The quantum threat isn’t future tense. It’s present tense.
Nation-state intelligence agencies are recording encrypted internet traffic right now — TLS sessions, VPN tunnels, encrypted emails, classified communications. They can’t decrypt it today. But they’re storing it, waiting for quantum computers capable of running Shor’s algorithm to break RSA and ECC.
When that day comes (estimates range from 2030-2040), every recorded session becomes readable. Trade secrets negotiated in 2024. Medical records transmitted in 2025. Government communications from 2026. Financial transactions. Legal privileged communications. Anything encrypted with RSA or ECC key exchange that was captured on the wire.
This is “Harvest Now, Decrypt Later” (HNDL) — and it’s not theoretical. It’s documented intelligence strategy.
How HNDL Works
TODAY (2026):
Alice ←→ Bob: TLS 1.3 connection (X25519 key exchange, AES-256 data)
Eve (nation-state): records the entire TLS session (ciphertext + handshake)
Eve cannot decrypt (X25519 ECDHE is secure against classical computers)
FUTURE (2035?):
Eve has a cryptographically-relevant quantum computer
Eve runs Shor's algorithm against the recorded X25519 key exchange
Eve recovers the shared secret from the handshake
Eve derives the AES session keys
Eve decrypts the entire recorded session
Eve reads Alice and Bob's 2026 communication in plaintextCritical detail: AES-256 (symmetric) is quantum-safe. The vulnerability is in the key exchange (ECDHE, RSA) — not the bulk encryption. If Eve can break the key exchange, she recovers the symmetric key, which decrypts everything.
What Data Is at Risk
Not all data needs protection for decades. HNDL is a threat only for data that remains sensitive long after transmission:
High Risk (Sensitive for 10-25+ years)
| Data Type | Sensitivity Duration | HNDL Risk |
|---|---|---|
| Government classified communications | 25-75 years | CRITICAL |
| Trade secrets and IP | 10-20 years | HIGH |
| Medical records (HIPAA) | Lifetime of patient | HIGH |
| Legal privileged communications | Indefinite | HIGH |
| Financial M&A negotiations | 5-10 years | HIGH |
| Personal genetic data | Lifetime | HIGH |
| Military/intelligence operations | 25-50 years | CRITICAL |
Low Risk (Short-lived sensitivity)
| Data Type | Sensitivity Duration | HNDL Risk |
|---|---|---|
| E-commerce transactions | Days (until settled) | LOW |
| Session tokens | Hours | NONE |
| Streaming media | None | NONE |
| Public website content | None | NONE |
| Ephemeral messaging (if truly ephemeral) | Minutes | LOW |
The Question to Ask
For every encrypted data flow: “If this communication were decrypted in 10 years, would it matter?”
If yes → you need quantum-safe key exchange now. If no → current encryption is sufficient for the data’s lifetime.
Evidence That HNDL Is Happening
Public Statements
- NSA (2015): Announced plans to transition to quantum-resistant algorithms, citing “the threat of quantum computing.” This implicitly acknowledges the HNDL threat.
- CNSA 2.0 (2022): NSA mandates quantum-safe algorithms for national security systems by 2030-2033. The urgency implies the threat is real and imminent.
- NIST (2016-2024): Ran a 8-year competition to standardize post-quantum algorithms. The investment level ($100M+) indicates serious threat assessment.
Intelligence Community Indicators
- Massive investment in undersea cable tapping infrastructure (documented by Snowden leaks, 2013)
- Internet exchange point (IXP) monitoring programs
- Cloud provider data requests (legal and extralegal)
- Satellite communication interception
Storage Economics
Storing encrypted traffic is cheap and getting cheaper:
- 1 TB of storage: ~$20/month (cloud) or ~$15 one-time (HDD)
- A targeted organization’s TLS traffic: ~1-10 GB/day
- 10 years of storage for one target: ~$500-$5,000 total
For a nation-state intelligence budget ($50B+ annually for the US alone), storing decades of encrypted traffic for thousands of targets is trivially affordable.
What You Can Do Today
1. Enable Hybrid Key Exchange (Immediate)
Modern browsers and servers already support hybrid key exchange — combining classical ECDHE with post-quantum ML-KEM:
TLS 1.3 Hybrid Key Exchange:
Classical: X25519 (128-bit classical security)
+ Post-Quantum: ML-KEM-768 (NIST Level 3 quantum security)
= Combined shared secret (secure against both classical AND quantum)Chrome: Enabled X25519+ML-KEM-768 by default since Chrome 124 (2024) Cloudflare: Supports hybrid key exchange on all connections AWS: CloudFront supports hybrid TLS
Server-side (Nginx with OpenSSL 3.x + oqs-provider):
# Enable hybrid key exchange groups
ssl_ecdh_curve X25519MLKEM768:X25519:P-256;
# Clients that support hybrid will negotiate ML-KEM
# Clients that don't will fall back to X25519 (still classically secure)2. Protect Data at Rest with AES-256 (Immediate)
AES-256 provides 128-bit security against quantum computers (Grover’s algorithm halves the effective key length). This is still computationally infeasible.
# Ensure all data-at-rest encryption uses AES-256 (not AES-128)
# AES-128 → 64-bit post-quantum security (potentially vulnerable)
# AES-256 → 128-bit post-quantum security (safe)
# Check your current encryption:
cryptsetup luksDump /dev/sda2 | grep cipher
# Should show: aes-xts-plain64 with 512-bit key (= AES-256 for XTS mode)3. Build a Cryptographic Inventory (CBOM)
You can’t protect what you can’t see. Identify every system using quantum-vulnerable key exchange:
Quantum-vulnerable (need migration):
- TLS connections using ECDHE or RSA key exchange (without hybrid PQ)
- SSH connections using ECDH or DH key exchange
- VPN tunnels using IKEv2 with ECDH
- Any key exchange based on factoring (RSA) or discrete log (DH, ECDH)
Quantum-safe (no action needed):
- AES-256 symmetric encryption (data at rest)
- SHA-256/SHA-384 hashing
- HMAC-SHA256 authentication
- Any symmetric-only operation4. Prioritize by Data Sensitivity
Not everything needs quantum-safe protection immediately:
Priority 1 (NOW): Government/military communications, trade secrets, healthcare data
Priority 2 (2026-2027): Financial services, legal communications, long-term contracts
Priority 3 (2028-2029): General enterprise data, customer communications
Priority 4 (2030+): Everything else (by then, PQC will be standard)5. Plan for Full PQC Migration
The complete migration (replacing all RSA/ECC with post-quantum algorithms) will take years. Start planning now:
- Inventory all cryptographic assets (CBOM)
- Test PQC algorithms in non-production (larger keys, different performance characteristics)
- Upgrade libraries and HSMs to versions supporting PQC
- Deploy hybrid mode first (classical + PQ), then PQ-only
- Verify with updated CBOM showing reduced quantum risk
The Timeline Question: When Will Quantum Computers Break Crypto?
| Source | Estimate | Confidence |
|---|---|---|
| NIST | ”Within 20 years” (stated 2016) → ~2036 | Medium |
| NSA/CNSA 2.0 | Mandates PQC by 2030-2033 (implies threat before then) | High |
| IBM | 100,000 qubit system by 2033 (may not be enough for crypto) | Medium |
| Demonstrated quantum supremacy (2019) but not for crypto | Low (for crypto timeline) | |
| Academic consensus | 2035-2045 for cryptographically-relevant QC | Medium |
| Optimistic estimates | 2030 (some researchers) | Low |
The honest answer: Nobody knows exactly when. But the migration takes 5-10 years for large organizations. If quantum computers arrive in 2035, you need to start migrating by 2025-2030. We’re in that window now.
FAQ
Q: If I use TLS 1.3 with forward secrecy, am I safe from HNDL? A: No. Forward secrecy (ECDHE) protects against future compromise of the server’s long-term key — but the ephemeral ECDHE key exchange itself is quantum-vulnerable. A quantum computer can break the recorded ECDHE exchange and recover the session keys. You need hybrid (ECDHE + ML-KEM) for quantum safety.
Q: Is AES-256 encrypted data safe from HNDL? A: Data encrypted with AES-256 at rest is quantum-safe (128-bit post-quantum security). But if the AES key was exchanged using RSA or ECDH (e.g., TLS session), the key exchange is the vulnerability — not the AES encryption itself.
Q: Should I be worried if I’m not a government target? A: Depends on your data’s long-term sensitivity. If you handle trade secrets, healthcare data, financial records, or legal communications that remain sensitive for 10+ years — yes, HNDL is relevant. If your data is only sensitive for days/weeks (e-commerce, session data) — the risk is minimal.
Q: Can I just re-encrypt everything later with PQC? A: Data at rest: yes, you can re-encrypt with quantum-safe algorithms later. Data in transit: no — once it’s been transmitted and recorded, you can’t “un-transmit” it. The recording exists. This is why protecting data in transit with hybrid key exchange matters NOW, not later.
Q: What’s the cost of enabling hybrid key exchange? A: Minimal. Hybrid TLS adds ~1KB to the handshake (ML-KEM public key + ciphertext) and ~0.1ms of computation. For most applications, this is unnoticeable. The main barrier is library/server support — which is rapidly improving (OpenSSL 3.x, BoringSSL, Cloudflare, AWS already support it).