# Harvest Now, Decrypt Later

> Someone is keeping your handshakes

By Zsolt Bizderi · Published 2026-09-20
Canonical: https://ambientnode.uk/harvest-now-decrypt-later

Harvest now, decrypt later means recording encrypted traffic today and decrypting it years later, once a quantum computer is able to break the key exchange that protected it. The attack does not need an exploit or access / interaction, since passive collection is enough.

Forward secrecy protects against the server's long-term private key being compromised later. Under old TLS RSA key transport, the client encrypted the premaster secret to the server's certificate key, so anyone who recorded the traffic and later stole that one key could decrypt every session it ever protected. Ephemeral Diffie-Hellman managed to fix that by generating a throwaway key pair per session and discarding it afterwards, so there is no stored key to steal.

But the quantum case doesn't need a stored key. The ephemeral public keys are sent in the clear in the handshake, because both sides need them to derive the shared secret. Shor's algorithm recovers the private value from the public one that is already in the recording. So discarding the private key after the session doesn't help here, because the attacker just regenerates it from the capture.

***

## Shor and Grover

Assymetric encyption: Shor's algorithm turns factoring and discrete log into a period-finding problem, which a quantum computer can work through quickly. RSA, Diffie-Hellman and elliptic curve are all built on those two problems, so one algorithm takes out all three. Classically you stay safe by adding bits, since the time to break a key grows faster than the key does. Shor flattens that, and a 2048-bit RSA key goes from impossible to a few hours. The hardware to run it does not exist yet, but every time someone publishes a better version of the algorithm the number of qubits needed drops.

Symmetric encryption: Grover's algorithm is brute force with a shortcut. It gets through the possible keys in roughly the square root of the attempts, so a 256-bit key that needs 2^256 guesses classically needs about 2^128 with Grover. Halving sounds bad, but 2^128 is still nowhere near reachable, and Grover does not split across machines the way classical brute force does, so throwing more hardware at it does not help.

***

## The HNDL mechanism

A TLS 1.3 handshake agrees a session key using an ephemeral key exchange, usually X25519. The client sends its public key, the server sends its own, then both sides derive the same shared secret, and everything after that is AES-GCM / ChaCha20. The public keys go over the wire in the clear as expected.

Anyone recording the connection captures both public keys and the entire encrypted session. Today, that capture is useless, since deriving the shared secret from the two public keys means solving the discrete log problem. Shor's algorithm solves it. Given a large enough fault-tolerant quantum computer, the recorded public keys yield the private scalar, then the private scalar yields the shared secret, and the shared secret yields the session keys for the recording.

Symmetric encryption is in a different position, as Grover's algorithm halves effective key strength, AES-256 drops to \~128 bits and AES-128 becomes weaker, but not broken. For harvest now, decrypt later the key exchange is the crown jewel, as those public keys are inside the capture and the whole session depends on the secret.

So in short: Shor kills asymmetric, Grover weakens symmetric without breaking it.

***

## Hybrid TLS

X25519MLKEM768 runs both algorithms in one key share. The client sends an ML-KEM-768 encapsulation key alongside its X25519 public key, the server encapsulates against one and completes the classical exchange with the other, and the final secret is the concatenation of both outputs fed into the TLS key schedule.

![](/media/ae365696-edf2-4744-9c26-9ed6a43aaf5f/1280.webp)

Breaking the session requires breaking both. Shor against X25519 gets an attacker half of the input to the key schedule, which, without the second half is worth nothing on its own. ML-KEM is new and based on module lattices, and no quantum algorithm is known that breaks it. The reason we keep X25519 is that ML-KEM might have a classical flaw nobody has found yet.

## Testing it yourself

OpenSSL 3.5 (LTS, April 2025) includes ML-KEM and the hybrid group. To see what the server negotiates:

```
$ openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
    | grep -i "negotiated"
Negotiated TLS1.3 group: X25519MLKEM768
```

Comparing this against the classical group:

