Post-quantum cryptography: why "harvest now, decrypt later" is the threat that matters

The interesting fact about quantum computers is not when one becomes useful. It is that the threat does not have to wait. A nation-state intelligence agency, an ISP under court order, or a well-funded criminal group can record your encrypted traffic today, store it on a few cheap petabytes of disk, and decrypt it in 2032 when a cryptographically relevant quantum machine finally exists. The key exchange you used this afternoon is the only thing protecting that recording. If the key exchange falls, the entire conversation falls with it.

This is "harvest now, decrypt later" — HNDL — and it is the one quantum threat that is already happening, in the past tense, every day. Treat it as a current incident, not a future one.

What HNDL actually requires from the attacker

Three things. First, the ability to see and store your encrypted traffic. ISPs, transit providers, sub-sea cable taps, hostile Wi-Fi, and compromised middleboxes all qualify. Second, patience and storage. Encrypted bytes compress poorly but a year of one user's traffic is still measured in tens of gigabytes — a non-issue at scale for any actor that already taps fibre. Third, a future quantum computer large enough to run Shor's algorithm against the key exchange that protected the session. Estimates for that machine range from 2030 to "never," but you do not get to bet on the optimistic end of that range for traffic you sent in 2026.

Notice what is not on the list: the attacker does not need to know who you are today. They can fingerprint and attribute later, when storage is cheap and inference is automated. That is uncomfortable.

What NIST actually finalised in August 2024

After eight years of public competition, NIST published the first three production post-quantum standards:

• ML-KEM (FIPS 203) — Kyber, renamed. A key-encapsulation mechanism. This is the one that replaces the Diffie-Hellman handshake protecting your session keys.
• ML-DSA (FIPS 204) — Dilithium, renamed. A digital signature scheme for authentication: software updates, TLS certificates, identity.
• SLH-DSA (FIPS 205) — SPHINCS+, renamed. A hash-based signature scheme. Slower and larger than ML-DSA, but its security rests only on hash functions, which makes it the conservative backup if a flaw is found in lattice cryptography.

A fourth, HQC, was selected in March 2025 as a code-based KEM backup to ML-KEM. The pattern is intentional: NIST does not want every system on Earth depending on a single mathematical assumption.

Key exchange vs. authentication: not the same problem

Key exchange is what HNDL attacks. If your TLS or WireGuard handshake used classical ECDH (X25519, P-256), and the attacker recorded that handshake, then a future quantum computer recovers the session key and decrypts everything that followed. Replace the key exchange and the recording becomes useless.

Authentication is a different timeline. If your server's certificate is signed with RSA or ECDSA, an attacker with a quantum computer in 2032 can forge a certificate in 2032 — but they cannot retroactively forge a session that already happened. So PQ signatures matter for the future, but PQ key exchange matters for the past. Most rollouts do KEM first for exactly this reason.

Data at rest vs. data in flight

AES with a 256-bit key is not broken by quantum computers. Grover's algorithm cuts brute-force search down to roughly 2^128 operations, which is still infeasible. So your encrypted disk, your password manager vault, and the AES-GCM payload inside your VPN tunnel are fine — assuming the key that protects them was negotiated quantum-safely.

In other words: data at rest with a long symmetric key is mostly OK. Data in flight is only OK if the key exchange that produced its symmetric key was post-quantum. The whole game is the handshake.

How WireGuard is being upgraded

WireGuard's handshake uses Curve25519 ECDH plus a Noise framework construction. It is small, fast, and entirely classical. Several independent forks now exist that splice ML-KEM into the handshake in a hybrid construction — the session key is derived from both the X25519 shared secret and the ML-KEM shared secret, hashed together. If lattice cryptography turns out to have a hidden flaw, you fall back to classical security. If classical ECDH is broken by a quantum machine, you fall back to ML-KEM. You only lose if both break, which is a meaningfully different threat model.

The cost is real but bounded. ML-KEM-768 ciphertexts are about 1,088 bytes versus 32 for X25519 — handshake packets get bigger and may need MTU care. Handshake CPU rises noticeably; once-a-session it is invisible, in tight reconnect loops it shows up.

Where we are

We run our own WireGuard fork. Hybrid X25519 + ML-KEM-768 key exchange is in internal testing now, with a public beta planned for Q3 2026 and default-on for new tunnels by the end of that quarter. Authentication stays classical for a while longer — ML-DSA certificate chains still need ecosystem support we do not control. We are honest about the trade: hybrid PQ does not make any past traffic safer, and it is not a marketing event. It is the only sensible default for the next decade of recordings.

The corporate email you sent at lunchtime today is the one we are thinking about. Not the one you will send in 2032.