ML-KEM explained: NIST's new standard for post-quantum key establishment

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the primary key establishment algorithm from the NIST post-quantum standardization process. Standardized as FIPS 203 in August 2024, it provides post-quantum key establishment for protocols that need to move beyond quantum-vulnerable classical mechanisms such as Diffie-Hellman and RSA-based key transport. In practice, most early deployments pair ML-KEM with a classical algorithm in a hybrid configuration.

For most teams, the challenge is no longer understanding what ML-KEM is, but deciding where to introduce it first without breaking operational assumptions in existing protocols.

From Kyber to ML-KEM

ML-KEM is the standardized version of CRYSTALS-Kyber, which was selected by NIST in July 2022 after six years of evaluation. The "ML" prefix (Module-Lattice) indicates the mathematical foundation, while "KEM" describes the cryptographic primitive: a Key Encapsulation Mechanism.

A KEM differs from traditional key agreement. Instead of two parties jointly computing a shared secret, a KEM works asymmetrically:

1. KeyGen() produces a public/private key pair
2. Encaps(pk) takes the public key and outputs a ciphertext and a shared secret
3. Decaps(sk, ct) takes the private key and ciphertext, and recovers the shared secret

This model fits into the TLS 1.3 handshake, where the client and server exchange ephemeral key shares. The integration is not a direct drop-in; the IETF is still finalizing how hybrid KEM combinations are negotiated and encoded (see the TLS section below).

The mathematics: Learning With Errors

ML-KEM's security rests on the Module Learning With Errors (MLWE) problem. The core idea:

Given a system of "noisy" linear equations over a polynomial ring, it's computationally hard to recover the secret, even with a quantum computer.

More precisely, given a matrix A and a vector b = As + e (where s is the secret and e is a small error vector), no polynomial-time algorithm, classical or quantum, is known to recover s. The "module" structure means the entries are polynomials in a ring rather than plain integers, which provides efficiency without sacrificing security.

The hardness of MLWE is supported by:

• Decades of research in lattice cryptography
• Connections to well-studied worst-case lattice problems (though with loose approximation factors at practical parameter sizes)
• No known quantum algorithm that significantly outperforms classical attacks

Parameter sets

ML-KEM comes in three security levels:

Parameter Set	Security Level	Public Key	Ciphertext	Shared Secret
ML-KEM-512	NIST Level 1 (~AES-128)	800 bytes	768 bytes	32 bytes
ML-KEM-768	NIST Level 3 (~AES-192)	1,184 bytes	1,088 bytes	32 bytes
ML-KEM-1024	NIST Level 5 (~AES-256)	1,568 bytes	1,568 bytes	32 bytes

The NCSC recommends ML-KEM-768 for most general-purpose applications. Key sizes are larger than classical ECDH (32-byte keys) but manageable for most protocols.

ML-KEM-768 is the safe default and the parameter set used in hybrid TLS deployments. ML-KEM-512 targets NIST Level 1 (roughly AES-128 equivalent) and has the smallest sizes, but some national agencies (including ANSSI and BSI) have expressed a preference for Level 3 or above. ML-KEM-1024 provides Level 5 security at the cost of larger keys and ciphertexts; consider it when compliance requirements specifically mandate AES-256-equivalent post-quantum security or when protecting data with a multi-decade confidentiality horizon.

Impact on TLS

ML-KEM's most visible deployment is in TLS 1.3 hybrid key exchange. The standard approach combines ML-KEM-768 with X25519 into a single named group, so the connection remains secure even if one algorithm is broken.

The IETF has defined X25519MLKEM768 as a TLS 1.3 named group in draft-ietf-tls-ecdhe-mlkem. This draft is on the Standards Track but has not yet reached RFC status; details around negotiation, encoding, and additional hybrid combinations (such as SecP256r1MLKEM768) continue to evolve.

In practice, a hybrid TLS 1.3 handshake looks like:

ClientHello: X25519MLKEM768 key share
ServerHello: X25519MLKEM768 key share

Chromium-based browsers and Firefox both support hybrid ML-KEM key establishment in recent versions, and server-side support is available in BoringSSL, AWS-LC, and OpenSSL 3.5+. Check vendor release notes for the specific version that applies to your deployment environment.

The main operational impact is larger handshake messages. An ML-KEM-768 public key is 1,184 bytes compared to 32 bytes for X25519. This increases the ClientHello size, which can cause problems with:

• Middleboxes that reject or truncate larger-than-expected handshakes
• QUIC and UDP-based protocols where fragmentation affects performance
• Constrained devices with limited memory or bandwidth budgets

For a deeper treatment of hybrid schemes, including NCSC migration timelines and when to consider PQC-only deployment, see PQ/T hybrid schemes.

Performance

ML-KEM is fast on modern hardware. On x86-64 with AVX2 instructions, all three operations (key generation, encapsulation, decapsulation) for ML-KEM-768 complete in tens of microseconds. Published benchmarks vary by implementation and platform; see the pqcrypto.org benchmarks for comparative measurements across implementations.

ML-KEM-768 computation time is in the same order of magnitude as X25519 ECDH, though direct comparisons depend on implementation and hardware. In hybrid deployments, both run together, so ML-KEM adds modest computational overhead to the handshake.

Constant-time implementations are available in production TLS libraries including BoringSSL, AWS-LC, and OpenSSL 3.5+. The pqcrystals project provides reference implementations useful for testing and research, though these are not production-hardened. The lattice operations map well to SIMD instructions (AVX2, AVX-512, NEON), which helps performance on server and desktop hardware.

What to do now

1. Protocol designers: Specify X25519MLKEM768 as the hybrid key exchange group. For Internet-facing TLS today, prefer hybrid deployment over standalone ML-KEM unless you have a specific standards or compliance reason to do otherwise.
2. Application developers: Check whether your TLS library supports ML-KEM. OpenSSL 3.5+, BoringSSL, and AWS-LC include it. If your stack uses a managed TLS termination layer (cloud load balancers, CDN), check your provider's PQC support status separately.
3. Security architects: Start a cryptographic inventory. Identify every system using Diffie-Hellman key agreement or RSA key transport. Prioritize systems that protect long-lived data confidentiality (the "harvest now, decrypt later" threat model) and systems where you control both endpoints (easier to migrate).
4. What not to do yet: Do not remove classical algorithms from production systems. Do not assume ML-KEM-512 is sufficient without checking your compliance requirements. Do not treat PQC migration as a one-time library upgrade; it affects certificate chains, key management, protocol negotiation, and message sizes.

ML-KEM is standardized, has production-quality implementations, and is already deployed in hybrid TLS by major browsers and cloud providers. For most teams, ML-KEM adoption is settled; the open question is sequencing, which systems to migrate first. A structured post-quantum readiness assessment helps build that sequence: cataloging cryptographic dependencies, scoring exposure by data lifetime and threat model, and producing a prioritized migration plan.

See the PQC Timeline for the full standardization history, or browse our Resources for links to FIPS 203 and implementation libraries.