Cryptography Foundations · Part 8 of 8·Anonymity Engineering·2026-05-02·16 min read·advanced

Post-quantum cryptography in transit

Why TLS and QUIC are migrating to post-quantum key agreement now: ML-KEM, ML-DSA, hybrid X25519+ML-KEM, harvest-now-decrypt-later, and what 2026 deployment actually looks like.

A sufficiently large quantum computer would break Curve25519, RSA, ECDSA, Ed25519, and every other public-key system whose security rests on discrete logarithms or integer factoring. The good news is that no such computer exists in 2026, and informed estimates put working cryptographically-relevant quantum machines at least a decade away — possibly several. The bad news is that adversaries can capture today's encrypted traffic and store it for decryption later, the moment the necessary hardware becomes available. Confidentiality with a long shelf life — diplomatic cables, intellectual property, medical records — is already exposed even though the cryptographic break hasn't happened yet. This module is the foundational pass through what's actually being deployed in response: hybrid post-quantum key exchanges in TLS and QUIC, why authentication migration lags, and what the concrete engineering costs are.

Prerequisites

Module 1.11 — TLS 1.3 handshake byte by byte. Most of the post-quantum deployment story is about TLS handshakes.
Module 2.4 — Asymmetric crypto. The classical algorithms being protected against and replaced.
Module 2.5 — Digital signatures. The authentication side of the migration story.
Module 2.6 — Key derivation: HKDF and friends. Hybrid handshakes combine classical and post-quantum outputs through KDFs.

Learning objectives

By the end of this module you should be able to:

Explain "harvest now, decrypt later" and articulate why it changes the urgency of public-key migration even before working quantum computers exist.
Distinguish ML-KEM (key encapsulation, FIPS 203) from ML-DSA (signatures, FIPS 204) and explain why both standards exist in parallel.
Describe the engineering tradeoffs of hybrid X25519+ML-KEM key agreement in TLS and QUIC — handshake size, latency, middlebox compatibility.
Explain why post-quantum signature deployment lags post-quantum key-exchange deployment.
Recognize what a modern browser actually negotiates with a major CDN in 2026, and why "post-quantum cipher suites" require ecosystem changes beyond just enabling a new algorithm.

What the quantum threat actually targets

Quantum computers run different algorithms than classical computers, and only some of those algorithms break cryptography. The two relevant results:

Shor's algorithm (1994) factors integers and computes discrete logarithms in polynomial time on a sufficiently large quantum computer. This breaks:

RSA (relies on factoring being hard).
Diffie-Hellman over finite fields (relies on discrete-log being hard).
Elliptic-curve Diffie-Hellman (relies on discrete-log on the curve being hard).
ECDSA, Ed25519 (signatures based on curve discrete-log).

In other words: every public-key primitive currently deployed in TLS, SSH, X.509, code signing, and basically every secure transport is vulnerable to Shor's algorithm.

Grover's algorithm (1996) provides a quadratic speedup for unstructured search. Concretely, it lets a quantum computer brute-force an n-bit symmetric key in roughly 2^(n/2) operations instead of 2^n.

The implication for symmetric primitives:

AES-128 → effectively 64-bit security under Grover. Not catastrophic but reduced.
AES-256 → effectively 128-bit security. Comfortable margin.
SHA-256 → preimage resistance reduces from 2^256 to 2^128. Still safe.
SHA-256 collisions → reduce from 2^128 to ~2^85. Still safe.

The pragmatic guidance for symmetric and hash primitives in a post-quantum world is essentially: use longer keys. AES-256 instead of AES-128. SHA-384 or SHA-512 instead of SHA-256. None of this requires new algorithms, just slightly larger parameter choices.

The difficult part is asymmetric. There's no AES-256 equivalent for RSA: you can't make it post-quantum-secure by going to RSA-8192. The math itself is broken under Shor. Asymmetric cryptography requires entirely new algorithms based on different hard problems — lattice-based cryptography, code-based cryptography, hash-based signatures.

