ML-KEM (FIPS 203)
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key-encapsulation mechanism standardized by NIST in FIPS 203, finalized on August 13, 2024. It is the standardized form of CRYSTALS-Kyber, the encryption winner of the NIST PQC standardization process, and the primary standard for establishing shared secrets that resist attack by a quantum computer.
How a KEM works
A KEM consists of three algorithms. Key generation produces an encapsulation key (public) and a decapsulation key (private). Encapsulation takes the encapsulation key and outputs a ciphertext together with a 32-byte shared secret. Decapsulation takes the decapsulation key and the ciphertext and recovers the same shared secret. That secret then keys symmetric encryption such as AES-256-GCM. In protocols, a KEM fills the role that Diffie-Hellman key exchange fills today, and TLS 1.3 treats the two interchangeably as key-agreement mechanisms. ML-KEM provides IND-CCA2 security: ciphertexts stay secure even against attackers who can submit other ciphertexts for decapsulation.
Design
ML-KEM's security rests on the Module Learning With Errors (Module-LWE) problem, a structured variant of the learning-with-errors problem from lattice-based cryptography. All parameter sets work in the polynomial ring Z_q[X]/(X^256 + 1) with modulus q = 3329 and differ mainly in the module rank k (2, 3, or 4), which determines how many ring elements make up keys and ciphertexts. Polynomial multiplication uses the number-theoretic transform (NTT), which is why the scheme is fast and needs only integer arithmetic and hashing.
Internally, FIPS 203 defines a simpler IND-CPA public-key encryption scheme, K-PKE, and converts it into an IND-CCA2 KEM with a Fujisaki-Okamoto transform using implicit rejection: an invalid ciphertext does not trigger an error but yields a pseudorandom secret, which blocks chosen-ciphertext attacks that probe decryption behavior. Decapsulation can fail in principle, but the failure probability is below 2^-138 for every parameter set.
Parameter sets
FIPS 203 defines three parameter sets, mapped to NIST security categories 1, 3, and 5. All sizes are exact, in bytes.
| Parameter set | Security category | Encapsulation key | Decapsulation key | Ciphertext | Shared secret |
|---|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 | 1632 | 768 | 32 |
| ML-KEM-768 | 3 | 1184 | 2400 | 1088 | 32 |
| ML-KEM-1024 | 5 | 1568 | 3168 | 1568 | 32 |
Instead of storing the full decapsulation key, an implementation may store the two 32-byte seeds from key generation and re-derive the key when needed.
Changes from round-3 Kyber
ML-KEM is not interoperable with the third-round Kyber submission. The notable differences:
- Round-3 Kyber derived the final shared secret by hashing an intermediate key together with a hash of the ciphertext; ML-KEM outputs the 32-byte key directly, which simplifies using it as a drop-in KEM.
- Kyber hashed the 32 bytes of encapsulation randomness before use as a hedge against weak random number generators; ML-KEM uses the randomness directly and instead requires an approved random bit generator.
- ML-KEM mandates input validation: encapsulation keys are checked for canonical modulo-q encoding, and decapsulation keys carry a hash of the embedded public key that is verified before use.
Performance
All three operations complete in tens of microseconds on modern desktop processors, and a full encapsulation plus decapsulation cycle is generally faster than an X25519 exchange. The cost is bandwidth: an ML-KEM-768 encapsulation key is 1184 bytes and a ciphertext is 1088 bytes, against 32 bytes for each X25519 share. Because the scheme uses only integer arithmetic and SHA-3 family hashing, constant-time implementations are practical on embedded targets. See post-quantum algorithm comparison for side-by-side numbers.
Deployment
ML-KEM is the most widely deployed post-quantum algorithm. In TLS 1.3, the hybrid group X25519MLKEM768 combines ML-KEM-768 with X25519 so that an attacker must break both algorithms (draft-ietf-tls-ecdhe-mlkem); major browsers enabled the hybrid by default across 2024 and 2025, and large operators report a substantial share of inbound human-generated TLS traffic already using post-quantum key agreement (Cloudflare). The main driver is harvest now, decrypt later: traffic recorded today must stay confidential against future quantum attack. See post-quantum TLS, hybrid cryptography, and browser post-quantum adoption for the migration picture.
Before standardization, pre-standard Kyber shipped in Signal's PQXDH handshake and Apple's iMessage PQ3. Open-source implementations are available in liboqs, PQClean, and mainstream libraries such as OpenSSL (native since version 3.5).
Frequently asked questions
Is ML-KEM the same as Kyber?
ML-KEM is the standardized form of CRYSTALS-Kyber with small changes to key derivation and mandatory input checks, so round-3 Kyber and ML-KEM implementations are not interoperable.
Which parameter set should new deployments use?
ML-KEM-768 is the common default, and it is the variant used inside the X25519MLKEM768 hybrid deployed in TLS 1.3.
Sources
- FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (NIST, 2024)
- CRYSTALS-Kyber official site (CRYSTALS team, 2024)
- X25519MLKEM768 hybrid key agreement for TLS 1.3 (draft-ietf-tls-ecdhe-mlkem) (IETF, 2025)
- The state of the post-quantum Internet (Cloudflare, 2024)
Cite this entry
"ML-KEM (FIPS 203)." postquantum.wiki. Updated July 11, 2026. https://postquantum.wiki/ml-kem@misc{pqwiki-ml-kem,
title = {ML-KEM (FIPS 203)},
howpublished = {\url{https://postquantum.wiki/ml-kem}},
year = {2026},
note = {postquantum.wiki, updated 2026-07-11}
}