Harvest Now, Decrypt Later: The Quantum Threat That's Already Here

Most discussions about quantum computing and cryptography start with a future tense: quantum computers will break RSA, will compromise ECC, will render current encryption obsolete. The implicit assumption is that the threat is years away.

That assumption is wrong. The attack is happening now.

What Is Harvest Now, Decrypt Later?

Harvest Now, Decrypt Later (HNDL), also called "store now, decrypt later" or "retrospective decryption", is a strategy where an adversary captures encrypted network traffic today and stores it. The data is unreadable now. But when a sufficiently powerful quantum computer becomes available, the adversary can retroactively decrypt everything they've collected.

This isn't theoretical. Intelligence agencies and advanced persistent threat (APT) groups have the infrastructure to capture and store massive volumes of encrypted traffic at scale. The NSA's Utah Data Center, for example, was designed with storage capacity measured in exabytes.

Why This Changes the Timeline

The standard quantum threat model asks: "When will quantum computers be powerful enough to break RSA?" Estimates range from 2030 to 2040. That feels like plenty of time.

HNDL flips the question: "How long does my data need to stay confidential?"

If the answer is longer than the time until quantum computers arrive, you're already exposed. Consider:

• Healthcare records: HIPAA requires protection for the lifetime of the patient (potentially 50+ years)
• Financial data: Trade secrets, M&A communications, and strategic plans have multi-decade sensitivity
• Government classified data: Often classified for 25 to 75 years
• Legal communications: Attorney-client privilege has no expiration
• Intellectual property: Source code, patents-in-progress, and R&D data may be valuable for decades

If quantum computers arrive in 2035 and your data needs to stay confidential until 2050, then traffic captured today is at risk. The exposure window is already open.

Who Is Doing This?

HNDL is primarily a nation-state concern, but the barrier to entry is dropping. The attack requires two capabilities:

1. Traffic capture at scale: Tapping fiber optic cables, compromising ISPs, or positioning at internet exchange points. Well-documented capabilities of major intelligence agencies.
2. Long-term storage: Storing petabytes of encrypted traffic is expensive but feasible. Storage costs continue to drop roughly 20% per year.

The Snowden disclosures in 2013 confirmed that the NSA was already collecting encrypted traffic at scale. It's reasonable to assume that China's MSS, Russia's FSB, and other capable agencies are doing the same — and have been for years.

Which Protocols Are Vulnerable?

Not all encrypted traffic is equally at risk. The vulnerability depends on the key exchange mechanism:

• RSA key exchange (TLS 1.2 and earlier): The server's RSA private key encrypts the session key. If the private key is later factored by a quantum computer, every session ever encrypted with that key can be decrypted. This is the worst case.
• ECDHE / DHE key exchange: Ephemeral Diffie-Hellman provides forward secrecy, so each session uses a unique key. However, the ephemeral DH exchange itself relies on the discrete logarithm problem, which Shor's algorithm also solves. A quantum attacker can still break individual sessions, but must attack each one separately.
• TLS 1.3: Mandates ephemeral key exchange, so forward secrecy is guaranteed. But the underlying ECDHE is still quantum-vulnerable.

Forward secrecy helps (it prevents bulk decryption from a single compromised key) but doesn't eliminate the HNDL threat. Only quantum-resistant key exchange does.

What You Can Do Today

The good news: you don't need to wait for a complete PQC migration to reduce your HNDL exposure. Practical steps you can take now:

1. Inventory your cryptographic exposure

You can't prioritize what you can't see. Map every certificate, every TLS configuration, every key exchange algorithm across your infrastructure. Identify which services handle long-lived sensitive data.

2. Eliminate RSA key exchange immediately

If any of your services still use RSA key exchange (as opposed to ECDHE_RSA or DHE_RSA), fix this today. It's the single highest-risk configuration because it lacks forward secrecy entirely.

3. Enable TLS 1.3 everywhere possible

TLS 1.3 eliminates RSA key exchange and mandates forward secrecy. It's the best protection available with current standards while PQC key exchange is being deployed.

4. Begin hybrid PQC key exchange pilots

Chrome and Cloudflare already support hybrid key exchange (X25519 + ML-KEM). This combines a classical and quantum-resistant algorithm so that the connection is secure against both classical and quantum attackers. Start testing this in non-production environments.

5. Prioritize by data sensitivity, not by compliance deadline

Compliance frameworks will eventually mandate PQC. But HNDL doesn't wait for compliance timelines. If you handle data that needs to stay confidential for 10+ years, your migration priority should be based on data sensitivity, not regulatory deadlines.

The Cost of Waiting

Every day you run quantum-vulnerable key exchange on services handling sensitive data, you're adding to the stockpile a future attacker can decrypt. The data captured today cannot be un-captured. There is no retroactive fix for traffic that's already been harvested.

The organizations that will be in the best position when quantum computers arrive are the ones that started their cryptographic inventory and migration planning years before they had to.