---
title: Unified QKD-KEM Abstraction
url: https://www.emergentmind.com/topics/unified-qkd-kem-abstraction
type: topic
---

# Unified QKD-KEM Abstraction

Searching arXiv for the specified papers to ground the article and confirm metadata.
arXiv search: 2503.07196, 2507.09288, 2501.08435, 2304.02999, 2509.10551.
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 [2501.08435] [2304.02999] [2503.07196] [2507.09288] [2509.10551].

## 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 |
|---|---|---|
| [2501.08435] | Hybrid encryption theory | QKD as **qKEM**, composed with DEM into **qHE** |
| [2304.02999] | Two-message QKD theory | QKD recast through **QPKE**, structurally KEM-like |
| [2503.07196] | TLS/OpenSSL | QKD folded into a **hybrid QKD-KEM** provider |
| [2507.09288] | IPsec/IKEv2 | QKD backend made to look like a **KEM provider** |
| [2509.10551] | 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 CqK}\) is \(\epsilon(\lambda)\)-IND-OT secure iff the underlying QKD is \(\epsilon(\lambda)\)-secret, making the abstraction a formal bridge rather than a mere analogy [2501.08435].

A different formal route is taken by the QPKE-based two-message construction. There, the core primitive is a quantum public-key encryption scheme
\[
(SKGen, PKGen, Enc, Dec),
\]
with a public key \((\rho,pk)\) containing both a quantum state and a classical string. This leads to a two-message QKD syntax:
\[
(msg,\mu,st) \gets \mathsf{QKDFirst}(1^\lambda),
\]
\[
\{(resp,\eta,k),\bot\} \gets \mathsf{QKDSecond}(msg,\mu),
\]
\[
\{k,\bot\} \gets \mathsf{QKDDecode}(st,resp,\eta).
\]
Bob samples \(k\in\{0,1\}^{4\lambda}\) and derives the final shared key as
\[
K = \mathsf{Hash}(k).
\]
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 [2304.02999].

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 [2503.07196].

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 [2507.09288].

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:
\[
ss = ss_{PQ} \,\|\, k_{QKD},
\]
with total length
\[
|ss| = |ss_{PQ}| + |k_{QKD}|.
\]
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 [2503.07196].

The IPsec formulation uses the same composition rule in parallel-hybrid form:
\[
\text{shared\_secret} = \text{PQC\_secret} \| \text{QKD\_key}.
\]
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 [2507.09288].

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
\[
K_{\text{session}} = \mathrm{KDF2}_{\mathrm{SHA\text{-}256}}(K_{\text{ECDH}} \parallel K_{\text{ML-KEM}} \parallel K_{\text{QKD}}).
\]
From this derived material the system obtains \(K_{\text{enc}}\) for encryption and \(K_{\text{HMAC}}\) for message authentication. Authentication is also hybridized: **EdDSA/Ed25519** and **ML-DSA-6x5** are applied in parallel, and both signatures must validate [2509.10551].

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 [2501.08435] [2304.02999].

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 [2503.07196] [2509.10551].

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 [2503.07196] [2507.09288] [2509.10551].

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 [2507.09288].

## 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
\[
\sim 100 \text{ ms}
\]
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** [2503.07196].

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 [2507.09288].

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 [2509.10551].

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.

Source: https://www.emergentmind.com/topics/unified-qkd-kem-abstraction