ML-KEM (FIPS 203)

ML-KEM is the NIST-standardized key-encapsulation mechanism derived from CRYSTALS-Kyber. Built on the Module Learning With Errors (Module-LWE) problem, it is fast, has small keys and ciphertexts, and is NIST's recommended general-purpose post-quantum KEM.

How it works

ML-KEM is a key-encapsulation mechanism (KEM): instead of encrypting an arbitrary message, it lets two parties agree on a fresh 32-byte shared secret. The sender uses the recipient's encapsulation key to produce a ciphertext plus a shared secret; the recipient uses its decapsulation key to recover the same secret from the ciphertext.

The core building block is K-PKE, a public-key encryption scheme whose security rests on Module-LWE — recovering a secret vector from noisy linear equations over a polynomial ring. K-PKE is only IND-CPA secure, so ML-KEM wraps it in the Fujisaki-Okamoto (FO) transform to obtain IND-CCA2 security: the decapsulator re-encrypts the recovered message and rejects the ciphertext if it does not match, with an implicit-rejection fallback that returns a pseudorandom secret rather than failing visibly.

ML-KEM uses the SHA3/SHAKE family of functions for hashing, XOF expansion, matrix generation, noise sampling, and key derivation. The matrix arithmetic is done with the Number-Theoretic Transform (NTT), which keeps the scheme very fast.

Parameter sets

Three parameter sets target NIST security categories 1, 3, and 5. All sizes are in bytes; the shared secret is always 32 bytes.

ML-KEM-768 is the recommended default for most deployments, balancing a comfortable security margin against modest bandwidth.

Strengths & tradeoffs

• Fast. Key generation, encapsulation, and decapsulation are all sub-millisecond on commodity hardware — competitive with or faster than classical ECDH.
• Compact. Keys and ciphertexts are a few kilobytes, small enough to fit in a TLS handshake without major disruption.
• Well-studied. Module-LWE has been analyzed extensively, and Kyber was the flagship lattice KEM through every NIST round.
• Tradeoff: larger than classical ECDH (32-byte keys), and lattice assumptions are newer than code-based ones. For algorithm diversity, NIST also selected the code-based HQC KEM for standardization as a backup (final FIPS not yet published).

When to use it

Use ML-KEM as your primary post-quantum KEM for TLS, SSH, IPsec, VPNs, and any protocol that performs an ephemeral key exchange. In practice it is deployed in a hybrid mode (e.g. X25519 + ML-KEM-768) so that the connection stays secure even if one of the two schemes is later broken.

ML-KEM replaces quantum-vulnerable public-key key-establishment mechanisms, such as finite-field DH, ECDH, and RSA-based key transport or KEM-style use cases. It does not replace digital signatures; use ML-DSA, SLH-DSA, or future FN-DSA for signature use cases.

Code example

A minimal encapsulate/decapsulate round trip using liboqs-python:

import oqs

kem = "ML-KEM-768"
with oqs.KeyEncapsulation(kem) as server:
    public_key = server.generate_keypair()

    # Client encapsulates against the server's public key
    with oqs.KeyEncapsulation(kem) as client:
        ciphertext, ss_client = client.encap_secret(public_key)

    # Server recovers the same shared secret
    ss_server = server.decap_secret(ciphertext)

    assert ss_client == ss_server
    print("shared secret bytes:", len(ss_client))  # 32

Standards & references

• FIPS 203 (ML-KEM) — the official ML-KEM standard.
• CRYSTALS-Kyber project — the design ML-KEM is derived from.
• Open Quantum Safe — liboqs implementation used in the code example.
• Resources — full standards register

Related