Why migration starts before the computer exists

The seductive answer is "wait until quantum computers are real." The actual answer is that several factors force action now:

Harvest now, decrypt later. A patient adversary records today's encrypted traffic. They store it. When quantum computing matures in 2035 or 2040, they decrypt the archive. Anything in that archive whose confidentiality matters past the quantum-availability date is already lost. State actors are widely believed to be doing this; commercial adversaries may also.

The concrete implication: if you're encrypting data today that needs confidentiality through 2040 — diplomatic communications, medical records, trade secrets, intellectual property — you have to migrate to post-quantum now. The window to break that confidentiality with future quantum hardware is the rest of your data's required lifespan.

Software supply chain inertia. Migrating cryptographic primitives across the deployed ecosystem takes years. Browser updates, server software, embedded devices, hardware tokens, smart cards, IoT firmware, payment systems. Each has its own update cycle. Even in a hypothetical world where everyone agrees to migrate today, full ecosystem rollout is a 5-10 year project. Starting in 2026 means finishing well before the quantum-availability date arrives.

Infrastructure replacement timelines. PKI hardware (HSMs, TPMs, smart cards) often has 5-10 year deployment cycles. Replacing them post-2030 is an emergency project; replacing them as part of normal refresh cycles starting now is routine. Aligning the migration with existing infrastructure-replacement timelines is much cheaper than treating it as a separate emergency.

Compliance pressure. Major buyers (governments, regulated industries) are starting to require post-quantum support in vendor contracts. Even if you don't believe in the threat, the procurement contracts will eventually force the migration anyway.

The unifying observation: the quantum-availability date is uncertain, but the migration cost is paid now regardless. Companies that wait pay it as an emergency rather than as a planned upgrade. Pragmatic deployments are starting in 2025-2027 to be done by 2032-2035.

ML-KEM and ML-DSA in plain language

The 2015-2024 NIST Post-Quantum Cryptography Standardization Project took a decade to evaluate dozens of submissions and pick winners. The final standards:

ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, FIPS 203, 2024). Formerly known as Kyber during the competition. A Key Encapsulation Mechanism (KEM) is a primitive where the sender produces a ciphertext containing a shared secret; the receiver decapsulates the ciphertext (using their private key) to recover the same secret. Functionally, this is what ECDH does, with a slightly different API.

ML-KEM comes in three parameter sets:

ML-KEM-512 — ~128-bit security. Public key ~800 bytes, ciphertext ~768 bytes.
ML-KEM-768 — ~192-bit security. Public key ~1184 bytes, ciphertext ~1088 bytes. The currently-deployed default in browser-to-CDN hybrid handshakes.
ML-KEM-1024 — ~256-bit security. Public key ~1568 bytes, ciphertext ~1568 bytes.

ML-DSA (Module-Lattice-based Digital Signature Algorithm, FIPS 204, 2024). Formerly known as Dilithium. A signature scheme. Three parameter sets:

ML-DSA-44 — ~128-bit security. Public key ~1312 bytes, signature ~2420 bytes.
ML-DSA-65 — ~192-bit security. Public key ~1952 bytes, signature ~3293 bytes.
ML-DSA-87 — ~256-bit security. Public key ~2592 bytes, signature ~4595 bytes.

For comparison, classical:

X25519 public key: 32 bytes. ECDH ciphertext: 32 bytes.
Ed25519 public key: 32 bytes. Ed25519 signature: 64 bytes.

The size differences are the engineering reality of post-quantum: public keys 25-100× larger; signatures 35-70× larger. Every byte of these primitives travels in handshakes, certificates, and protocol messages, and the costs add up quickly.

Both ML-KEM and ML-DSA are based on lattice problems — specifically, the Module-LWE (Learning With Errors) problem and Module-SIS (Short Integer Solution) problem. These problems are not believed to be vulnerable to Shor's algorithm or Grover's algorithm. The cryptographic confidence in lattices comes from substantial academic study; they're the mainstream choice among post-quantum primitives in 2026.

