ML-KEM vs Kyber: Understanding the NIST Algorithm Selection

Security architects updating their documentation over the past two years have faced a specific frustration: the algorithm they knew as CRYSTALS-Kyber is now called ML-KEM, the name has changed across library changelogs and compliance checklists, and no one has given a clear account of whether the two are actually the same thing. They are not. NIST introduced substantive specification changes between the Kyber round submissions and the final FIPS 203 standard published in August 2024. Those changes break interoperability between pre-standardisation Kyber implementations and ML-KEM-compliant code.

This matters operationally right now. Google Chrome shipped X25519Kyber768Draft00 from version 116 (August 2023) through version 130. Chrome 131, released in November 2024, switched to ML-KEM-768. Any TLS stack that was pinned to the draft cipher suite identifier will not negotiate post-quantum key exchange with Chrome 131 and later clients. The rename is not a rebranding exercise. It reflects a standards process that finalised specific implementation details, and those details determine whether two endpoints agree on a shared secret.

This article sets out what changed, why the naming taxonomy matters, and what architects need to do with that information.

What CRYSTALS-Kyber Was

CRYSTALS-Kyber was a lattice-based key encapsulation mechanism submitted to the NIST post-quantum cryptography standardisation process, which opened for submissions in November 2017. Its security rests on the hardness of the Module Learning With Errors problem (Module-LWE), a generalisation of Ring-LWE over module lattices. The security reduction to Module-LWE was established in the original Kyber paper by Bos et al. published at IEEE EuroS&P 2018 and available as ePrint 2017/634.

Kyber survived three public rounds of cryptanalysis. NIST IR 8413, the July 2022 status report on the third standardisation round, confirmed that no polynomial-time classical or quantum attack on the underlying Module-LWE hardness assumption had been published. In July 2022, NIST selected Kyber as the sole KEM to standardise, alongside CRYSTALS-Dilithium, FALCON, and SPHINCS+ for digital signatures.

IND-CCA2 Security

Kyber achieves IND-CCA2 security, the gold standard for key encapsulation mechanisms, through the Fujisaki-Okamoto (FO) transform applied to its underlying K-PKE public-key encryption scheme. IND-CCA2 means an adversary with access to a decryption oracle cannot distinguish real ciphertexts from random, even after submitting chosen ciphertexts to that oracle. The FO transform and the formal security reduction are documented in the Kyber specification, version 3.02, and in the Bos et al. paper.

The K-PKE Building Block

Kyber, and its successor ML-KEM, use a two-layer design. K-PKE is a module-LWE public-key encryption scheme operating in the ring Z_q[X]/(X²⁵⁶ + 1) with q = 3329. ML-KEM wraps K-PKE with the FO transform to produce a secure KEM. The module dimension k governs the security level: k=2 for ML-KEM-512, k=3 for ML-KEM-768, k=4 for ML-KEM-1024. FIPS 203 documents this structure across Sections 5 and 6, with parameter tables in Section 7.

What Changed Between Kyber and ML-KEM

The transition from the Kyber round submission to FIPS 203 ML-KEM is not a version bump on identical code. NIST directed changes during finalisation that affect the specification at a level that matters for interoperability.

Domain Separation Strings

The most consequential change involves domain separation strings used in the hash functions within K-PKE and the KEM encapsulation and decapsulation routines. Domain separation ensures that distinct hash calls within the same protocol cannot be confused or cross-linked by an adversary. In ML-KEM, the domain separation bytes used in the G (key generation) and H (hashing) functions differ from those in the Kyber v3.02 submission. An implementation built to Kyber v3.02 will derive different internal keys from the same seed compared to an implementation built to FIPS 203. The Kyber team published version notes acknowledging NIST-directed changes during finalisation.

Key Schedule and Implicit Rejection

FIPS 203 Section 6.3 formalises the implicit rejection mechanism in decapsulation. When decapsulation encounters an invalid ciphertext, ML-KEM returns a pseudorandom value derived from the private key and the ciphertext rather than an explicit error code. This prevents timing side-channels that could leak decryption failure information to an adversary probing the system. Some intermediate Kyber implementations handled this differently. The FIPS 203 specification is now the normative definition, and any library that predates it must be audited against it.

The key derivation function within ML-KEM uses SHAKE-256 and SHA3-256, consistent with NIST's suite of approved hash functions as defined in FIPS 202.

Why the Rename Matters: The Module-Lattice Naming Convention

ML-KEM is not an arbitrary label. NIST introduced a naming taxonomy for its post-quantum algorithm family that communicates the underlying mathematical structure: mathematical hardness assumption + operation type. ML stands for module lattice; KEM stands for key-encapsulation mechanism. The naming convention is established explicitly in FIPS 203 Section 1.

The same pattern applies across the suite. ML-DSA (FIPS 204, August 2024) is the Module-Lattice-based Digital Signature Algorithm, derived from CRYSTALS-Dilithium. SLH-DSA (FIPS 205, August 2024) is the Stateless Hash-based Digital Signature Algorithm, derived from SPHINCS+. This allows procurement and compliance teams to map algorithm families to hardness assumptions without requiring implementation-level knowledge. ML-KEM and ML-DSA both rest on module-lattice problems (Module-LWE for ML-KEM, Module-SIS for ML-DSA). SLH-DSA rests on a different foundation entirely: the security of hash functions.

