Harvest Now, Decrypt Later: Why Your Cloud Credentials Are Already a Quantum Target

In 2013, leaked NSA documents revealed that intelligence agencies had been systematically collecting encrypted internet traffic — not because they could decrypt it at the time, but because they believed they eventually would.^[1] The strategy was simple: if you can't read the message today, save it until you can.

This is the essence of the Harvest Now, Decrypt Later (HNDL) attack. It doesn't require breaking encryption today. It requires only the patience to store encrypted data until the cryptographic foundation it rests on can be broken — and a credible path to that capability.

Quantum computers provide that path. Not today. But possibly within the decade. And for cloud infrastructure teams managing long-lived credentials — AWS access keys, SSH private keys, database passwords, OAuth tokens — "within the decade" is already a planning horizon that matters.

Why Cloud Credentials Are Prime HNDL Targets

Not all encrypted data is equally valuable to an HNDL attacker. Short-lived session tokens, one-time codes, and ephemeral secrets offer little value — by the time they can be decrypted, they'll have long expired. But attackers are specifically interested in data that will remain valuable after decryption, years from now.

Cloud infrastructure credentials meet that criteria almost perfectly:

• Long operational lifetimes. AWS IAM access keys are often created once and rotated infrequently, sometimes lasting years. SSH private keys for server access can persist across multiple server generations. A credential captured today in encrypted form may still be valid and valuable when decrypted in 2034.
• High post-decryption value. An AWS key that grants access to production infrastructure is not just historically interesting — it could grant real access to production systems if rotation hasn't occurred since the credential was captured.
• Concentrated in management layers. Cloud management platforms — which aggregate credentials from multiple cloud accounts into a single store — are particularly attractive collection targets. A single successful exfiltration of a management platform's encrypted credential store could yield access to hundreds of cloud environments.

The Quantum Timeline: What We Actually Know

Quantum computing timelines are notoriously difficult to predict, and the field is full of both hype and skepticism. For security planning purposes, the relevant question is not "when will a quantum computer exist?" — various forms of quantum computers exist today — but "when will a cryptographically relevant quantum computer (CRQC) exist?" A CRQC is one capable of running Shor's algorithm on the key sizes used in production cryptography (2048-bit RSA, 256-bit ECC) in a practical timeframe.

The key insight from this timeline is that the most important decisions are being made now, before quantum computing becomes relevant. Standards are finalized. Government agencies have set deadlines. Organizations that have already encrypted long-lived credentials with classical algorithms — and haven't migrated — are accumulating technical debt with a hard expiration date.

Why Classical Encryption Breaks Under Quantum Attack

To understand why post-quantum cryptography is necessary, it helps to understand why current encryption algorithms are vulnerable to quantum computers specifically.

Most public-key cryptography in use today — RSA, Diffie-Hellman, and Elliptic Curve Cryptography (ECC) — derives its security from mathematical problems that are computationally hard for classical computers: integer factorization (RSA) and the discrete logarithm problem (ECC, DH).

In 1994, mathematician Peter Shor published an algorithm showing that a sufficiently capable quantum computer could solve both of these problems in polynomial time — meaning the difficulty of these problems essentially disappears for a quantum attacker.^[2]

This doesn't affect symmetric encryption like AES in the same way. Grover's algorithm gives quantum computers a quadratic speedup against symmetric ciphers — meaning AES-256 offers roughly 128 bits of quantum security rather than 256. This is why AES-256 remains recommended under post-quantum standards: a 128-bit quantum security level is still practically unbreakable.

Post-Quantum Cryptography: The Defense

Post-quantum cryptography (PQC) refers to classical cryptographic algorithms — run on conventional computers — that are designed to remain secure against attacks from both classical and quantum adversaries. Unlike RSA and ECC, PQC algorithms are based on mathematical problems for which no efficient quantum algorithm is known.

NIST finalized three PQC standards in August 2024:

• FIPS 203 — ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism): The primary standard for key encapsulation — used to protect symmetric keys and by extension any data encrypted with them. ML-KEM-768 is the recommended parameter set for most applications.
• FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm): The primary standard for digital signatures.
• FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm): An alternative signature standard based on hash functions, providing diversity in the algorithm portfolio.