```
$ openssl s_client -connect cloudflare.com:443 -groups X25519 </dev/null 2>/dev/null \
    | grep -i "negotiated"
Negotiated TLS1.3 group: X25519
```

If you only offer hybrid to a server that does not support hybrid groups, it cannot complete the handshake, so this can be a usable readiness test across an environment:

```
$ openssl s_client -connect legacy.example.com:443 -groups X25519MLKEM768 </dev/null
...alert handshake failure
```

A normal client offers several groups at the same time and the server would fall back to its supported group otherwise.

An X25519 client key share is 32 bytes. The hybrid share is 1216 bytes, since the ML-KEM-768 encapsulation key is 1184 bytes with the X25519 public key appended. The server's reply goes from 32 bytes to 1120, carrying the 1088-byte ML-KEM ciphertext.

Capture it and measure:

```
$ sudo tcpdump -i any -w pq.pcap 'tcp port 443'  
$ tshark -r pq.pcap -Y "tls.handshake.type == 1" -T fields -e frame.len \
    -e tls.handshake.extensions_key_share_group  
```

The key\_share extension has the group code point, 0x11ec for X25519MLKEM768 and 0x001d for X25519. A hybrid ClientHello no longer fits in one packet at a 1500 byte MTU, so it creates two TCP segments. That is where PQC rollouts break, as middleboxes, load balancers and older TLS stacks assumed a ClientHello arrives whole, not in parts.

Browsers already negotiate the hybrid group by default, and https://pq.cloudflareresearch.com will show you whether the connection you just made used post-quantum key agreement. To test this on a loopback so you have both handshakes side by side:

```
$ openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 1 -subj "/CN=localhost"  
$ openssl s_server -accept 4433 -cert cert.pem -key key.pem -groups X25519MLKEM768  
$ openssl s_client -connect localhost:4433 -groups X25519MLKEM768 </dev/null | grep -i negotiated  
```

The classical group is recoverable by a future attacker and the hybrid approach is not.

***

## Is hybrid TLS the answer to HNDL?

Hybrid solves the exchange bit, but there are still a number of outstanding elements:

* **The certificate is still classical:** The server authenticated itself with an RSA or ECDSA signature and Shor breaks those too. Nothing useful comes from forging that signature later though, since the handshake was checked at the time and the session is over. Forged certificates are a problem for connections made after a quantum computer exists. Recorded sessions are a problem for connections made now, which is why key exchange is migrated first.
* **Reconnecting skips the key exchange:** TLS 1.3 lets a client come back with a session ticket instead of running a fresh exchange, and the key used for the session was generated during the original handshake. If the original handshake is broken, so is everything that reconnected off it.
* **Everything that is not browser traffic:** IPsec and SSL VPNs, SSH, database connections, MQTT, service mesh, backups. A site-to-site tunnel is the better harvesting target than a website since it runs constantly and transports production data.
* **Data at rest with wrapped keys:** Envelope encryption protects the data with AES-256 and then wraps that data key with RSA, storing the wrapped key next to the ciphertext. Grover does not affect AES, but Shor unwraps the key that unlocks it, so the archive is only as strong as the wrapping algorithm.

***

## What to do about it?

* **Test what your endpoints negotiate:** The `s_client` check above works against anything.
* **Turn on hybrid key exchange if your stack already supports it:** OpenSSL 3.5, recent nginx builds and the major CDNs all do.
* **Start with tunnels:** For IPsec look for RFC 9370 support, and failing that RFC 8784 preshared keys. TLS-based VPNs like OpenVPN pick up the hybrid groups from whatever OpenSSL they link against.
* **Ask vendors for a date:** Renewal is the only real leverage most of us have. If a vendor has nothing to say about hybrid key exchange, that should tell you something.
* **Keep algorithms configurable:** ML-KEM is new, HQC was chosen in March 2025 as a backup KEM for a reason, so make your config modifiable.

The scary thing with harvest now, decrypt later is that we don't exactly know when that later arrives, but traffic may have been sniffed for years at this point, and while hybrid key exchange fixes every session from today onwards, it won't protect any of your already captured traffic.