Unified QKD-KEM Abstraction

• Unified QKD-KEM Abstraction is a framework that normalizes QKD keys into KEM-like operations, allowing seamless integration into existing key exchange processes.
• It bridges formal cryptographic primitives with practical protocol engineering by enabling hybrid designs in TLS, IPsec, and multi-source secret derivation pipelines.
• The approach combines information-theoretic QKD security with post-quantum and classical methods, ensuring robust protection even when one component is compromised.

Searching arXiv for the specified papers to ground the article and confirm metadata. arXiv search: (Blanco-Romero et al., 10 Mar 2025, Blanco-Romero et al., 12 Jul 2025, Dey et al., 14 Jan 2025, Malavolta et al., 2023, Raj et al., 9 Sep 2025). Unified QKD-KEM Abstraction denotes a family of constructions in which Quantum Key Distribution is represented through an interface that is compatible with key encapsulation or key-exchange pipelines, rather than being treated as an entirely separate subsystem. Across recent work, the abstraction appears in several distinct but related forms: as a formal quantum-enabled Key Encapsulation Mechanism (qKEM) composed with a symmetric Data Encapsulation Mechanism; as a public-key-encryption-like route to two-message QKD; as a provider-backed KEM-like secret source for TLS; as a KEM-shaped backend for IKEv2/IPsec; and as a unified key-management layer in which ECDH, ML-KEM, and Guardian-managed QKD jointly feed a downstream KDF. The shared theme is not a strict identification of QKD with classical KEMs, but an architectural normalization of QKD-generated key material into the same derivation and composition surfaces already used by KEM-based systems (Dey et al., 14 Jan 2025, Malavolta et al., 2023, Blanco-Romero et al., 10 Mar 2025, Blanco-Romero et al., 12 Jul 2025, Raj et al., 9 Sep 2025).

1. Conceptual scope and variants

The expression covers both formal cryptographic abstractions and compatibility-first systems engineering. In the formal direction, QKD is lifted into a primitive with encapsulation and decapsulation semantics. In the protocol-engineering direction, QKD remains operationally distinct—because its keys are pre-distributed and later referenced by identifiers—but is wrapped so that TLS or IKEv2 can consume it through interfaces already designed for KEMs or key exchange. In deployable hybrid systems, the same idea is extended further: QKD is one contributor among several to a common secret-derivation stage.

Work	Setting	Characterization of the abstraction
(Dey et al., 14 Jan 2025)	Hybrid encryption theory	QKD as qKEM, composed with DEM into qHE
(Malavolta et al., 2023)	Two-message QKD theory	QKD recast through QPKE, structurally KEM-like
(Blanco-Romero et al., 10 Mar 2025)	TLS/OpenSSL	QKD folded into a hybrid QKD-KEM provider
(Blanco-Romero et al., 12 Jul 2025)	IPsec/IKEv2	QKD backend made to look like a KEM provider
(Raj et al., 9 Sep 2025)	Hybrid encryption prototype	Unified key-management abstraction over ECDH, ML-KEM, and QKD

A central distinction runs through this literature. Some papers provide a formal primitive with an explicit security game, while others provide an implementation abstraction that preserves existing protocol machinery. The latter does not imply that QKD is literally a KEM in the cryptographic-theory sense. Rather, it means that QKD-derived secret material can be inserted into a KEM-shaped derivation path with minimal redesign of higher-layer software.

2. Formal cryptographic formulations

The most explicit formalization appears in the qKEM/qHE framework. A qKEM is defined as

${\sf qK = (qK.Gen_{\mathcal{E}}, qK.Enc, qK.Dec)},$

where