A third NIST standard worth mentioning: SLH-DSA (FIPS 205, 2024), formerly SPHINCS+. A hash-based signature scheme — built only on cryptographic hashes, no number theory. Stateless, conservative, very large signatures (~7-50 KB). Used as a backup option where lattice cryptanalysis-progress causes concern.

Hybrid deployment as the transition plan

Real-world post-quantum deployment in 2026 is almost universally hybrid: combine a classical primitive with a post-quantum one, derive the session key from both. Why?

Defense in depth. If lattice cryptography turns out to have a flaw — unlikely but not impossible — the classical half still provides security against today's adversaries. If Shor's algorithm becomes practical sooner than expected — also unlikely — the post-quantum half still provides security. The session is broken only if both halves fail.

Interoperability. Many deployments don't yet support post-quantum at all. A hybrid that includes a classical fallback can negotiate with both legacy and modern peers; pure post-quantum requires both ends to be upgraded.

Gradual rollout. Hybrid lets you turn on post-quantum support without committing to it as the only option. As the ecosystem matures, the classical half can be dropped.

The standard hybrid construction for TLS:

shared_secret = X25519_secret || ML_KEM_secret

The two outputs are concatenated and run through HKDF as TLS 1.3 normally would. The handshake exchanges both an X25519 public key (32 bytes) and an ML-KEM-768 ciphertext (1088 bytes) in the same key_share extension.

The IETF code point for this is X25519MLKEM768 (formerly named X25519Kyber768Draft00 during the standardization period). Cloudflare and Google rolled out X25519Kyber768 starting in 2023; both transitioned to the FIPS-finalized X25519MLKEM768 in 2024-2025. Chrome, Firefox, and Safari all support it as of mid-2025.

When you connect to cloudflare.com or google.com from a modern browser in 2026, the negotiated key exchange is, in many cases, X25519MLKEM768. The TLS 1.3 ClientHello includes ML-KEM-768 public-key bytes; the ServerHello returns the matching ciphertext. The session is post-quantum-protected against harvest-now-decrypt-later for as long as both halves of the hybrid hold.

TLS and QUIC deployment reality

The size cost of ML-KEM-768 public keys (~1184 bytes) plus ciphertexts (~1088 bytes) plus the rest of the ClientHello is real:

ClientHello bloat. A pre-PQ TLS 1.3 ClientHello might be 600-1200 bytes. With X25519MLKEM768 added, it grows to ~2400-3000 bytes. This is bigger than the typical Initial QUIC packet (1200 bytes) and bigger than many middleboxes' handshake-handling assumptions. Some middleboxes drop oversized ClientHellos; others fragment them and handle the fragments wrong.

TCP segment fragmentation. A 2500-byte ClientHello doesn't fit in one Ethernet MTU; it spans two TCP segments. If one is lost, the other has to wait for retransmission. Marginal extra latency on lossy links.

QUIC Initial packet splitting. QUIC's Initial packets are constrained to 1200 bytes by spec. A hybrid post-quantum ClientHello has to span multiple Initial packets. The QUIC standards in 2024 added explicit mechanisms for this; not all stacks handle it equally well.

Latency overhead. The post-quantum operations themselves are fast — ML-KEM-768 encapsulation/decapsulation on modern x86 takes ~50-100 microseconds. But the larger handshake means more bytes on the wire, which on long-RTT paths produces noticeable extra time-to-first-byte.

Cloudflare's post-quantum deployment notes are the canonical operational evidence on what it took to roll out hybrid PQ at internet scale. The summary: it works, the size cost is manageable, but specific middleboxes and older stacks broke and required workarounds.

Authentication is the harder half

Key exchange migrated first because it's the immediate harvest-now-decrypt-later problem. Authentication migration is the bigger ecosystem challenge for several reasons:

