The term on this page
- ML-KEMModule-Lattice-based Key Encapsulation Mechanism
- the standardised post-quantum replacement for RSA and ECDH key exchange, published as FIPS 203
Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ECDHECDHElliptic Curve Diffie-HellmanElliptic Curve Diffie-Hellman, a key-exchange method using elliptic-curve mathematics to establish a shared secret with smaller keys than classical Diffie-Hellman.Read the full entry (new tab), KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), AES-GCMAES-GCMAdvanced Encryption Standard, Galois/Counter ModeThe Advanced Encryption Standard, a symmetric block cipher standardized by NIST that encrypts data using shared secret keys of 128, 192, or 256 bits.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry (new tab) are defined in the glossary.
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.