Field notes · Post-quantum · Risk
Harvest now, decrypt later: is your data already exposed?
Why data encrypted today can be read by tomorrow's quantum computers, how to use Mosca's inequality to tell whether you're already late, and what to fix first.
Most conversations about quantum computers and cryptography start with a date: when will a machine big enough to break RSA and elliptic-curve cryptography exist? Nobody knows, and that uncertainty makes it tempting to wait. For a large class of data, waiting is already the wrong call.
The attack that has already started
An adversary doesn’t need a quantum computer today to benefit from one later. They only need to record encrypted traffic now and store it. When a cryptographically relevant quantum computer arrives, Shor’s algorithm breaks the key exchange that protected that traffic (RSA or elliptic-curve Diffie-Hellman), and everything recorded becomes readable.
This is “harvest now, decrypt later.” It means the deadline for protecting data in transit isn’t the day the quantum computer arrives. It’s that day minus however long the data needs to stay secret.
Mosca’s inequality
Michele Mosca, a quantum computing researcher at the University of Waterloo, put this into a simple test. Estimate three numbers:
- X: how many years your data must stay confidential (its shelf life)
- Y: how many years it will take you to migrate to quantum-safe cryptography
- Z: how many years until a quantum computer can break today’s public-key cryptography
If X + Y > Z, you have a problem. Some of the data you protect today will still matter when it can be decrypted, or you won’t finish migrating in time, or both.
Take a health insurer whose records must stay private for 25 years, with a realistic five-year migration. Even if you think a quantum computer is 20 years away, 25 + 5 > 20: the insurer is already a decade late. A marketing team whose campaign data is stale after one year has far more room.
You can run your own numbers with our quantum risk calculator.
What to fix first
Harvest-now, decrypt-later is a threat to confidentiality, so it shapes priorities differently from forged signatures:
- Key exchange on long-lived data paths. TLS, VPN and messaging links that carry data with a long shelf life. Hybrid key exchange, combining a classical algorithm with ML-KEM (NIST FIPS 203), protects new sessions even if one of the two is broken. Major browsers and CDNs already support it.
- Stored data encrypted under public keys. Backups and archives whose encryption keys are wrapped with RSA or ECDH. Symmetric encryption like AES-256 is not meaningfully threatened; the wrapping is.
- Signatures come next. A forged signature requires a quantum computer at the moment of the attack, so signature migration can follow, except for long-lived roots of trust and firmware, which take years to replace in the field.
Start with an inventory
None of this is possible without knowing where your public-key cryptography lives: in code, in certificates, in hardware security modules, in vendor products and in protocols you didn’t write. That inventory is almost always the first deliverable of a migration, and it’s usually where the surprises are.
If you’d like help working out your X, Y and Z, or building that inventory, get in touch.