Why 'harvest now, decrypt later' is driving post-quantum crypto adoption

A sufficiently large quantum computer doesn't exist yet. Encrypted traffic from 2018 might already be sitting on a tape, waiting for one. That asymmetry — encrypt now, decrypt later — means the damage starts when the recording happens, not when the machine arrives.

The picture version

Six pictures for a reader who has never thought about quantum computers, following one ordinary thing: a VPN session you opened in 2018 and never thought about again.

Why it exists

Think back to a VPN session you opened in 2018 to read work email from a hotel or an airport. It was encrypted; you never thought about it again. But encryption doesn’t stop anyone from recording the ciphertext, and copying traffic is cheap. Somewhere — a stack of LTO tapes in a warehouse, the bulk-collection storage of a state-level adversary — there may well be a copy of that session sitting untouched.

That 2018 session is the running example for this post. Follow it forward.

Nobody can read it today. The TLS handshake agreed on a key using elliptic-curve Diffie-Hellman, and recovering that key would mean solving a discrete-log problem classical computers can’t solve at the relevant sizes. But “can’t solve today” and “can’t solve ever” are different claims. If a sufficiently large quantum computer is ever built — five years from now, fifteen, fifty — that tape becomes plaintext. The encryption was real. The recording was always allowed.

That asymmetry — encrypt now, decrypt later — is why the migration to PQC is happening on a timeline that has nothing to do with when the threat actually arrives. The adversary doesn’t need a quantum computer in 2026. They need a hard drive in 2026 and a quantum computer eventually. The people building the systems we trust today are already losing that race for any traffic with a long secrecy lifetime — diplomatic cables, medical records, source-code repositories, the contents of corporate VPN tunnels — and the only fix is to change the math before the recording stops being hypothetical.

The shorthand for this threat model is harvest now, decrypt later (HNDL; sometimes “store now, decrypt later”). It’s the reason “we have time” is a worse argument than it sounds. The clock you care about isn’t when quantum arrives — it’s how long you need yesterday’s secrets to stay secret, minus the gap between today and quantum. For some workloads that arithmetic is already negative.

Why it matters now

The standards finally exist. On August 13, 2024, NIST published the first three finalized post-quantum standards as Federal Information Processing Standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) (NIST announcement). Before that, shipping post-quantum crypto meant shipping a draft: every deployment listed below went out against pre-standard Kyber. What August 2024 changed is that there was finally a fixed target to build against — which is why the Chrome entry below describes a second rollout, swapping the draft scheme for the standardized one.

A non-exhaustive snapshot:

• Signal rolled out PQXDH in 2023, upgrading the X3DH initial handshake to combine X25519 with CRYSTALS-Kyber in hybrid mode.
• Apple announced PQ3 for iMessage on February 21, 2024, a hybrid post-quantum messaging protocol that shipped with iOS 17.4 and macOS 14.4.
• Cloudflare enabled hybrid post-quantum key agreement (X25519Kyber768) for general availability across its edge in September 2023; by March 2024 nearly 2% of TLS 1.3 connections to Cloudflare were post-quantum secured, mostly via Chrome.
• Chrome shipped X25519Kyber768 by default in Chrome 124 (May 2024), then in Chrome 131 (late 2024) swapped the draft Kyber for the standardized ML-KEM — still as a hybrid pairing with X25519 (X25519MLKEM768), not as pure post-quantum.

Notice what every one of those has in common: none of them replaced the classical algorithm. They all run the new post-quantum piece alongside the old one. That’s hybrid mode, and the reason for it is the single most interesting decision in this whole migration — we’ll get to why below.

The short answer

post-quantum urgency = long-lived secrets + adversary patience + Shor's algorithm someday

Picture to keep: a warehouse of sealed envelopes nobody can open, stacked beside an empty loading bay marked key-cutting machine — arriving someday. Nothing in the warehouse changes while you wait. The bay is what eventually gets filled, and every envelope opens at once.

Public-key crypto as it’s deployed today (RSA, classical Diffie-Hellman, ECC) rests on math problems that classical computers can’t solve at the sizes we use. Shor’s algorithm, published by Peter Shor in 1994, solves all of them in polynomial time on a sufficiently large quantum computer. Such a computer doesn’t exist yet, and — as the section below lays out — nobody can say when one will. But anyone who records ciphertext today and waits has a free option on it. The migration is to algorithms whose hardness isn’t broken by Shor — mostly based on lattice problems — before that option pays out.

How it works

The clearest way to see why the migration looks the way it does is to walk the obvious responses in order and watch each one fail. Keep your 2018 tape in mind throughout.

Naive response 1: “wait until quantum exists, then swap algorithms”

This is how we handle most cryptographic deprecations — MD5, SHA-1, RC4 all got years of “stop using it” before anyone was actually broken.

Why it breaks: those were attacks on future traffic. Break SHA-1 and old signatures get suspect, but yesterday’s confidential conversations stay confidential. Shor is retroactive. The day the machine works, your 2018 tape is readable, and there is no action available in that moment that changes it — the ciphertext left your control eight years earlier. Any secret whose lifetime exceeds (time until quantum) minus (time to migrate) is already lost if it’s being recorded. And migration is not fast: it means new standards, new library versions, new hardware in some cases, propagating across every TLS stack, VPN, and embedded device on earth.

