ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism (FIPS 203))

ML-KEM is a key-encapsulation mechanism (KEM) whose security rests on the Module Learning With Errors lattice problem. A KEM has three operations: key generation produces an encapsulation key and a decapsulation key; encapsulation takes the encapsulation key and outputs a ciphertext plus a 32-byte shared secret; decapsulation recovers the same secret from the ciphertext with the decapsulation key. FIPS 203 defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in increasing order of strength.

Why it matters

ML-KEM is the main post-quantum algorithm for TLS key establishment, deployed inside the hybrid group X25519MLKEM768, which Chrome has used since version 131. It is computationally fast; its cost is size. An ML-KEM-768 encapsulation key is 1,184 bytes, compared with 32 bytes for an X25519 public key, so the ClientHello grows by more than a kilobyte. During rollout, some middleboxes and servers that mishandled larger ClientHello messages had to be fixed.

Example

Sizes of the three parameter sets in FIPS 203:

Parameter set   Encapsulation key   Ciphertext    Shared secret
ML-KEM-512      800 bytes           768 bytes     32 bytes
ML-KEM-768      1,184 bytes         1,088 bytes   32 bytes
ML-KEM-1024     1,568 bytes         1,568 bytes   32 bytes

Common misconceptions

• "ML-KEM is just Kyber with a new name." The final FIPS 203 standard differs in details from earlier Kyber versions and does not interoperate with them, which is why Chrome moved from the X25519Kyber768Draft00 group to X25519MLKEM768.
• "A KEM works exactly like Diffie-Hellman." In a KEM one side encapsulates to the other's public key rather than both sides contributing symmetric shares; TLS carries the encapsulation key in the client's key_share and the ciphertext in the server's.
• "ML-KEM makes certificates quantum-safe." It protects key establishment only; authentication still depends on signatures, for which ML-DSA is the post-quantum standard.