$${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$

${\sf qK.Enc}(X) \rightarrow (C,K),$

and

${\sf qK.Dec}(Y,C) \rightarrow K \text{ or } \perp.$

Here, Alice and Bob obtain correlated strings $X$ and $Y$ in the presence of an active quantum adversary $\mathcal{E}$, while Eve retains side information $\rho_E$. This is then composed with a DEM to form quantum-enabled hybrid encryption, with the paper proving the composition theorem

$$Adv^{ind\text{-}ot_{\sf qHE},\mathcal{E}^{\sf qHE}}(\lambda) \le \epsilon(\lambda)+\sigma(\lambda).$$

The same work constructs a concrete qKEM ${\sf CqK}$ from BB84-style QKD and proves that $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$0 is $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$1-IND-OT secure iff the underlying QKD is $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$2-secret, making the abstraction a formal bridge rather than a mere analogy (Dey et al., 14 Jan 2025).

A different formal route is taken by the QPKE-based two-message construction. There, the core primitive is a quantum public-key encryption scheme

$${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$3

with a public key $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$4 containing both a quantum state and a classical string. This leads to a two-message QKD syntax: $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$5

$${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$6

$${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$7

Bob samples $${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$8 and derives the final shared key as

$${\sf qK.Gen}_{\mathcal{E}}(1^\lambda) \rightarrow (X, Y, \rho_E),$$9

Structurally, Bob’s role is an encapsulation analogue and Alice’s role is a decapsulation analogue. The paper proves that if quantum-secure one-way functions exist, then there exists a two-message QKD protocol with everlasting security, while also proving that unconditionally secure QPKE is impossible. This formulation therefore supports a unified QKD/KEM viewpoint without claiming literal equivalence to standard classical KEM syntax (Malavolta et al., 2023).

Taken together, these formalizations suggest two complementary meanings of unification. One is compositional: QKD is a KEM-like primitive in a hybrid-encryption theorem. The other is structural: QKD can be made to exhibit the same two-message interaction pattern as encapsulation and decapsulation, albeit with quantum public keys and everlasting, rather than conventional IND-CPA, security.

3. Protocol-stack realization in TLS and IPsec

The TLS formulation starts from a concrete mismatch. TLS 1.3 and OpenSSL expose KEYEXCH and KEM provider interfaces, but QKD keys are pre-established and later retrieved by key identifiers through backend APIs. The proposed hybrid QKD-KEM design adapts the OQS Provider into a QKD-KEM Provider, allowing OpenSSL to treat QKD as a KEM-like secret source. The implementation supports both ETSI GS QKD 004 and ETSI GS QKD 014, with two flows. In the client-initiated flow, the client retrieves a QKD key identifier during key generation and sends it with the public KEM material; this supports both ETSI 004 and ETSI 014. In the server-initiated flow, the server retrieves the QKD key and returns the identifier to the client; this is cleaner for TLS semantics but only compatible with ETSI 014. The provider registers custom hybrid groups such as qkd_kyber768, advertises them in supported_groups, carries PQC public keys and optionally QKD key IDs in key_share, and leaves TLS core logic unchanged (Blanco-Romero et al., 10 Mar 2025).

The IPsec/IKEv2 formulation pushes the same idea into strongSwan. The abstraction is realized through the key_exchange_t interface, especially the operations get_public_key(), set_public_key(), and get_shared_secret(). In the pure QKD case, get_public_key() returns a QKD key identifier rather than a mathematical public key; set_public_key() consumes that identifier and triggers retrieval from the KME; get_shared_secret() returns the retrieved quantum key material. In the hybrid QKD+PQC case, the same interface wraps a real PQC KEM plus QKD. The paper also introduces a pure QKD approach that replaces computational key derivation with identifier-based quantum key coordination, and a unified QKD-KEM abstraction that enables parallel composition inside existing IKEv2 message structure. Compatibility is maintained with the standard IKE_SA_INIT / IKE_AUTH structure, with IKE_INTERMEDIATE used when sequential exchanges are needed (Blanco-Romero et al., 12 Jul 2025).

These realizations illustrate the protocol-engineering meaning of the abstraction. QKD is not remodeled as a native handshake primitive from first principles. Instead, the protocol layer continues to “speak KEM,” while the backend maps those operations to either stateful stream coordination or stateless key retrieval.

4. Secret composition and downstream derivation

At the heart of the abstraction is the treatment of QKD as another source of shared secret material. In the TLS design, the hybrid secret is explicitly defined by concatenation: ${\sf qK.Enc}(X) \rightarrow (C,K),$0 with total length

${\sf qK.Enc}(X) \rightarrow (C,K),$1

The paper also states a design rule that QKD material is always placed last in the final shared secret. Both endpoints derive the same concatenated value, and the resulting construction is intended to provide dual protection: the post-quantum KEM contributes computational quantum resistance, while the QKD component contributes information-theoretic security for its portion of the secret (Blanco-Romero et al., 10 Mar 2025).

The IPsec formulation uses the same composition rule in parallel-hybrid form: ${\sf qK.Enc}(X) \rightarrow (C,K),$2 The significance of this statement is architectural. The two secrets are produced within the same logical exchange and then combined, rather than serialized into separate protocol round trips. This is the paper’s formalization of parallel composition (Blanco-Romero et al., 12 Jul 2025).

The deployable hybrid encryption framework broadens the composition beyond PQC and QKD alone. It treats ECDH (X25519), ML-KEM-768, and Guardian QKD as parallel contributors to a common derivation stage. The paper states: “These keys are concatenated and passed through a key derivation function (KDF) to produce symmetric encryption and HMAC keys, ensuring security even if one protocol is compromised, as their generation depends on all three components.” The implementation mentions KDF2 (SHA-256), yielding an operational flow that can be expressed as

${\sf qK.Enc}(X) \rightarrow (C,K),$3

From this derived material the system obtains ${\sf qK.Enc}(X) \rightarrow (C,K),$4 for encryption and ${\sf qK.Enc}(X) \rightarrow (C,K),$5 for message authentication. Authentication is also hybridized: EdDSA/Ed25519 and ML-DSA-6x5 are applied in parallel, and both signatures must validate (Raj et al., 9 Sep 2025).

This suggests a general pattern. Unified QKD-KEM abstraction is not confined to encapsulation syntax; it can also denote a secret-aggregation layer in which heterogeneous establishment mechanisms collapse into a single downstream symmetric-security pipeline.

5. Security rationale, assumptions, and points of contention

The common security argument is hybrid redundancy. In the formal qKEM setting, QKD supplies an information-theoretically secure encapsulated key, while the DEM provides post-quantum-secure message encryption against a QPT adversary. In the QPKE setting, the shared key is information-theoretically hidden after protocol completion, provided computational assumptions hold during execution. In the protocol-engineering papers, the concatenated secret remains protected as long as at least one underlying component remains uncompromised, which is the usual hybrid-combiner intuition (Dey et al., 14 Jan 2025, Malavolta et al., 2023).

Several assumptions delimit these claims. In the TLS prototype, QKD keys traverse HTTPS between remote endpoints, which the paper explicitly states is not a true quantum-secure deployment; the strongest claim requires endpoints co-located with QKD nodes or within secure segments so that keys do not travel over quantum-insecure channels. In the Guardian-based framework, Guardian is trusted to retrieve and distribute QKD keys correctly, whether from a simulator or Vault, and the design assumes correct implementation of classical and PQC components as well as proper key separation by the KDF. The same framework notes that QKD deployment is constrained by cost, distance, and key rates, and that real-world QKD hardware integration remains future work (Blanco-Romero et al., 10 Mar 2025, Raj et al., 9 Sep 2025).

A recurrent misconception is that unification means “QKD = KEM.” The literature does not support that interpretation. The TLS paper explicitly presents a compatibility-first hybrid abstraction; the IPsec paper treats QKD as a backend that can be made to look like a KEM provider; the Guardian-based prototype is described as a hybrid key-establishment and hybrid-authentication framework rather than a fully formalized unified abstraction. This is therefore not a proof that QKD is natively a KEM, but a demonstration that QKD can be normalized into KEM-like derivation and interface boundaries when that is operationally useful (Blanco-Romero et al., 10 Mar 2025, Blanco-Romero et al., 12 Jul 2025, Raj et al., 9 Sep 2025).

There are also protocol-specific concerns. In pure-QKD IKEv2, the paper notes that no proof-of-possession is built in, so identifier substitution attacks or replay-style problems can remain possible until authentication completes. It explicitly suggests future proof-of-possession mechanisms, potentially using IKE_INTERMEDIATE. More broadly, the IPsec work emphasizes that authenticated handshakes remain necessary and that classical authentication remains a limitation unless post-quantum authentication is also used (Blanco-Romero et al., 12 Jul 2025).

6. Performance characteristics and practical significance

The empirical literature is implementation-oriented rather than theorem-driven. In TLS, isolated PQC KEM operations show that ML-KEM variants complete in microseconds, HQC algorithms take milliseconds, and key generation is generally the slowest operation. Adding QKD introduces a roughly fixed overhead of about

${\sf qK.Enc}(X) \rightarrow (C,K),$6

in key generation and encapsulation due to ETSI 014 API calls, while decapsulation is unaffected in the same way. With production Cerberis XGR QKD hardware, handshake times are mostly around 300–350 ms, with one outlier around 551 ms for bikel5; example entries include mlkem512: OQS 18.22 ms vs QKD 300.96 ms, mlkem768: OQS 13.47 ms vs QKD 310.76 ms, and hqc256: OQS 72.92 ms vs QKD 362.40 ms (Blanco-Romero et al., 10 Mar 2025).

In IPsec, the paper presents the first systematic comparison of sequential versus parallel hybrid QKD-PQC key establishment strategies for IPsec and concludes that parallel composition eliminates the multiplicative latency penalties of sequential methods mandated by RFC 9370. Under 100 ms artificial delay, a sequential composition with two extra exchanges incurs about 200 ms of extra handshake time, directly reflecting added RTTs. The evaluation uses IDQuantique Cerberis XGR QKD nodes over dark fiber, Docker-based strongSwan containers, and network impairment emulation. The results show that the parallel unified QKD-KEM hybrid consistently outperforms sequential RFC 9370-style compositions as latency rises, that pure QKD exchanges are very compact at around 270–319 bytes, and that QKD+ML-KEM-512 and QKD+ML-KEM-768 stay within standard MTU limits (Blanco-Romero et al., 12 Jul 2025).

The multi-source hybrid encryption prototype reports prototype performance metrics across many PQC-hybrid combinations. Among the faster options, X25519-MLKE512M-Draft00 has average execution time: 774315.00 ns, bytes transferred: 1632, and packets transferred: 2; X25519-MLKE768M-Draft00 has average execution time: 951946.00 ns, bytes transferred: 2336, and packets transferred: 2; X448-MLKEM768-Draft00 has average execution time: 3269694.00 ns, bytes transferred: 2384, and packets transferred: 2. FrodoKEM variants are reported at around 24–45 million ns, 31440–31488 bytes, and 22 packets, while McEliece is the heaviest with average execution time: 84805784.00 ns, bytes transferred: 200722, and 139 packets. The paper does not provide a separate quantitative benchmark for the exact QKD+Guardian path versus ML-KEM-only or classical-only operation; Guardian is instead presented as the enabling distribution layer (Raj et al., 9 Sep 2025).

The aggregate significance of these results is architectural rather than absolute. The abstraction appears practical when compact lattice-based PQC is used, especially in parallel compositions that avoid extra protocol turns. It also appears transitional: organizations can preserve existing TLS or IPsec machinery, support both ETSI GS QKD 004 and ETSI GS QKD 014 where required, and combine QKD with PQC and, in some designs, classical mechanisms. Unified QKD-KEM Abstraction thus names a convergence point between QKD’s identifier-coordinated key retrieval model and the encapsulation-oriented abstractions already dominant in modern secure-channel protocols.