PaperlayerView exact revision on arXiv

Source-linked AI summary

Combining Post-Quantum Cryptography and Quantum Key Distribution: Taxonomy, Constructions, Proofs, Standards, Deployments and Open Problems

Mona Alotaibi, Noora Fetais, Saif Al-Kuwari

arXiv:2610.19039v1cs.CR

TL;DR

Combining PQC and QKD is subtle because an adversarially influenced input can weaken a hybrid key. This paper surveys hybrid designs, organizes them by taxonomy and security arguments, and concludes that binding keys and identifiers to a session matters more than choosing XOR or a KDF.

  • Problem

    Combining PQC and QKD is subtle: a compromised or adversarially influenced input must not weaken the other key source, and the QKD classical channel requires authentication.

    Source: §1 · p. 2

  • Method

    The paper separates hybrid designs into orthogonal taxonomy dimensions and maps their security arguments by model, assumptions, permitted compromise, guarantees, and limitations.

    Source: §1.3 · p. 5, §3 · p. 9

  • Results

    The paper finds that binding exchanged and QKD keys and their identifiers to a session matters more than using a KDF or XOR combiner.

    Source: §10 · p. 23

  • Takeaways & Limitations

    Plain XOR preserves QKD secrecy only under a narrow independence condition and does not bind the public values that produced the inputs.

    Source: §4.1 · p. 12

    The reviewed proofs cover shared-infrastructure threats only partially, despite modeling some effects such as QKD-key leakage or compromise.

    Source: §4.3 · p. 16

Abstract

from arXiv · show

Post-quantum cryptography (PQC) and quantum key distribution (QKD) address the quantum threat from opposite directions: PQC replaces vulnerable public-key algorithms with schemes believed to resist quantum cryptanalysis, while QKD derives keys whose secrecy rests on physical assumptions rather than computational ones. Because each approach has a distinct failure mode, a growing body of work combines them so that a session key remains secure if either component holds. We first establish the deployed baseline, hybrid classical-plus-PQC key exchange, against which QKD-augmented designs must be judged. We then propose a taxonomy of hybrid PQC-QKD designs along eight dimensions (integration layer, combiner construction, authentication scope and source, QKD topology, trusted entities, key-delivery interface, classical component, and evidence type), and use it to compare published protocols, including Muckle and its successors, MACsec and TLS integrations, and IKEv2 mechanisms standardised in RFCs 8784, 9370, and 9867. We examine key-combiner constructions in light of the KEM-combiner literature and of NIST, ETSI, and ITU-T guidance, and map the security arguments for hybrid PQC-QKD protocols onto a common grid of security model, assumptions, permitted compromise, established guarantee, and limitations. We synthesise deployment evidence from metropolitan and national QKD networks, distinguishing the few testbeds that have run PQC in the key path from pure-QKD deployments, and summarise the standards and policy landscape, including the positions of national security agencies that recommend against relying on QKD alone. We close with open problems: authentication of the QKD classical channel, shared-infrastructure threat models, device certification versus formal proofs, formal verification of hybrid handshakes, and the lack of peer-reviewed deployment economics.

1 Introduction

The survey frames hybrid PQC–QKD as a response to the distinct failure modes of PQC and QKD, then compares designs across protocols, standards, proofs, and deployments. It positions its contribution as an evidence-based account of what proofs establish, what remains outside their scope, and which measurements support performance claims.

1 Introduction

  • PQC and QKD address the quantum threat with different security bases and limitations, motivating hybrids intended to remain secure when either key source is uncompromised.PQC relies on computational assumptions; QKD relies on quantum-mechanical principles but has device, infrastructure, and authentication constraints.Source: §1 · p. 2

1.1 Scope and corpus construction

  • The survey is an expert-curated, non-systematic review of key establishment and protocol integration, with corpus construction bounded by its stated databases, search terms, and dates.It combines seed studies and standards, backward and forward snowballing, and database searches; it excludes hardware and implementation topics except where they bear on hybrid design.Source: §1.1 · p. 2

1.2 Related surveys

  • Prior surveys cover PQC, QKD, or selected integration areas, but none treats combined PQC–QKD key material as its subject.The survey distinguishes its coverage from GSMA IG.18 [67] and Abelard et al. by examining proof limitations, key-identifier binding, protocol integrations, and measurement conditions.Source: §1.2 · pp. 3–4

