"Harvest now, decrypt later" — why the quantum clock is already running
Adversaries are recording encrypted data today and storing it until a quantum computer can break the encryption — so anything with a multi-year confidentiality lifetime is already exposed, even though the quantum computer doesn't exist yet.
It's tempting to treat quantum computing as a "someday" problem: the machine that can break RSA-2048 hasn't been built, so why migrate now? The answer is that encryption has to protect data for as long as the data is sensitive — and for a lot of data, that's many years.
How the attack works
Most internet traffic is protected by public-key cryptography (RSA, elliptic-curve) during the handshake that sets up a session. That handshake is the part a future quantum computer breaks. The attack is simple and patient:
- Record. An adversary captures encrypted traffic now — a nation-state tapping a fiber line, a leaked database backup, intercepted VPN sessions.
- Store. Disk is cheap. They archive the ciphertext and the recorded key-exchange.
- Decrypt later. Once a cryptographically-relevant quantum computer exists, they run Shor's algorithm against the stored handshakes, recover the session keys, and read everything retroactively.
Why "later" still means "act now"
The math that matters is Mosca's inequality: if the time your data must stay secret (X) plus the time it takes you to migrate (Y) is greater than the time until a quantum computer arrives (Z), you're already too late. For data with a 10–25 year confidentiality requirement, X alone blows past most estimates of Z.
Who has data like that? More people than you'd think:
- Health and genomic records (sensitive for a lifetime)
- Legal, financial, and M&A documents
- Government and defense communications, classified material
- Long-lived credentials, signing keys, and firmware roots of trust
- Anything covered by long-tail regulatory retention requirements
What actually fixes it
NIST finalized the post-quantum replacements in August 2024: ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) / SLH-DSA (FIPS 205) for signatures. The practical migration path is:
- Key exchange first. This is the only part with retroactive risk, so it's the priority. Adopt hybrid key exchange (e.g. X25519 + ML-KEM) so a session is safe if either half holds.
- Signatures next. Forgery needs a live quantum computer — there's no harvest-now risk — so this trails key exchange. Move long-lived roots of trust earlier.
- Inventory before you migrate. You can't fix what you can't see. The first step every framework asks for is a cryptographic inventory.
See which quantum-vulnerable algorithms are in a codebase right now — free, no signup.
Scan a repo →