Naive response 2: “just use bigger keys”

That’s the standard answer to advancing hardware, and for one whole half of cryptography it’s the correct answer.

Why it breaks — and where it works: Shor’s algorithm isn’t faster brute force. It efficiently solves two specific structured problems on a quantum computer: integer factoring and discrete logarithm. That happens to cover essentially all deployed public-key crypto — RSA rests on factoring, classical Diffie-Hellman on discrete log mod a prime, ECC on discrete log over an elliptic curve (Shor handles the curve case too). Doubling an RSA modulus doesn’t help against an algorithm that isn’t searching.

Symmetric crypto is a different story. AES, ChaCha20, and SHA-256 are not broken by Shor. The best known quantum attack there is Grover’s algorithm, which gives roughly a square-root speedup on brute-force key search — and against that, “double the key length” is exactly right. AES-256 retains roughly 128 bits of security against Grover, which is fine. This is why the migration is loud about key exchange and signatures and quiet about AES: the bulk encryption you do after the handshake is already safe. It’s the handshake that breaks.

How far away is the machine, actually?

Nowhere close. Published factoring demonstrations on real quantum hardware involve tiny numbers, with caveats about how much of the work the quantum processor genuinely did. Resource estimates for RSA-2048 are a different universe: the widely cited Gidney & Ekerå estimate puts it at roughly 20 million noisy physical qubits running for about 8 hours with surface-code error correction (paper). A 2025 follow-up by Gidney (arXiv:2505.15917) cuts the qubit count sharply — to under a million — but buys it with a longer runtime, on the order of a week rather than hours. Either way, still far beyond anything that exists.

The honest gap: nobody knows when a cryptographically relevant quantum computer will exist. Credible public estimates span roughly a decade to “never,” and anyone naming a precise year is guessing. That uncertainty is the point rather than an objection — it’s exactly why the harvest-now framing decides the schedule. You can’t wait for the threat to be observable, because by the time it is, your 2018 traffic has already been read.

Naive response 3: “fine — switch to the new quantum-safe algorithm”

“Nobody knows when” cuts both ways, though. It’s an argument against complacency — and also against betting everything on a single new scheme, because the same uncertainty applies to the replacements.

Why it breaks: the lattice problems underneath the new schemes are old and well-studied, but the schemes are young, and deploying one to a billion devices is younger still. The cautionary tale is SIKE: an isogeny-based KEM that NIST had advanced as a fourth-round candidate, until Castryck and Decru published an efficient classical key-recovery attack on SIDH — the structure SIKE is built on — in August 2022. Follow-up implementations recovered keys in about an hour on a single core. NIST dropped it. The lesson isn’t “PQC is broken” — it’s that real-world cryptanalytic mileage on these schemes is far shorter than on RSA, and surprises remain possible.

The fix — hybrid mode: run the post-quantum KEM alongside a classical one (typically X25519) and mix both into the shared secret. If lattice crypto has an unknown weakness, X25519 still stops a classical attacker; if quantum arrives, the lattice half holds. It’s a bet that “either of these holds” beats either alone, and it’s why every deployment listed above shipped hybrid rather than pure PQC.

Why lattices, and what got standardized

The leading family — the one that landed in FIPS 203 and 204 — is lattice-based. A lattice is the set of points you get from integer combinations of a few basis vectors in high-dimensional space (a wallpaper pattern, but in 768 dimensions). The hard problem: given a “messy” basis, find the shortest non-zero vector, or find a lattice point very close to a given target. No polynomial-time quantum algorithm is known for these, and they’ve been studied since the 1980s, which is why NIST built its first KEM and signature standards on them.

ML-KEM (standardized CRYSTALS-Kyber) is a key encapsulation mechanism built on Module Learning With Errors, whose algebraic structure keeps keys and ciphertexts compact. ML-DSA (CRYSTALS-Dilithium) is a signature scheme on related lattice problems. The third standard, SLH-DSA (SPHINCS+), is hash-based — its security rests only on hash functions like SHA-256 being hard to invert and collision-resistant, the most conservative assumption in cryptography. The trade-off is that its signatures are large and slow. NIST standardized it as the belt-and-suspenders backup in case lattice cryptanalysis takes a bad turn.

NIST made the same bet again on the encryption side. On March 11, 2025 it selected HQC as a fifth algorithm — a KEM built on error-correcting codes rather than lattices, explicitly a backup to ML-KEM rather than a replacement for it, with a draft standard out for comment and a final expected in 2027. Read that as the standards body agreeing with the argument two sections up: the danger isn’t lattices specifically, it’s having only one basket.

Bring the tape back for a moment: whichever of these your VPN had used in 2018, the recording would be worthless — not because lattices are magic, but because Shor’s two tricks don’t apply to any of them. That’s the entire substitution being made.

Naive response 4: “migrate everything, then”

Why it breaks: you have finite engineering attention, and the two halves of public-key crypto are not equally urgent. This is the distinction that decides where the effort goes.