1.3 Contributions

  • The survey proposes an eight-dimension taxonomy that separates topology, trusted entities, key-delivery interfaces, authentication scope, and evidence types.It classifies core studies and uses the taxonomy to compare designs.Source: §1.3 · p. 4
  • It analyzes combiner constructions and maps identified security arguments by model, assumptions, permitted compromise, guarantees, limitations, and supporting theorem.It also compares TLS 1.3, IKEv2/IPsec, and MACsec integrations against the relevant standards.Source: §1.3 · p. 5
  • The survey synthesizes deployment evidence while distinguishing pure-QKD testbeds from deployments that ran PQC in the key path, summarizes standards and policy, and derives open problems.Its stated added value is an evidence-based comparison of proof scope, deployed-system components outside reviewed proofs, and measurements supporting performance claims.Source: §1.3 · p. 5

1.4 Organization

  • The remaining sections proceed from security background and taxonomy through proofs, protocol integrations, deployments, standards, deployment considerations, open problems, and conclusion.Source: §1.4 · p. 5

2 Foundations

The foundations frame the quantum threat as a migration concern, distinguish PQC’s computational basis from QKD’s authenticated physical-key approach, and clarify which security properties hybrid analyses can establish.

2.1 The quantum threat, briefly

  • A cryptographically relevant quantum computer threatens RSA and elliptic-curve cryptography, so data-confidentiality and migration timelines matter because recorded ciphertext could later be decrypted.Mosca’s framing treats a CRQC arriving within x + y years as a present concern when data must remain confidential for x years and migration takes y years.Source: §2.1 · p. 5

2.2 Post-quantum cryptography

  • PQC replaces vulnerable assumptions with quantum-resistant candidates, while deployed TLS 1.3 hybrids combine ECDH and ML-KEM secrets in the key schedule.The surveyed designs pass combined keys to symmetric ciphers; ML-KEM, ML-DSA, and SLH-DSA are standardized, while implementation flaws can undermine the assumed independence of failures.Source: §2.2 · p. 6

2.3 Quantum key distribution

  • QKD can provide keys without computational secrecy assumptions, but requires an authenticated classical channel and often trusted relays that hold keys in the clear [14, 45, 84, 91, 132].Detector and source imperfections motivate device certification; MDI- and TF-QKD remove trust in a relay’s measurement, not the need for long-distance relay chains.Source: §2.3 · pp. 6–7

2.4 Security properties and arguments

  • Hybrid security claims concern distinct properties: key secrecy, peer authentication, and application-data confidentiality, and a protocol may establish one without establishing the others.Application-data confidentiality still depends on correct use of computationally secure AEAD; key-exchange proofs do not establish it.Source: §2.4 · pp. 7–8
  • Hybrid proofs give system-specific advantage bounds under component-model assumptions; reviewed analyses differ in their guarantees and may idealize QKD keys or omit infrastructure-sharing risks [69].Muckle claims a sum of component limits, while Hövelmanns et al. suggest the lesser limit; Clermont and Henrich claim twice the lesser limit.Source: §2.4 · p. 8

3 A Taxonomy of Hybrid PQC–QKD Designs

The taxonomy compares hybrid PQC–QKD designs across eight dimensions and separates endpoint authentication from authentication of QKD and key-management channels. Its survey matrix distinguishes designs with proofs from integrations and deployments, while showing that some works labelled hybrid do not combine two key sources.

3 A Taxonomy of Hybrid PQC–QKD Designs

  • Eight dimensions cover integration layer, combiner, authentication scope and source, QKD topology, trusted entities, key-delivery interface, classical component, and evidence type.Authentication is recorded separately for endpoint exchange (E), the QKD classical channel (Q), and key-delivery and relay channels (K).Source: §3 · pp. 8–9
  • The taxonomy records whether designs retain a classical ECDH/DH contribution and allows multiple evidence types, including proofs, implementations, deployments, standards, and informal analysis.D1, D2, and D4–D7 take one value per design; D3 is recorded per authentication scope, and D8 lists all applicable evidence types.Source: §3 · p. 9, Figure 1 · p. 10
  • The dimensions are orthogonal: a combiner can appear at different protocol layers, with different authentication and QKD-topology choices.Topology, trusted entities, and key-delivery interface distinguish relay presence, who holds keys in the clear, and how a key is bound to a session.Source: §3 · p. 9
  • The surveyed proofs generally authenticate the endpoint exchange but assume QKD and key-management channels; only some deployments document those channels.Ferreira’s protocol is an exception in also protecting the classical data of its embedded QKD phase.Source: §3 · pp. 10, 12
  • Proof-bearing designs in the surveyed corpus tend to use abstract key delivery at the AKE layer, while testbed-backed designs use protocol or KMS layers and ETSI key interfaces.Muckle+ and Muckle++ combine proof and implementation evidence on QKD hardware; other listed implementations use simulated QKD or network-level analysis.Source: §3 · p. 11
  • Some works use PQC only for QKD-channel or key-management protection, or document no PQC component, so they are not two-key-source combinations.The taxonomy marks these as having no combiner or authentication confined to scope Q.Source: §3 · pp. 11–12, Table 6 · p. 11

