Skip to content

CONCEPT Cited by 3 sources

Harvest-now, decrypt-later (HNDL)

Definition

Harvest-now, decrypt-later (also store-now-decrypt-later / steal-now-decrypt-later) is the threat model in which an adversary captures encrypted traffic today and stores it indefinitely, intending to decrypt it years later once a CRQC exists and can break the classical asymmetric primitives that established the session keys.

Any protocol whose confidentiality depends on classical key-agreement (RSA-KEX, Diffie-Hellman, ECDH) is vulnerable to this retroactive attack — TLS before PQ hybrid, SSH before PQ KEM, IPsec IKE, any raw Noise/WireGuard instance still using X25519 alone. The attacker does not need a CRQC now — only the patience to keep the ciphertext.

Why the deployment schedule is set by session lifetime

The standard PQ-rollout calculus:

Deploy PQ encryption before:   earliest(Q-Day) − max(session data lifetime)

If captured TLS traffic today contains data that is still sensitive in 2040, and a CRQC could plausibly exist by 2030, then PQ encryption must be deployed now — regardless of when the CRQC actually materialises. The calendar is driven by the floor on Q-Day and the retention value of leaked plaintext, not by the most-likely CRQC date.

Canonical quote:

An attacker could save encrypted sessions now and, if a suitable quantum computer is built in the future, decrypt them later. This is known as a 'store now, decrypt later' attack. (Source: sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github)

Scope: KEM / key-agreement, not signatures

HNDL is only a confidentiality problem. It applies to the key-exchange primitives that negotiate session keys. It does not apply to digital signatures:

  • An attacker cannot retroactively forge a signature over past traffic — the past is fixed. Signatures are a live-attack threat, not a historic-capture threat.
  • This is why PQ KEM rollout proceeded ahead of PQ signature rollout across the industry (TLS X25519MLKEM768 / SSH sntrup761x25519-sha512 before ML-DSA certificates).

See concepts/post-quantum-authentication for why the priority flips once Q-Day is close.

Who captures the traffic?

The HNDL threat model names an adversary with traffic-capture capability:

  • Nation-state signals-intelligence agencies — the canonical HNDL actor; bulk-collection programs are the exact shape HNDL assumes.
  • Cloud / network providers in the path — less commonly discussed but structurally the same.
  • Malicious BGP peers / passive wiretap / compromised middleboxes.
  • An insider with tap access to enterprise transit.

The attack does not require active MITM — passive capture is sufficient because modern key-exchange sends enough public data (DH / ECDH public keys, KEM ciphertexts) on the wire for a future attacker with a CRQC to recover the session key.

The HNDL → authentication priority flip

HNDL's dominance as the primary threat depends on Q-Day being far away. Once a CRQC is near-term:

  • Far-Q-Day world: HNDL is the dominant concern. Any captured-today ciphertext decrypts when Q-Day arrives. Priority: PQ key-agreement (KEMs) by default.
  • Near-Q-Day world: Attackers can now do active attacks — impersonate servers, forge credentials. This is much worse than retroactive decryption because it grants live access. Priority inverts: PQ authentication (signatures) + disable classical + rotate secrets — see concepts/post-quantum-authentication.

But HNDL does not go away in the near-Q-Day regime; it compounds:

  • An attacker with a scalable (fast, cheap) CRQC may still prefer HNDL to active attacks — because live forgeries are detected as anomalies, while historic-decryption-of-captured- traffic stays covert. Sophie Schmieg's Enigma analogy: the valuable capability is the one the adversary keeps secret. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

This is why Cloudflare's 2022-onward PQ-KEM-by-default deployment was on-the-right-track even as the 2026 priority flip to PQ authentication becomes urgent — both threats remain live across the transition window.

What PQ-KEM-by-default buys

Deploying hybrid KEM (classical + PQ) on the session-establishment path means:

  • Today's captured ciphertext no longer decrypts under a future CRQC — the CRQC only breaks the classical half of the hybrid; the PQ half still protects confidentiality.
  • Legacy clients continue to work via algorithm negotiation — but their sessions are still HNDL-vulnerable. Only PQ-capable clients get the protection.
  • >65 % of human traffic to Cloudflare was PQ-encrypted by early 2026 (source) — the rest is mostly older clients and not-yet-upgraded origins.

HNDL outside TLS / SSH

The threat applies equally to:

  • VPN / site-to-site protocols — IPsec IKE, WireGuard, OpenVPN handshakes. Cloudflare IPsec GA'd hybrid ML-KEM per draft-ietf-ipsecme-ikev2-mlkem on 2026-04-30 with Cisco 8000 Series + Fortinet FortiOS branch-connector interop; this closes the HNDL gap for enterprise site-to-site WAN traffic four years after TLS.
  • Messaging protocols — Signal protocol (which added PQXDH hybrid in 2023), Matrix Olm, WhatsApp / iMessage (vendor-specific PQ rollouts underway).
  • Federated identity — OIDC / SAML assertions protected in transit by TLS; the encapsulated tokens themselves may have their own lifetime.
  • File encryption at rest where the key-wrapping asymmetric primitive is classical — though this is architecturally harder because the asymmetric key is often long-lived (see concepts/long-lived-key-risk).

Seen in

  • sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga — canonical site-to-site / IPsec instance. Cloudflare's 2026-04-30 IPsec PQ GA names HNDL explicitly as the motivating threat: "Cloudflare IPsec now uses post-quantum encryption with hybrid ML-KEM (FIPS 203) to stop harvest-now-decrypt-later attacks. These are attacks where an adversary harvests data today and then decrypts later, after Q-Day, when there are powerful quantum computers that can break the classical public key cryptography used across the Internet." Extends HNDL mitigation scope from TLS (2022) and SSH (2025) to enterprise WAN / site-to-site IPsec — enterprise traffic between branches, data centres, and cloud VPCs is now also HNDL-protected when tunnelled through Cloudflare IPsec with PQ-capable branch connectors.
  • sources/2025-09-15-github-post-quantum-security-for-ssh-access-on-github — explicit HNDL framing as the motivating threat for GitHub's SSH PQ-KEM rollout (sntrup761x25519-sha512 on github.com + non-US GHEC). Definition quote: "An attacker could save encrypted sessions now and, if a suitable quantum computer is built in the future, decrypt them later."
  • sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security — HNDL as the historically-dominant concern Cloudflare already mitigated (PQ encryption by default since 2022, >65 % of human traffic PQ-encrypted); the 2026 priority flip to authentication explicitly frames HNDL as necessary-but-no-longer-sufficient. Sophie Schmieg's Enigma analogy for why a scalable-CRQC attacker might still prefer HNDL (stealth).
Last updated · 542 distilled / 1,571 read