A KEM agrees the symmetric key protecting the rest of the conversation. Record that handshake, break the KEM later, and you recover the key and therefore the whole conversation. HNDL hits the KEM directly — that’s your 2018 tape, and it’s why the messaging-app and TLS rollouts all started with key exchange.

Signatures work the other way. Forging a 2018 signature in 2040 requires the signer’s key, but a 2040 attacker who breaks the scheme can already forge new signatures on future documents — and that’s the attack that matters (a forged signature on a malicious software update, not a retroactively forged old one, which usually buys nothing). So the clock on signatures is when quantum arrives, not how long your secrets stay secret — which is a different clock, not a later one. Where a signature has to still be trusted decades from now — a secure-boot root fused into silicon, a code-signing anchor shipped in an installed base you can’t reach, a long-term timestamp — “before quantum arrives” means before you ship the device, because that’s your last chance to touch it. That asymmetry is why TLS deployments led with KEMs and have moved more slowly on PQ certificate signatures, and why firmware and secure-boot roots are the signature case people are migrating first.

Show the seams

• Sizes change everything downstream. Ed25519 signatures are 64 bytes. ML-DSA-65 signatures are 3,309 bytes and its public key 1,952 bytes (liboqs algorithm table). Multiply by the certificates in a TLS chain and the handshake grows meaningfully. Chrome’s initial X25519Kyber768 rollout hit interop bugs in middleboxes precisely because the ClientHello no longer fit in one packet. Hardware tokens with tight storage budgets (some TPMs, some smart cards) need rework, not a software update.
• The timeline is genuinely unknown, and that’s load-bearing. Nobody has a defensible year — see the estimates above — so the claim this post rests on is structural instead: if it happens, harvested traffic is exposed retroactively, and migration takes years to propagate — so starting now is rational under almost any timeline assumption, including pessimistic ones.
• “Quantum-safe” is a claim about known attacks. Lattice hardness is a conjecture, like factoring hardness was. SIKE is the reminder that a finalist can die in an afternoon.

You started with post-quantum urgency = long-lived secrets + adversary patience + Shor's algorithm someday. What did the four dead ends add? — + the migration is scheduled by your secrets' shelf life, not by quantum's arrival date — and, for the signatures that have to keep verifying long after the machine shows up, by the last date you can still touch the device. That single reframing explains all of it: why hybrid rather than pure, why KEMs before signatures, and why “we have time” is an argument about the wrong clock.

Check yourself

Before you go — your company signs software updates with ECDSA. A colleague argues this is a five-alarm HNDL emergency: an adversary is recording your signed releases right now and will forge them once quantum lands. Are they right?

And: a team ships pure ML-KEM with no classical X25519 alongside, reasoning that hybrid is transitional clutter and ML-KEM is a NIST standard. What did they give up?

Famous related terms

• Shor’s algorithm — Shor's = quantum algorithm + period-finding via QFT → factoring + discrete log in poly time. The reason public-key crypto needs replacing.
• Grover’s algorithm — Grover's ≈ quantum brute-force search with sqrt speedup. Why symmetric crypto only needs longer keys, not new algorithms.
• ML-KEM (Kyber) — ML-KEM = lattice-based KEM + Module-LWE hardness assumption + small ciphertexts. The standardized post-quantum KEM (FIPS 203); how it gets wired into a TLS key exchange is specified separately, at the IETF.
• ML-DSA (Dilithium) — ML-DSA = lattice-based signature + Module-LWE/SIS + Fiat-Shamir. The standardized post-quantum signature (FIPS 204).
• SLH-DSA (SPHINCS+) — SLH-DSA = stateless hash-based signature + Merkle trees of one-time signatures. The conservative-assumption backup standard (FIPS 205).
• Hybrid key exchange — hybrid = classical KEM (X25519) + post-quantum KEM (ML-KEM) + combine into one shared secret. The pattern every deployment named above shipped.
• HNDL — HNDL = adversary records ciphertext now + decrypts later when quantum arrives. The threat model that puts the clock on the recording rather than on the machine.
• Public-key crypto — the layer being replaced. The interface stays similar; the math underneath changes.

Going deeper

• Peter Shor, Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1994/1996) — for the question “what exactly does a quantum computer do that a classical one can’t, and why does it hit factoring and discrete log at once?”
• Cloudflare Research, The state of the post-quantum Internet — for the question “how much of this is actually deployed, and what broke on the way?”, written from a vantage point that sees a real slice of global TLS.
• Castryck & Decru, An efficient key recovery attack on SIDH (2022) — the rabbit hole: for the question “how does a NIST finalist die in an afternoon?”, and why every deployment shipped hybrid instead of pure.

Three things this post deliberately doesn’t tell you, because nobody can. When a cryptographically relevant quantum computer arrives: credible public estimates run from about a decade to “never,” and no year is defensible. Which post-quantum scheme survives another decade of cryptanalysis: that is what cryptanalysis is for, and SIKE is the reminder. And what fraction of the internet has migrated: there is no census — the figures above come from the operators who publish their own numbers, which is a real vantage point and not a global one.