4 Key Combination and Security Arguments

The section compares combiners by their binding of public values, response to attacker-influenced inputs, and preservation of information-theoretic key secrecy, then examines what proof models cover. It concludes that shared infrastructure and incompletely modelled key-delivery channels limit what protocol proofs establish for deployments.

4.1 Combiner constructions

  • XOR preserves information-theoretic secrecy when one input is uniform and independent, but plain XOR lacks public-value binding and does not generally preserve IND-CCA security for KEMs.Hövelmanns et al. bind the transcript and QKD key identifier with nested one-time MACs before XOR, addressing dependent-key attacks [69].Source: §4.1 · p. 12
  • A KDF over concatenated secrets relies on a dual-PRF property; when QKD is an input, key secrecy then rests on the KDF assumption even if QKD is secure.Application-data confidentiality remains computational in the surveyed integrations because the data use a computational AEAD.Source: §4.1 · pp. 12–13
  • Muckle’s chained HKDF stages combine classical, PQ, and QKD secrets with computational key-indistinguishability guarantees; IKEv2 standards mix PPKs through the protocol’s PRF chain.RFC 8784 and RFC 9867 name QKD keys as possible PPKs, while RFC 9370 adds ML-KEM exchanges.Source: §4.1 · p. 13

4.2 Security arguments

  • Proofs model QKD variously as shared random keys, a BB84 phase, or an identifier-based key service that can permit leakage or key override.The HAKE approach fixes the QKD key per stage, while Hövelmanns et al. model identifiers and adversarial QKD-key leakage or override [69].Source: §4.2 · p. 15
  • Game-based and UC-composability proofs for hybrid PQC–QKD systems are not known, and composing the QKD security bound with key-management and AKE advantages remains open.Ferreira reports that existing BB84 security parameters make the game-based bound unmeaningful over expected runs of an installed protocol.Source: §4.2 · p. 15

4.3 Shared-infrastructure threats

  • Shared infrastructure can make both component models false at once, so a protocol proof alone cannot justify a deployed system’s “secure if either holds” claim.The authors recommend evaluating the combiner at the key-consuming endpoint, including device and implementation security evidence, and modelling the key-delivery interface.Source: §4.3 · p. 16

5 Protocol-Level Integration

The integrations exchange QKD key identifiers and retrieve corresponding keys locally, while PQC enters through existing protocol mechanisms. The section compares TLS, IKEv2/IPsec, and MACsec designs, noting that retrieval and exchange patterns shape latency and that proofs cover different parts of the integrations.

5 Protocol-Level Integration

  • Endpoints typically exchange a QKD key identifier and retrieve the corresponding key through a key-management interface, keeping QKD key material off the classical channel.Because the identifier binds the QKD key to the session, it must be authenticated in the transcript [69].Source: §5 · p. 17, Figure 2 · p. 18

5.1 TLS 1.3

  • TLS integrations place a QKD key identifier alongside ECDH and ML-KEM shares, retrieve the key through ETSI interfaces, and combine secrets in the TLS key schedule.Reported added handshake latency is attributed mostly to QKD key retrieval rather than ML-KEM; these handshake measurements do not report data-plane throughput [20].Source: §5.1 · p. 17

5.2 IKEv2 / IPsec

  • IKEv2 standards provide mechanisms for ML-KEM and QKD-derived PPKs, enabling an ECDH–ML-KEM–QKD hybrid through the existing PRF chain.The standards do not specify mapping a PPK identifier to an ETSI key identifier or the PPK refresh policy; a reported parallel composition avoids sequential exchange latency [21].Source: §5.2 · p. 17

