Quantum Key Distribution

Two answers to the same adversary

Quantum key distribution and post-quantum cryptography get mentioned in the same breath because they answer the same fear: an adversary with a future quantum computer. The similarity ends there.

QKD is a physical key-establishment scheme. Two parties exchange quantum states over a dedicated channel, coordinate over an authenticated classical channel, and end up with shared key material — plus a statistical bound on how much an eavesdropper could have learned. It needs specialized hardware at both ends and care about distance, topology, and trusted relays.

Post-quantum cryptography, or PQC, is a set of classical algorithms designed so that even a quantum attacker gets no useful shortcut. It ships as software. It runs on the machines and networks you already have. One of these is an infrastructure project; the other is a migration project. Treating them as interchangeable products is the first and most expensive mistake in this space.

Measurement is the security mechanism

In the BB84-style pattern, Alice encodes each bit in a randomly chosen basis and Bob measures each arriving qubit in a randomly chosen basis. When their bases agree, their outcomes agree and the bit enters the candidate key. When the bases disagree, the outcome is discarded. The sifted bits that survive become the key — after one more step that carries the entire security argument.

That step exists because of the Born rule:

An eavesdropper who measures a qubit in the wrong basis does not just fail to learn the bit; she disturbs the state, and Bob's later measurement inherits that disturbance as an elevated error rate. Alice and Bob sacrifice a public sample of their sifted bits, estimate the error rate, and only keep the key if the rate is low enough to bound what Eve could know.

The estimate is statistics, not certainty. With $S$ sampled bits, the sampling error of the measured rate is roughly:

Small samples leave wide margins, and the security proof lives inside those margins. Note also what the scheme assumes rather than provides: the classical channel must be authenticated by ordinary cryptographic means. QKD distributes keys. It does not authenticate anyone.

Worked example: the enterprise memo

An enterprise holds confidential data that must stay secret for decades, and leadership asks whether to "buy quantum-safe security." The weak memo is one sentence: buy QKD, because it is quantum-safe. The stronger memo reads like this:

• Threat model. Long-lived confidential data exposed to record-now-decrypt-later collection by a future quantum-capable adversary.
• Baseline. Migrate vulnerable public-key systems to suitable post-quantum algorithms wherever they are deployable — which is nearly everywhere, because PQC is software.
• QKD fit. Consider only for specific high-value links where dedicated hardware, key management, distance limits, the trust model, and the operational burden are all acceptable.
• Decision. PQC migration is the broad default; QKD is a specialized option for named links after an infrastructure review.

The stronger memo is not more cautious; it is more precise. It separates the security goal (protect long-lived data) from the branding on the tool, and it prices each tool in the currency it actually costs — software rollout versus physical infrastructure.

Where the intuition fails

The first trap is recommending QKD as a universal replacement for cryptography. QKD produces key material on particular links. It does nothing for authentication, endpoint compromise, software updates, identity systems, or the migration of every other cryptographic dependency. A link with perfect quantum key distribution and a compromised endpoint is a compromised link.

The second trap runs the other way: treating PQC as a quantum product. PQC is classical mathematics aimed at quantum adversaries. Its real concerns are algorithm choices, protocol integration, implementation quality, interoperability, and migration risk — the ordinary miseries of a large software transition. No photons are involved.

The engineering view

For a builder, this chapter is about threat modeling and systems integration, not about a single primitive. A system is not made secure by one clever component. You have to ask where keys are generated, stored, rotated, authenticated, audited, and used — and what breaks when each of those steps fails.

Any serious QKD-versus-PQC comparison should score, at minimum:

• threat model and attacker capabilities
• asset lifetime — how long the data must stay secret
• network topology and link distances
• hardware requirements at each endpoint
• software migration path and interoperability
• authentication assumptions on the classical channel
• operational burden: key management, maintenance, staffing
• verification evidence: what has been demonstrated, under what conditions

The quantum layer changes one part of this stack. The rest of the stack does not notice, and neither do your attackers.

What this buys you in diligence

When a vendor or startup pitches quantum security, the first question is which problem the buyer actually has: key distribution on specific links, cryptographic migration, compliance, or general security hygiene. If the pitch treats QKD and PQC as one category, mark the diligence risk high — the confusion is either strategic or sincere, and both are expensive.

A credible claim names its threat model, its integration burden, and its operational proof. An incredible one leads with the word "unhackable." The physics in this chapter is solid; the engineering and economics around it are where the real evaluation happens.

Exercise

Decide one security scenario. Take a real or plausible enterprise problem and produce a QKD-versus-PQC recommendation that a security team could act on.

• Map the problem into assets, attackers, key paths, and cryptographic dependencies before proposing any technology.
• Describe the classical migration path first, so the quantum-specific option has to justify itself against a working baseline.
• Deliver a comparison table covering deployment burden, hardware needs, standards path, and a practical recommendation.
• Use the Born rule and the sampling-error formula only for the quantum measurement part — they are not a substitute for the whole security argument.
• Close with a build, partner, monitor, wait, or avoid call, and name the single assumption that would flip your answer.

Check your understanding

Answer without notes: for one concrete enterprise threat model, when does QKD beat PQC, and which assumptions drive that conclusion?

A passing answer distinguishes key establishment from cryptographic migration, names the role of the authenticated classical channel, and ties the recommendation to asset lifetime and topology rather than to the word "quantum."

Oral defense: explain to a smart colleague why "QKD is quantum-safe cryptography" is a category error — without dismissing QKD as useless.

If you get stuck

If your reasoning treats QKD as a drop-in replacement for cryptography, or skips the baseline and the threat model, revisit Chapter 5 (Measurement and What It Does Not Mean) for the measurement mechanics the protocol relies on, and Chapter 4 (Qubits Without Mysticism) for what a qubit does and does not give you. Then rewrite the memo starting from the assets, not the technology.