BenchmarksStack RankingAPIsPricingDocsWhite PaperTokenBlogAbout
Log InGet API Key
Security NIST · 8 min read

Harvest Now, Decrypt Later
How to Stop It Today, Not in 2035

Adversaries are recording your encrypted traffic right now. They can't read it yet. But when cryptographically relevant quantum computers arrive, they will. The clock isn't starting in 2035 -- it started years ago. Here's what HNDL is, who's doing it, and the only way to eliminate the threat entirely.

What Is Harvest Now, Decrypt Later?

Harvest Now, Decrypt Later (HNDL) is not a theoretical attack. It is a documented, ongoing intelligence-collection strategy in which adversaries capture encrypted network traffic today with the explicit intent of decrypting it once a sufficiently powerful quantum computer becomes available. The encrypted data is stored in bulk -- entire sessions, key exchanges, certificate chains -- waiting for the day when Shor's algorithm can factor the RSA keys or compute the discrete logarithms protecting that traffic in polynomial time.

The fundamental asymmetry of HNDL is what makes it so dangerous: the cost of storage is trivial (roughly $5 per terabyte per month on commodity cloud storage), while the value of the data inside those encrypted sessions can be worth billions. A nation-state actor can record petabytes of encrypted traffic from submarine cable taps, ISP mirrors, or compromised network equipment and simply wait. There is no expiration date on stored ciphertext.

The math is simple: If your data has value beyond the arrival of cryptographically relevant quantum computers (estimated 2030-2035), it is already compromised if it was ever transmitted under classical key exchange. The attack happened when the data was recorded. The decryption is just a formality.

Who Is Doing This?

Multiple intelligence agencies and advanced persistent threat (APT) groups have been documented conducting bulk traffic collection programs. The NSA's own internal documents, disclosed in 2013, described programs for bulk collection of encrypted traffic with the explicit goal of future decryption as computational capabilities advanced. China's Ministry of State Security (MSS) has been linked to massive data exfiltration campaigns targeting healthcare systems, government networks, and defense contractors -- accumulating encrypted data stores measured in exabytes.

Russia's GRU and SVR have conducted sustained network infiltration campaigns that prioritize long-dwell-time access specifically for traffic capture. APT groups linked to these agencies -- APT28 (Fancy Bear), APT29 (Cozy Bear), APT40 (Leviathan), and APT41 (Double Dragon) -- have all demonstrated the operational capability for bulk encrypted traffic capture.

But it is not just nation-states. Organized cybercrime groups are increasingly storing encrypted data as a speculative asset. The cost of capture and storage is negligible. The potential payoff from future decryption of financial records, authentication credentials, and proprietary business communications is enormous.

What Data Is at Risk?

The HNDL threat is not uniform across all data types. The attack only matters for data whose value persists beyond the quantum computing timeline. This creates a clear risk hierarchy:

Data CategorySensitivity WindowHNDL Risk Level
Healthcare records (PHI)Patient lifetime (50+ years)Critical
Government classified data25-75 years (classification duration)Critical
Intellectual property / trade secrets10-30 years (competitive value)Critical
Financial records / transaction data7-25 years (regulatory + legal)High
Biometric templatesLifetime (cannot be changed)Critical
Authentication credentialsRotation period (hours to years)Medium-High
Real-time communicationsImmediate to years (context-dependent)Medium

Healthcare records are perhaps the most alarming category. A patient's medical history, genetic data, and biometric identifiers cannot be rotated like a password. A 30-year-old patient's records captured today will still be sensitive -- and still be the same person's records -- in 2060. Biometric templates share this permanent vulnerability: you cannot change your fingerprints or iris patterns after a breach.

Why TLS 1.3 Alone Does Not Protect Against HNDL

TLS 1.3 was a significant improvement over TLS 1.2. It eliminated legacy cipher suites, mandated perfect forward secrecy (PFS) through ephemeral Diffie-Hellman, and reduced the handshake to a single round trip. Many organizations assume that deploying TLS 1.3 makes them quantum-safe. This is incorrect.

TLS 1.3 provides perfect forward secrecy against classical computers. Each session generates a unique ephemeral key pair, so compromising one session key does not compromise past sessions. However, the ephemeral key exchange in TLS 1.3 uses either ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or DHE (Diffie-Hellman Ephemeral) -- both of which are vulnerable to Shor's algorithm.