5.3 MACsec

  • VMuckle supplies MKA with a root session key from a separate hybrid AKE, leaving MKA and the MACsec data plane unchanged.Its proof covers VMuckle but not the hand-off to MKA; its prototype used simulated QKD, with MadQCI deployment listed as future work [28].Source: §5.3 · p. 18

5.4 Cross-layer comparison

  • Across layers, TLS and IKEv2 reuse their key schedules, while VMuckle supplies the root key MKA consumes; reported latency comes largely from key retrieval or sequential exchanges.Buffering pre-distributed QKD keys removes key generation from the critical path, but not the retrieval round trip.Source: §5.4 · pp. 18–19

6 Deployment Evidence

The deployment evidence separates pure-QKD networks from testbeds that place PQC in the key or control path. Reported findings distinguish network interoperability and key-path use from application throughput, QKD key rate, and handshake latency.

Deployment evidence

  • PQC appears in the key or control path in six reported testbeds or prototypes, while Alia et al.’s deployed-fibre IPsec trial combines classical and QKD keys without PQC [5].The cited examples include Berlin, Madrid, Eindhoven, Vigo–Madrid, Jinan, and Toshiba’s Muckle++ integration.Source: §6 · p. 19

Reported findings

  • In TLS measurements, added handshake latency is attributed to key retrieval rather than PQC arithmetic [20].The reported findings also include multi-vendor ETSI 014/004 interoperability and trusted-node relaying in each multi-span Table 11 network.Source: §6 · p. 19

Metric distinctions

  • 80 Gb/s application throughput and a 7.4 kb/s secret-key rate were both reported for Alia et al.’s trial, and the throughput does not indicate key-refresh capacity [5].Application throughput, QKD secret-key rate, handshake latency, and rekey interval are distinct metrics.Source: §6 · p. 19

Evidence boundary

  • Peer-reviewed sources provide no data on carrier-grade availability, long-term operational cost, or security incidents for the networks in Tables 11 and 12.Table values are taken from cited sources; unstated values are marked n.r.Source: §6 · p. 19

7 Standards and Policy Landscape

The standards landscape includes mature provisions for hybrid key combination, while agencies in several countries do not recommend QKD as a replacement for PQC. The policy baseline is PQC, with QKD treated as an optional additional layer.

Standards

  • NIST, ETSI, IETF, and ITU-T documents cover hybrid key combination, including IKEv2 and classical-plus-PQC TLS 1.3 exchanges.A new combiner should explain why existing constructions do not meet its goal; information-theoretic key secrecy is one cited reason.Source: §7 · p. 19

Agency policy

  • Agencies in the United States, United Kingdom, France, Germany, Netherlands, and Sweden do not approve or recommend QKD as a PQC replacement.Their cited concerns include special-purpose hardware, authentication, trusted nodes, proof-to-device gaps, and lack of a certification path.Source: §7 · pp. 19–20

Deployment constraints

  • The shared-infrastructure threat surface includes QKD keys visible in cleartext to the KMS and relay nodes, plus endpoints hosting both PQC implementations and key stores.The QKD reconciliation channel also requires authentication.Source: §7 · p. 20

Policy and certification

  • The European position allows QKD “in addition to” PQC, while the cited agency policy baseline is PQC and QKD is optional.No hybrid PQC–QKD product is known to have been evaluated against ETSI GS QKD 016 or ISO/IEC 23837 together with FIPS 140-3 validation of its PQC component.Source: §7 · p. 20

8 Deployment Considerations

The deployment considerations describe a shared architecture, trust and topology constraints, operational differences between QKD and PQC key lifecycles, and the limited evidence on hybrid deployment economics.

8.1 Reference architecture

  • QKD keys pass from per-span generation through a KMS to endpoints, while the combiner runs either at endpoints or inside the KMS.The reference architecture identifies trusted nodes and the KMS as concentrations of shared-infrastructure threats.Source: §8.1 · p. 20

8.2 Topology and trust

  • Every cited multi-link network uses trusted-node relaying, and the practical recommendation is to terminate PQC end-to-end and protect relays with PQC-authenticated, encrypted key transport.Topology choices depend on where trusted nodes can be physically secured; MDI- and TF-QKD relocate trust from relay measurement but still require chains of end nodes.Source: §8.2 · pp. 20–21