Certificate sizes. An ML-DSA signature is 2-4 KB; an Ed25519 signature is 64 bytes. A typical X.509 certificate today is 1-2 KB; with ML-DSA it'd be 4-8 KB. A full chain (server cert + intermediate + root) is 3-6 KB today; with ML-DSA it'd be 12-25 KB. Every TLS handshake transmits the chain. The bandwidth cost is substantial.

Public-key sizes. ML-DSA public keys are 1.3-2.5 KB. They live in certificates and travel with them. CT log entries grow correspondingly.

Long-tail compatibility. Code-signing systems, package managers, S/MIME email, JWT-based auth, and dozens of other deployed signature usages all need their certificate chains updated. Some of those systems have 5-10 year refresh cycles.

HSM and hardware support. PKI HSMs and smart cards need firmware updates or replacements to support PQ signature operations. Banks and governments are slow to roll these.

Verification cost. ML-DSA verification is computationally expensive — much more than RSA-PSS or ECDSA verification. Edge devices, IoT, and constrained clients feel this.

The current 2026 industry guidance: migrate key exchange to hybrid post-quantum now; defer authentication migration until certificate ecosystems are ready (2027-2030). The harvest-now-decrypt-later threat applies to confidentiality, not authentication. An attacker who breaks a 2024 Ed25519 signature in 2035 can't usefully forge a signed certificate from 2024 — by 2035, the certificate has long since expired.

HPKE and the wider ecosystem

HPKE (Hybrid Public Key Encryption, RFC 9180) is the modern KEM-based encryption framework underlying ECH, OHTTP, and several other protocols. It's been parameterized with post-quantum KEMs alongside classical ones.

When ECH (Encrypted Client Hello — Module 1.11) advertises that it supports KEM = X25519MLKEM768, that's HPKE with a hybrid post-quantum KEM. Browser-server ECH with PQ KEM provides post-quantum-protected SNI hiding, in addition to the regular TLS handshake's PQ key exchange.

