Harvest now, decrypt later: why key exchange comes first
Updated:
A quantum computer large enough to run Shor's algorithm would break RSA and elliptic-curve cryptography. None exists yet. The reason to act before it does is simple: encrypted traffic can be recorded now and stored until it can be decrypted.
What gets exposed
In TLS, the key exchange decides the session keys that encrypt everything. With classical X25519 or ECDHE, someone who recorded the handshake and the traffic can recover those keys with a future quantum computer and read the whole session: logins, API tokens, personal data, business documents.
The certificate only proves who the server is at the moment of connection. Breaking it later does not reveal past traffic. It matters for live impersonation once a quantum computer exists, not for data recorded today.
That is why browsers moved key exchange first. Chrome, Firefox, Edge and Safari's newer releases offer the hybrid X25519MLKEM768, and post-quantum certificates are still being standardised for the web.
Who should care now
Anyone whose data must stay confidential for years: health and financial records, legal and government communication, trade secrets, long-lived credentials. If the data will still be sensitive when a large quantum computer arrives, recording it today is already the attack.
Why hybrid
X25519MLKEM768 combines classical X25519 with ML-KEM-768 (NIST FIPS 203, August 2024). An attacker has to break both. If a flaw is ever found in the newer ML-KEM, the connection is still as strong as today's X25519.
What to do
- Scan your domain to see whether it negotiates the hybrid group today.
- Enable it: nginx or Apache, Caddy, HAProxy, Cloudflare.
- Plan for post-quantum certificates later, when CAs and browsers support them.