NIST IR 8547, the Initial Public Draft published in November 2024, establishes the deprecation schedule for classical cryptographic algorithms and names ML-KEM, ML-DSA, and SLH-DSA as the post-quantum replacements. The naming taxonomy makes that mapping explicit for auditors and regulators who need to verify algorithmic compliance.

The Interoperability Gap: Kyber768Draft00 and ML-KEM-768 Are Not the Same

Before FIPS 203 was finalised, browser vendors and TLS library implementers began deploying Kyber in hybrid mode to gather operational data and provide forward secrecy against future quantum adversaries. The version deployed was X25519Kyber768Draft00, defined in the IETF Internet Draft draft-tls-westerbaan-xyber768d00. That document is an internet draft, not an RFC, and the “d00” suffix explicitly references the pre-standardisation draft version.

Google Chrome shipped X25519Kyber768Draft00 (TLS cipher suite identifier 0x6399) from Chrome 116 in August 2023 through Chrome 130. Chrome 131, released in November 2024 to coincide with the FIPS 203 finalisation, switched to the ML-KEM-768 hybrid, X25519MLKEM768, with cipher suite identifier 0x11EC.

The two are not interoperable. The domain separation and key derivation differences described above mean that a client negotiating X25519Kyber768Draft00 and a server expecting ML-KEM-768 will derive different shared secrets. In correctly implemented TLS stacks, this produces a handshake failure. In misconfigured implementations, it risks a silent downgrade to classical-only X25519, eliminating the post-quantum protection entirely.

Any TLS termination proxy, load balancer, or cryptographic library that was configured to accept only cipher suite 0x6399 will not complete a post-quantum key exchange with Chrome 131 and later clients. The fix requires updating to support cipher suite 0x11EC. For organisations that want a transition window, accepting both identifiers temporarily is the safer approach: keep 0x6399 for older clients while adding 0x11EC for current ones, then deprecate 0x6399 once client version data shows the draft suite is no longer in use. See the related discussion in Post-Quantum TLS: What Changes and What Stays the Same.

Parameter Sets: 512, 768, and 1024

FIPS 203 Section 7 defines three parameter sets, each targeting a different NIST security category:

• ML-KEM-512: k=2, NIST security category 1 (equivalent classical security to AES-128). Public key: 800 bytes. Ciphertext: 768 bytes.
• ML-KEM-768: k=3, NIST security category 3 (equivalent to AES-192). Public key: 1,184 bytes. Ciphertext: 1,088 bytes.
• ML-KEM-1024: k=4, NIST security category 5 (equivalent to AES-256). Public key: 1,568 bytes. Ciphertext: 1,568 bytes.

NSA CNSA 2.0, published in September 2022, mandates ML-KEM-1024 for national security systems, reflecting the NSA's preference for the highest parameter set where feasible. For most enterprise deployments, ML-KEM-768 provides an appropriate balance: Category 3 security with manageable key and ciphertext sizes. The additional performance cost of ML-KEM-1024 is modest on modern server hardware, but key sizes increase by roughly 33% compared to ML-KEM-768. This is relevant for high-throughput TLS termination at scale.

NIST security categories are defined relative to the cost of attacking the corresponding AES variant. Category 1 means the algorithm is at least as hard to break as a brute-force key search on AES-128. Category 5 means at least as hard as AES-256. These are the same definitions used across all NIST PQC algorithm families, which makes cross-algorithm security level comparisons straightforward.

Practical Guidance for Architects

The Kyber-to-ML-KEM transition creates a concrete audit obligation. Every library and cryptographic provider in your stack that references Kyber must be checked against FIPS 203 compliance. “Kyber” in a changelog does not mean the library has implemented FIPS 203 ML-KEM. It may mean the library implemented Kyber v3.02, the IETF draft, or an intermediate version. Each of these has a different specification and none is interoperable with ML-KEM without an update.

OpenSSL 3.x, BoringSSL, and liboqs have different version timelines for ML-KEM support. The liboqs project (Open Quantum Safe) explicitly tracks algorithm versions and documents which version of each algorithm is implemented in which release. Checking liboqs release notes against the FIPS 203 finalisation date of August 2024 will identify whether a given build predates the standard.

For migration sequencing: treat cipher suite support as a two-step process. First, ensure your servers accept both 0x6399 and 0x11EC (transition window). Second, deprecate 0x6399 once your client version distribution shows that the draft suite is no longer negotiated. The length of that window depends on how quickly your client base updates. Managed enterprise endpoints can move in weeks. Consumer-facing services may need six to twelve months.

ML-KEM covers key encapsulation only. The signature counterparts, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205), address authentication, certificate signing, and code signing. Those are separate migrations. For an overview of how ML-KEM fits into the broader key exchange architecture, see Hybrid PQC and Classical Cryptography Explained and ML-KEM Key Sizes: A Guide for Enterprise Architects.

The QSECDEF PQC migration advisory programme supports organisations through cipher suite audits, library version assessments, and migration sequencing. Expert Membership provides structured access to that programme, including dedicated support for teams working through the TLS stack transition now.