ML-KEM is the algorithm that replaces RSA and ECDH for key exchange. It was standardised by NIST in August 2024 as FIPS 203, it is implemented in OpenSSL, Chrome, Firefox and Cloudflare, and it is protecting a large share of real internet traffic today. It also does not do what most people assume it does, and clearing that up first saves a lot of confusion.
ML-KEM does not encrypt your message
It is a key encapsulation mechanism. It agrees on a shared secret between two parties, and a symmetric cipher like AES-GCM does the actual encrypting. If you were picturing a drop-in replacement for RSA encryption, that picture is wrong, and it is the single most common misunderstanding about the migration.
What encapsulation actually means
It is a three-step dance, and it is genuinely simpler than the RSA version once you see it.
- You publish a public key. Anyone can have it.
- Someone who wants to talk to you runs encapsulate against that public key. It hands them two things: a random shared secret, and a ciphertext that carries that secret to you. They send you the ciphertext.
- You run decapsulate on the ciphertext with your private key, and you get the same shared secret back.
Now you both hold the same secret and nobody watching the wire does. You use it to key AES-GCM and encrypt whatever you actually wanted to send. If that pattern feels familiar it should: it is exactly what ECDH does, which is why ECDH is the better mental model for ML-KEM than RSA is.
The encrypt and sign playground shows this split explicitly. Encrypt something with ML-KEM and you get back two separate fields: the encapsulated key and the message ciphertext. Do the same with RSA and there is no encapsulated key at all.
What makes it quantum-resistant
RSA and elliptic curve both rest on problems that Shor's algorithm solves. ML-KEM rests on a different one, called Module Learning With Errors, which no known quantum algorithm solves efficiently.
The intuition: it works with lattices, regular grids of points in very high-dimensional space, and deliberately adds small random errors to its equations. Recovering the original values from noisy equations in a few hundred dimensions is hard for classical and quantum computers alike. Shor's algorithm is a specialised tool for periodicity, and there is no periodicity here for it to find.
Lattice schemes can and do break
HAWK, a lattice signature scheme in the third round of NIST's additional-signatures process, was withdrawn in July 2026 after an AI-found structural weakness. ML-KEM was unaffected: different construction, different mathematics, and years more scrutiny. But it is a reminder that newer schemes deserve caution and that hybrid deployment exists for a reason.
Which parameter set
| Parameter set | NIST category | Public key | Ciphertext | Comparable to |
|---|---|---|---|---|
| ML-KEM-512 | Category 1 | 800 B | 768 B | AES-128 |
| ML-KEM-768 | Category 3 | 1,184 B | 1,088 B | AES-192 |
| ML-KEM-1024 | Category 5 | 1,568 B | 1,568 B | AES-256 |
ML-KEM-768 is the default you want unless something tells you otherwise. It is what browsers deploy, what Cloudflare serves, and what most guidance converges on. Use ML-KEM-1024 where policy requires category 5, which in practice means CNSA 2.0 and national security systems.
The cost, stated plainly
| X25519 | ML-KEM-768 | Change | |
|---|---|---|---|
| Public key | 32 B | 1,184 B | 37x larger |
| Ciphertext | 32 B | 1,088 B | 34x larger |
| Speed | fast | comparable or faster | not the problem |
Speed is not the issue. Size is. A TLS ClientHello that comfortably fit in one packet may no longer, and anything with tight buffers, embedded devices, constrained radio links, may need real work. This is the actual migration cost and it is worth measuring rather than assuming.
Why almost everyone deploys it hybrid
In practice ML-KEM is rarely deployed alone. The standard approach is hybrid: run X25519 and ML-KEM-768 together and combine both shared secrets, which is what X25519MLKEM768 in TLS does and what RFC 10024 specifies.
The reasoning is straightforward. ML-KEM is younger than the algorithm it replaces, so combining them means a break in either one leaves you no worse off than today. See hybrid key exchange explained for the construction.
Try it
OpenSSL 3.5 and later generates ML-KEM keys directly. If your OpenSSL is older, the key generator will make one in your browser so you can at least see the sizes.
For a worked example of ML-KEM in a real protocol, @nostr-wot/pq implements a hybrid ML-KEM-1024 and NIP-44 envelope for Nostr direct messages, sealed with XChaCha20-Poly1305. It is a compact, readable illustration of the pattern this guide describes: encapsulate, derive, encrypt with a symmetric cipher.