When your browser opens https://, before a single letter is sent it negotiates a set of keys with the server. That opening greeting, the TLS 1.3 handshake, includes an ECDHE key exchange (ephemeral Diffie-Hellman over an elliptic curve): each side contributes a one-time secret and the mixture yields the symmetric key that encrypts everything else. We have spent two decades trusting that the mathematics of that step is intractable. And it still is… for a classical computer.
What is remarkable is that the replacement is already under way and invisible. If you browse today with Chrome, Firefox or Safari, the odds are that every secure connection you open is using a hybrid post-quantum key exchange, without you changing or installing anything. That is the headline: the cryptography that survives a quantum computer is not a lab experiment or a ten-year plan, it is real traffic from your daily life.
The problem is not the future, it is what is already being copied
Two quantum algorithms have very different consequences. Shor’s algorithm solves integer factorisation and the discrete logarithm in polynomial time: exactly the two problems RSA, Diffie-Hellman and elliptic curves rely on. A quantum computer with enough stable qubits breaks all the public-key cryptography we use today in one blow, for key exchange and for signatures alike. Grover’s algorithm, by contrast, only buys a quadratic speed-up on searches, which translates into AES-128 dropping to roughly 64 effective bits and AES-256 to 128: uncomfortable, but fixable by enlarging the key. The asymmetry matters: symmetric keys hold, asymmetric ones do not.
That is why the number-one priority for standards bodies is key exchange rather than signatures. The reason has a name: harvest now, decrypt later. A signature can only be forged at the moment it is used: without a quantum computer today, you cannot sign on someone else’s behalf. But a TLS session recorded today can be decrypted retroactively tomorrow, when the machine arrives. Somebody is storing terabytes of encrypted traffic waiting for that day, and anything with long-term value —medical records, state secrets, industrial property— is already in that cup. Migrating key exchange is the only thing that closes that door today.
Lattices instead of curves: how ML-KEM works
NIST’s chosen replacement is ML-KEM (FIPS 203, published in August 2024), the algorithm known during the competition as CRYSTALS-Kyber. Its security does not rest on factoring large numbers or on elliptic curves, but on a lattice problem: Module-LWE (Module Learning With Errors). The idea, heavily compressed, is that given a matrix A and a vector b = A·s + e, where s is a small secret and e an equally small noise term, recovering s is computationally infeasible, for a quantum computer too. The noise is the trap: without it, solving a system of equations would be enough.
The entries of those matrices are not plain integers but polynomials in the ring Z_q[X]/(X^256 + 1) with q = 3329, a prime chosen on purpose so that roots of unity of order 256 exist. That detail allows polynomial multiplication via the NTT (Number Theoretic Transform, a modular-arithmetic analogue of the Fourier transform), cutting the cost of each multiplication from O(n²) to O(n log n). The practical consequence: ML-KEM uses only integer arithmetic and hash functions, with no floating-point operations and no secret-dependent execution time, which is why it is fast even on microcontrollers.
The mechanism has three operations: KeyGen produces the key pair and publishes (A, t) with t = A·s + e; Encaps uses that public key to produce a ciphertext and a 32-byte shared secret; Decaps recovers the same secret with the private key. Validation is mandatory in the standard: if decryption does not check out, the implementation does not return an error but a pseudorandom value (implicit rejection), so an attacker cannot tell a tampered ciphertext from a valid one. That trick comes from the Fujisaki-Okamoto transform and is what provides security against chosen-ciphertext attacks.
The price is paid in size. ML-KEM-768, the recommended level (equivalent to AES-192), uses public keys of 1,184 bytes and ciphertexts of 1,088 bytes, against the 32 bytes of an X25519 public key. That is 30 to 40 times larger, a factor that would have been a serious problem in 2010 and that in 2026 is absorbed almost unnoticed.
Two locks at once: the hybrid handshake
Nobody deploys ML-KEM on its own. The group actually in production is called X25519MLKEM768 (code point 0x11EC, registered for TLS in RFC 9794): the client sends an X25519 key and an ML-KEM key in its key_share, the server replies with its part and the ciphertext, and the session secret is derived with HKDF by mixing both outputs. Breaking the connection would require breaking both at once. The reason is historical and very sound: in 2022 the SIKE candidate, which had looked solid for a decade, fell to a classical attack; young algorithms deserve a parachute.
The cost of that mixture is about 1,216 extra bytes in the ClientHello and some 1,120 in the reply. And that is where the least glamorous and most real problem of the whole migration appeared: during 2023 and 2024 many servers and middleboxes (load balancers, firewalls, network antivirus) closed the connection on seeing an unusually large opening message, because they split it across several TCP packets and failed to reassemble it properly. Cryptography was not failing, the plumbing was. The fix was the usual one on the internet: fragment, negotiate and, in some cases, pull the cotton wool out of old implementations.
It is already happening without you noticing
The real rollout is enormous. Chrome turned it on by default in version 131 (November 2024), Firefox in 132, Safari in 18.2 and Apple adopted it system-wide in iOS 26 and macOS Tahoe. OpenSSL 3.5 (April 2025) ships ML-KEM, and BoringSSL —the engine behind Chrome and Cloudflare— has had it since 2024. In Go it is available from 1.24 with the GODEBUG=tlsmlkem=1 switch. Cloudflare enabled it for all customer traffic in 2024, AWS offers it in its modern TLS policies, and on nginx a single line is enough: ssl_ecdh_curve X25519MLKEM768:X25519.
The numbers confirm it. Cloudflare Radar reported that more than half of human browser traffic crossing its network was already using hybrid key exchange by late 2025, and in 2026 some measurements speak of two thirds. An internet-wide measurement study is more sober: slightly fewer than half of all domains support the hybrid group, and only about half negotiate TLS 1.3, the prerequisite for using it. The key point is that the user does not decide: the browser offers, and the server accepts or not. That is why a site behind a modern CDN is already protected without its administrator doing anything.
The same is true beyond the web. OpenSSH has used hybrid post-quantum key exchange by default since version 9.0 (2022, with sntrup761) and switched to mlkem768x25519-sha256 as the default in 10.0 (April 2025). Any SSH session between updated machines is already safe from retroactive harvesting, even if the administrator does not know it.
The hard part is signatures and certificates
The other 50% of the problem remains. The standards exist: ML-DSA (FIPS 204, also lattice-based) and SLH-DSA (FIPS 205, the former SPHINCS+, based only on hash functions and Merkle trees, far more conservative but with enormous signatures). Migrating signatures is considerably harder than migrating key exchange, for four reasons: post-quantum signatures are big —ML-DSA-65 goes past 3 KB, and SLH-DSA can exceed 7 KB, so a certificate chain swells—, trust is anchored in long-lived certificates that expire and renew in specific windows, every piece of software has to change at roughly the same time (certificate validation, timestamping, DNSSEC, code signing, HSMs) and legacy formats do not always have room for larger keys.
The timelines are already official. Draft NIST IR 8547 states that RSA, ECDH, ECDSA and EdDSA become deprecated (discouraged, with a mandatory risk justification) after 2030 and disallowed after 2035; moving from RSA-2048 to RSA-4096 buys no time, because Shor breaks both equally. For national security systems, CNSA 2.0 requires quantum-resistant cryptography in new acquisitions from 2027 and full migration by 2033. In practice, the coming decade is a global cryptographic renovation campaign.
Meanwhile there is a simple check to learn whether your server is on the right side: connect with openssl s_client -connect example.com:443 -groups X25519MLKEM768 and see whether the handshake completes with that group. If your site sits behind a major CDN, the answer is most likely yes, and neither the certificate nor your server configuration will have had anything to do with it. The internet’s padlock is being changed from the inside, piece by piece, and all the user will notice is that everything kept working.