The critical point: If an adversary recorded the full TLS 1.3 handshake (including the ephemeral public keys exchanged during ClientHello and ServerHello), a quantum computer can recover the shared secret by solving the elliptic curve discrete logarithm problem. PFS protects against classical key compromise. It does not protect against quantum key recovery from recorded handshakes.

This means every TLS 1.3 session ever recorded is a future quantum target. The forward secrecy guarantee evaporates against a quantum adversary who captured the handshake. The only defense is to replace the key exchange mechanism itself with one that is resistant to quantum attack.

The Solution: Post-Quantum Key Exchange Eliminates HNDL

The definitive countermeasure to HNDL is post-quantum key exchange. Specifically, ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), standardized as FIPS 203, replaces the vulnerable ECDHE or DHE step in the TLS handshake with a lattice-based key encapsulation that is resistant to both classical and quantum attack.

When ML-KEM protects the key exchange, an adversary who records the handshake gains nothing. The shared secret cannot be recovered even with a quantum computer, because the underlying mathematical problem (Module Learning With Errors) has no known efficient quantum algorithm. The recorded ciphertext becomes permanently useless, not temporarily secure.

This is not a mitigation or a risk reduction. It is elimination of the attack vector. If the key exchange is quantum-safe, there is no harvest-now-decrypt-later attack. The "decrypt later" step becomes computationally infeasible regardless of future advances in quantum computing.

FHE Adds a Second Layer of Defense

Post-quantum key exchange stops HNDL at the transport layer. But H33 goes further with Fully Homomorphic Encryption (FHE). Even in a scenario where an attacker somehow compromises the transport layer entirely -- through implementation bugs, side-channel attacks, or advances we cannot predict -- FHE ensures the payload data remains encrypted.

With H33's BFV-based FHE engine, data is encrypted before it ever touches the wire. The server processes encrypted data directly, computes on ciphertext, and returns encrypted results. At no point does plaintext exist outside the client's secure enclave. This is defense in depth taken to its mathematical extreme: even total compromise of the transport layer reveals only encrypted data that requires the client's FHE private key to decrypt.

H33's Approach: PQ by Default on Every API Call

H33 does not offer post-quantum cryptography as an opt-in feature or a premium tier. Every API call to H33 infrastructure is post-quantum protected by default. This includes:

The entire stack runs natively in Rust on AWS Graviton4 ARM infrastructure, with no external cryptographic library dependencies. Every primitive -- from the NTT butterfly operations in BFV to the lattice sampling in ML-KEM -- is implemented, audited, and optimized in-house. The result is 2.17 million authentications per second sustained, at 38.5 microseconds per authentication, with full post-quantum protection on every operation.

QuantumVault: Find Your Vulnerable Endpoints

Knowing that HNDL is a threat is the first step. Knowing which of your endpoints are vulnerable is the actionable step. H33 QuantumVault provides automated scanning of your infrastructure to identify every endpoint still using classical key exchange, every certificate chain relying on RSA or ECDSA, and every API integration transmitting sensitive data under vulnerable encryption.

QuantumVault produces a prioritized remediation report that maps each vulnerable endpoint to the specific H33 product that replaces its classical cryptography with post-quantum equivalents. The scanning runs continuously, so new endpoints added to your infrastructure are automatically assessed against the quantum threat model.

The Timeline Is Already Behind You

NSM-10 (National Security Memorandum 10) mandates federal agencies migrate to post-quantum cryptography by 2035. CNSA 2.0 requires National Security Systems to begin compliance by January 2027. But these deadlines address the migration timeline, not the threat timeline. The threat timeline started when adversaries began recording encrypted traffic -- which, based on disclosed intelligence programs, has been ongoing for over a decade.

Every day that your systems transmit sensitive data under classical key exchange is another day of captured traffic added to an adversary's quantum-decryption backlog. The migration deadline is 2035. The protection deadline was yesterday.

Start protecting your traffic today. H33's post-quantum infrastructure is production-ready, with a free tier that includes full PQ protection on every API call. No migration project required -- just point your API calls at H33 and HNDL becomes a non-issue.

Further Reading