These algorithms are based on problems in lattice mathematics — specifically the Learning With Errors (LWE) problem and its variants — for which the best known algorithms (classical or quantum) require time that grows exponentially with problem size.^[3]

The Hybrid Construction: Defending Against Two Adversary Classes Simultaneously

A critical implementation decision for any organization migrating to post-quantum cryptography is whether to replace classical algorithms outright or use a hybrid construction — combining a post-quantum algorithm with a classical one in a way that requires both to be broken for the protection to fail.

NSA CNSA 2.0 and NIST SP 800-227 both recommend hybrid constructions during the transition period. The rationale is sound: ML-KEM is new, and while it has been analyzed extensively, post-quantum algorithms haven't accumulated the decades of real-world cryptanalytic scrutiny that RSA and AES have. A hybrid construction hedges against the possibility that PQC algorithms have unforeseen weaknesses:

// Hybrid key derivation: both keys must be compromised to decrypt
shared_secret_pq  = ML-KEM-768.decapsulate(sk_pq, kem_ciphertext)
classical_master  = AES-256 key (classical)
key_enc_key       = HKDF-SHA-256(
    ikm  = shared_secret_pq XOR classical_master,
    info = "hybrid-kek-v2"
)
encrypted_payload = AES-256-GCM(key_enc_key, data)

In this construction, a classical adversary (today) cannot decrypt without shared_secret_pq. A quantum adversary (tomorrow) cannot decrypt without classical_master. The security proof requires breaking both simultaneously.

What to Protect First: A Prioritization Framework

Not every organization can migrate all encryption to PQC immediately. The most practical approach is to prioritize by the combination of sensitivity and longevity of the data being protected.

For cloud infrastructure operators, the priority order is clear:

1. Cloud provider API keys and OAuth tokens — Grant direct control of cloud accounts. Often long-lived. Highest value post-decryption. Protect first.
2. SSH private keys for server access — Direct shell access to infrastructure. Can persist for years. Protect alongside API keys.
3. Database connection strings and credentials — Access to production data. High longevity risk.
4. Environment variables and application secrets — Variable longevity, but often contain long-lived third-party API keys.
5. Session tokens and short-lived credentials — Lowest priority. By design, these expire before any CRQC timeline. Classical protection is acceptable.

The prioritization principle: if the secret will still be valid and useful in 10 years, it needs post-quantum protection today.

Performance and Practical Considerations

A common concern when evaluating PQC migration is performance overhead. ML-KEM-768 key sizes are larger than classical equivalents — a public key is 1,184 bytes versus 32 bytes for X25519 — and key generation and encapsulation operations add latency.

In practice, for data-at-rest credential protection, this overhead is immaterial. ML-KEM-768 encapsulation and decapsulation operations complete in under 300 microseconds on modern server hardware. At typical cloud management platform scales — encrypting and decrypting credential fields on API requests — PQC adds under 5 milliseconds of total latency at the 99th percentile.

The storage overhead is approximately 1.2 KB per encrypted credential (compared to ~100–200 bytes for AES-only). For organizations storing thousands of credentials, this is a matter of kilobytes — not a practical concern.

Mosca's Theorem: When Is "Now" Actually Late?

Security researcher Michele Mosca formalized the urgency calculation for PQC migration with what's known as Mosca's Theorem:^[5]

If the time to migrate your cryptographic systems (t) plus the time until a CRQC arrives (y) is less than the sensitivity lifetime of your data (x), then you have a security problem today — not in the future.

For cloud infrastructure credentials: if a credential's sensitivity lifetime is 10 years, and a CRQC might arrive in 8 years, then any organization that hasn't begun migration already is behind.

The theorem doesn't require precise timelines — it reframes the question. Instead of asking "when will quantum computers arrive?", ask: "how long does my most sensitive data need to remain confidential?" If the answer is longer than the expert consensus on CRQC arrival, the migration needs to start now.