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

  1. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (NIST, 2024)
  2. CRYSTALS-Kyber official site (CRYSTALS team, 2024)
  3. X25519MLKEM768 hybrid key agreement for TLS 1.3 (draft-ietf-tls-ecdhe-mlkem) (IETF, 2025)
  4. 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} }