8.3 Key management and operations

  • QKD keys are generated continuously and buffered in per-link pools, whereas PQC keys are generated per session.ETSI 014/004 standardize key-delivery interfaces, and RFC 9867 specifies use of refreshed IKEv2 PPKs without re-establishing the SA; fallback when QKD keys are unavailable must be explicit and negotiated.Source: §8.3 · p. 21

8.4 Cost

  • No peer-reviewed cost or benefit–cost analysis of a hybrid PQC–QKD deployment was found.QKD costs are dominated by transceiver hardware, fibre, and secured trusted-node sites, while PQC is software and adds little [54].Source: §8.4 · p. 21

9 Open Problems

The survey identifies open questions spanning QKD-channel authentication, end-to-end proof coverage, shared infrastructure, certification, formal verification, identifier binding, deployment evidence, and the value of QKD’s hedge. These questions mark limits in current proofs, interoperability, and peer-reviewed operational data.

O1. Authentication of the QKD classical channel

  • QKD classical-channel authentication remains open: reviewed proofs assume authentication, while deployments use pre-shared keys or PQ signatures and newer work explores KEM-based authentication [13].Questions include what survives later compromise of the authenticating KEM and how to bind the QKD transcript or session identifier into the hybrid AKE.Source: §9 · p. 21

O2. Proofs that include the full key-delivery path

  • Proofs do not yet cover the full key-delivery path: existing work models an ETSI 014-like interface or QKD phase, while other proofs treat QKD keys abstractly [69].Open extensions include stateful ETSI 004, multi-tenant KMSs, inter-KMS relays, and composable bounds connecting ε_QKD to AKE advantage; deployed parameters can yield non-meaningful bounds.Source: §9 · pp. 21–22

O3. Shared-infrastructure threat models

  • Current proofs only partially cover shared-infrastructure threats; open work includes KMS and trusted-node corruption models and determining which combiners preserve the PQC guarantee [69].The reviewed QKD-OVERRIDE oracle captures an attacker-set QKD key on one end-to-end link.Source: §9 · p. 22

O4. Certification versus proof

  • QKD-device certification and PQC-module validation remain separate, with no joint profile for hybrid endpoints.The open question is how to map proof assumptions to assurance requirements so certification can discharge them.Source: §9 · p. 22

O5. Formal verification of hybrid handshakes

  • No Tamarin or ProVerif model was found for QKD-extended TLS or IKEv2, VMuckle, or its hand-off to MKA.Proposed checks include symbolic modeling of key-ID exchanges and downgrade or identifier-confusion properties.Source: §9 · p. 22

O6. Standardised bindings

  • No IANA-registered TLS group carries a QKD key identifier, and no profile binds RFC 9867 PPK or ETSI 014 identifiers across vendors [69].The binding must authenticate the identifier as part of the transcript.Source: §9 · p. 22

O7. Deployment economics and operational evidence

  • Peer-reviewed availability, incident, and cost data for hybrid PQC–QKD deployments are absent; project deliverables are the only reviewed sources reporting such data.The open question is which metrics enable comparison with the classical-plus-PQC baseline.Source: §9 · p. 22

O8. The value question

  • The value of adding QKD remains an open question about whether its hedge exceeds PQC algorithm diversity for particular data lifetimes and threat models [8] [119].The stated trade-off includes the cost of QKD and possible lattice-assumption breaks within the confidentiality lifetime.Source: §9 · p. 22

10 Conclusion

The review contrasts the small literature on hybrid PQC–QKD protocols with deployed hybrid systems and identifies design priorities, evidence gaps, and policy context.

10 Conclusion

  • The review finds that most deployed hybrid systems use QKD keys provided per ETSI standards, while only a few reviewed protocols combine PQC and QKD with QKD hardware and security proofs.Exceptions include Muckle+, Muckle++, and an IPsec implementation by Garms et al.Source: §10 · pp. 22–23
  • Binding exchanged keys and QKD key identifiers to a session matters more than choosing a KDF or XOR combiner.KDF-based standards combiners do not provide information-theoretic secrecy, although computationally secure AEAD can preserve upper-layer message confidentiality.Source: §10 · p. 23
  • The review identifies unresolved questions in protocol models, authentication, shared infrastructure and key management, device certification, and formal verification of end-user handshakes.It also reports no peer-reviewed evidence on hybrid QKD–PQC system operation or economics; procuring agencies view PQC as necessary and QKD as an option requiring justification for particular data-storage durations and threat models.Source: §10 · p. 23

Related papers

Loading 2610.19039v1…