Harvest Now, Decrypt Later: Whose Data Needs Post-Quantum Crypto First

The attack that doesn't need a quantum computer

Harvest now, decrypt later (HNDL) is the core threat model of post-quantum security, and what makes it frightening is that the attack happens today:

1. An adversary records your encrypted traffic or ciphertext now (fiber taps, log leaks, stolen backups all qualify)
2. The data sits quietly on their storage, waiting for practical quantum hardware
3. When that day comes, Shor's algorithm breaks the RSA/ECDH key exchange recorded years ago, and the entire historical plaintext unwinds

The expensive step — the quantum computer — can be bought last. Which means the deadline isn't "the year quantum computers ship"; it's "the year your recorded data stops mattering".

Which algorithms are on the list

The quantum threat to classical cryptography is selective, a distinction popular explainers routinely blur:

So PQC migration replaces public-key cryptography (key exchange and signatures) while symmetric crypto and hashes mostly need a parameter check — which is why the NIST family (ML-KEM / ML-DSA / SLH-DSA) lives entirely in those two categories.

The priority formula: risk = data lifetime × sensitivity × interceptability

Three factors multiply; any one near zero collapses the risk. Use them to rank your systems:

Move first (long lifetime × high sensitivity)

• Medical and genomic data (histories, sequencing results — lifetimes in decades)
• Government and judicial archives
• Long-horizon financial records and identity data
• Communication metadata and stored message content
• Long-lived signatures (root certificates, code-signing roots, notarized timestamps)

Can relax (short lifetime or hard to intercept)

• Per-session TLS traffic with ephemeral session keys — with one HNDL exception: if the key exchange itself was recorded, forward secrecy does not protect the past. This is exactly why hybrid TLS still matters
• Archives already protected by AES-256 where keys never travel through public-key wrapping
• Public content (already visible to everyone)

One sentence: quantum risk doesn't hit all your data, only the part that lives long enough and hides deep enough.

Migration order: key exchange first, signatures later

The cost-benefit ranking is clear:

1. TLS hybrid key exchange (X25519+ML-KEM) — a server-side toggle in most stacks, browsers already default to it, and it covers all future interception in one move (how-to in the migration checklist)
2. Certificates and signing — later not because it matters less but because it costs more: ML-DSA signatures run ~2.4KB (Ed25519 is 64 bytes), certificate chains bloat accordingly, and the CA trust fabric has to be rebuilt — that doesn't rush
3. Data at rest — confirm AES-256 with key management that bypasses RSA/ECC wrapping, and most of the backlog is already safe

For compliance-driven stacks: SM suites and PQC stack, not compete

Teams running Chinese cryptographic compliance (miping, see the self-check checklist) often ask how SM2/SM3/SM4 relate to PQC. They're parallel tracks:

• SM2's mathematical foundation (elliptic curves) is squarely inside Shor's blast radius — the SM family gets no quantum exemption
• Compliance runs the SM track; HNDL assessment for long-lived secrets adds the PQC track on top
• TLCP (Chinese-crypto HTTPS) and TLS 1.3 hybrid will likely converge on the same hybrid deployment shape over time

Critical-infrastructure operators writing "PQC readiness" into their cryptography master plan are getting ahead of the next assessment cycle.

Implementer's note

Building the AES tool, I added explicit GCM-nonce-reuse guards — but the HNDL lens adds a different question: where did the key come from? Keys generated locally via crypto.subtle come from the system CSPRNG and never pass through public-key wrapping, so browser-local symmetric ciphertext never enters the HNDL ledger. What's dangerous is the hybrid pattern of "RSA-wrap the AES key, then transmit" — that RSA envelope is the decryption doorway ten years from now. The lesson from hashing vs. encryption holds once more: understanding what each primitive actually protects beats chasing algorithm names.

Related reading

• Post-quantum migration self-check: 12 items
• Hash collisions, explained
• RSA encryption, explained properly