The ecosystem-wide trend: post-quantum KEMs are showing up everywhere a classical KEM previously did. TLS, QUIC, ECH, OHTTP, MLS (group messaging), Signal (still using X3DH classical, with a PQ extension in development), VPN protocols (WireGuard's PSK extension, IPsec PQ-IKEv2 drafts).

Where the standards stand now

In 2024, NIST finalized:

FIPS 203 — ML-KEM (lattice-based KEM).
FIPS 204 — ML-DSA (lattice-based signatures).
FIPS 205 — SLH-DSA (hash-based signatures, conservative backup).

In 2025-2026, IETF produced:

TLS 1.3 PQ key exchange code points for X25519MLKEM768 and friends.
HPKE PQ KEM extensions.
QUIC negotiation behavior for handshakes that span multiple Initial packets.
PQ X.509 work is ongoing; production-ready signed-with-ML-DSA certificate ecosystems are still being established.

Browser support timeline:

Chrome — X25519Kyber768Draft00 enabled by default in 2023; switched to X25519MLKEM768 in 2024.
Firefox — X25519MLKEM768 enabled in 2025.
Safari — X25519MLKEM768 in iOS/macOS releases starting late 2024.

If you connect from a current browser to Cloudflare, Google, Apple, or several other major CDNs in 2026, the connection is most likely using hybrid post-quantum key exchange. The HTTPS lock icon is structurally the same, but the bytes underneath are different.

Hands-on exercise

Exercise 1 — Compare key and signature sizes

"""Compare classical vs post-quantum key/signature sizes."""

# Sizes from the published standards, in bytes.
sizes = {
    "X25519 public key":        32,
    "X25519 ECDH ciphertext":   32,
    "Ed25519 public key":       32,
    "Ed25519 signature":        64,
    "ECDSA P-256 public key":   65,
    "ECDSA P-256 signature":    72,    # DER-encoded
    "RSA-2048 public key":      270,   # SPKI DER
    "RSA-2048 signature":       256,
    "ML-KEM-768 public key":    1184,
    "ML-KEM-768 ciphertext":    1088,
    "ML-DSA-65 public key":     1952,
    "ML-DSA-65 signature":      3293,
    "SLH-DSA-128s signature":   7856,  # SPHINCS+ small
}

print(f"{'Primitive':<35} {'Bytes':>8}")
for name, n in sizes.items():
    print(f"{name:<35} {n:>8}")

# Useful comparisons
print()
print(f"ML-KEM-768 public key is {1184 / 32:.0f}× larger than X25519")
print(f"ML-DSA-65 signature is   {3293 / 64:.0f}× larger than Ed25519")
print(f"ML-DSA-65 public key is  {1952 / 32:.0f}× larger than Ed25519")

Run it. Notice the orders of magnitude. A handshake that swaps Ed25519 for ML-DSA grows the signature alone by ~3.2 KB. Add ML-DSA public keys for the certificate chain, and you've added ~10 KB of bytes to a TLS handshake.

Stretch: estimate how many extra TCP segments a typical ClientHello plus full PQ certificate chain might require. Standard MTU 1500, TCP/IP overhead ~40 bytes, max payload per segment ~1460 bytes. A ~25 KB handshake spans 17-18 segments instead of 2-3 for a classical handshake. The bandwidth difference shows up most painfully on cellular and lossy links.

Exercise 2 — Inspect what your browser actually negotiates

Open a modern browser and visit https://cloudflare.com. Open DevTools → Security panel → connection details. Look for the Connection section.

You should see:

TLS version: 1.3.
Key exchange: typically X25519MLKEM768 (the X25519 + ML-KEM-768 hybrid). On older browsers without PQ support, just X25519.
Cipher: ChaCha20-Poly1305 or AES-GCM.

Try several major sites — Google, Apple, GitHub. Most CDN-hosted sites in 2026 negotiate hybrid PQ. Sites hosted on legacy infrastructure may still use plain X25519.

Now try from a slightly older browser (or a recent browser with PQ disabled in flags). The connection still works, falls back to classical X25519. The hybrid is opt-in and degrades gracefully.

If your browser doesn't show the negotiated key-exchange method, run openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 and look at the Server Temp Key line. Note: requires OpenSSL 3.5+ for ML-KEM support.

Common misconceptions

"Post-quantum means replace everything with one new algorithm." Different primitive roles migrate at different speeds. KEMs (ML-KEM) for confidentiality have rolled out first; signatures (ML-DSA) are slower because of certificate-ecosystem inertia. AES and SHA-2 mostly need parameter increases, not replacement. Hybrid deployment is the reality for years.

"Hybrid mode is redundant if one algorithm is enough." Hybrid is the practical hedge during transition. Either of the two algorithms could turn out to have a flaw — a recent lattice-cryptanalysis breakthrough, or a faster Shor implementation than expected. Combining them means both have to fail before the connection is broken. The cost is small; the safety margin is real.

"Post-quantum TLS is just a software switch." Handshake size, middlebox compatibility, certificate chains, and client support all complicate deployment. Cloudflare's rollout took years and required workarounds for specific broken middleboxes. Every CA and HSM vendor has to update their toolchains. None of this is automatic.

"If ML-KEM is standardized, signatures are solved too." PQ key exchange and PQ authentication have very different deployment costs. ML-DSA signatures are 35-70× larger than Ed25519. Certificate chains, code-signing infrastructure, and HSM support all need to be updated. KEMs migrated quickly because the cost is per-handshake; signatures migrate slowly because the cost is built into every certificate.

"Quantum risk means AES and hashes are dead too." Symmetric crypto is mostly fine. Grover's algorithm gives a quadratic speedup, halving effective security. AES-256 stays at ~128-bit strength against a quantum adversary, which is comfortable. SHA-256's preimage resistance similarly stays at 128 bits. Use AES-256 and SHA-384 in post-quantum-leaning deployments and you're fine. The asymmetric primitives are the ones being replaced; symmetric is just being parameter-tuned.