Skip to content

CONCEPT Cited by 1 source

Quantum Key Distribution (QKD)

Definition

Quantum Key Distribution (QKD) is a family of key-agreement protocols that uses quantum physical phenomena — typically the transmission of polarised photons over a dedicated optical channel — to derive a shared secret key between two parties. Security rests on the no-cloning theorem: any eavesdropper attempting to intercept the photons disturbs their quantum state in a way the legitimate parties can detect, allowing them to discard compromised key material.

QKD is frequently proposed as an alternative to post-quantum cryptography (PQC) because both are pitched as defences against a future cryptographically- relevant quantum computer (CRQC). The two approaches are fundamentally different, and the cryptographic mainstream does not treat them as interchangeable — the NSA, Germany's BSI, and the UK's NCSC have all warned against solely relying on QKD. (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

Why QKD does not solve the Internet-PQ problem

Cloudflare's canonical wiki statement names the four structural limits:

  1. Requires specialised hardware. Both endpoints need single-photon emitters + detectors + polarisation-handling optical gear. Standard consumer-grade processors cannot run QKD the way they can run ML-KEM.
  2. Requires a dedicated physical link. QKD cannot run across the Internet as a logical overlay — photons need an optical path (typically a dark-fibre strand or free-space optical link) between the two parties. BGP-routed packet networks are structurally incompatible.
  3. No authentication. QKD solves the key-agreement problem (derive a shared secret) but does not authenticate the parties. You still need post-quantum signature cryptography to stop active attackers impersonating one end. The "QKD removes the need for PQC" framing is therefore structurally false.
  4. Vendor interoperability is weak. QKD systems from different vendors historically don't interoperate; QKD deployments are consequently point-solutions, not Internet-scale infrastructure.

"QKD requires specialized hardware and a dedicated physical link between the two parties, which fundamentally means it will not operate at Internet scale. Also, QKD does not provide authentication, so you still need post-quantum cryptography anyway to stop active attackers. It's difficult to find implementations of QKD that interoperate across vendors." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

RFC 8784 and the IPsec QKD distraction

RFC 8784 (2020) codified QKD-style post-quantum pre-shared key integration for IPsec, allowing operators to mix a pre-shared PQ secret (which in principle could come from a QKD system) into the IKEv2 handshake. Cloudflare's 2026-04 IPsec PQ post explicitly blames continued IPsec-community interest in QKD + RFC 8784 for the four-year delay between TLS adopting hybrid ML-KEM (2022) and IPsec adopting it (late 2025 draft-ietf-ipsecme-ikev2-mlkem):

"The four-year delay is likely due in part to the IPsec community's continued interest in Quantum Key Distribution (QKD), as codified in RFC 8784, published in 2020." (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga)

The implicit argument: standards-community focus is a finite resource, and QKD consumed focus that should have been spent on converging a single interoperable hybrid-KEM standard.

Niche use cases QKD remains reasonable for

QKD is not uniformly useless — there are specific scenarios where the dedicated-physical-link + specialised-hardware constraints are already met and the non-Internet-scale delivery mode is acceptable:

  • Financial trading floors with dedicated fibre between counterparties.
  • Government / intelligence point-to-point links where hardware investment and physical security are already provisioned.
  • Campus / metro-area fibre plants where the link distance and topology align with QKD's reach.
  • Research deployments demonstrating the technology.

Cloudflare's point is not that QKD has zero value — it's that QKD should not distract the IPsec / Internet standards community from the interoperable software PQC work that actually scales.

Contrast with PQC

Property QKD PQC (concepts/post-quantum-cryptography)
Hardware requirement Specialised quantum optics Standard processors
Link requirement Dedicated physical optical link Any IP network
Distance Limited (typically <100 km fibre) Unlimited
Authentication None — needs separate mechanism Built-in (PQ signatures)
Interoperability Weak (vendor-specific) Strong (NIST FIPS standards)
Scalability Point-to-point Internet-scale
Threat model covered Key-agreement confidentiality Key-agreement + authentication + HNDL
Deployment window Hardware-upgrade cycle Software-update cycle

PQC dominates on every axis that matters for Internet-scale deployment. QKD retains niche relevance for point-to-point links where hardware + physical-path + distance constraints already happen to be satisfiable.

Seen in

  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical wiki instance. Cloudflare's IPsec PQ GA post explicitly blames IPsec-community QKD interest (codified in RFC 8784 from 2020) for the four-year delay between TLS and IPsec hybrid ML-KEM rollouts; names the four structural limits of QKD; cites NSA / BSI / NCSC warnings against sole QKD reliance. Closes with the explicit standards-community ask: "we hope the IPsec community will continue to focus on interoperable PQC implementations, rather than diverting focus to niche use cases with QKD."
Last updated · 433 distilled / 1,256 read