The terms on this page
- ML-KEMModule-Lattice-based Key Encapsulation Mechanism
- the standardised post-quantum replacement for RSA and ECDH key exchange, published as FIPS 203
- FIPSFederal Information Processing Standard
- the US government's standards series, and where the post-quantum algorithms were published
Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry, TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry, NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry, ACVPACVPAutomated Cryptographic Validation ProtocolThe Automated Cryptographic Validation Protocol, a NIST system for automatically testing that cryptographic algorithm implementations conform to their specifications.Read the full entry, KATKATknown answer testA test that feeds an implementation a fixed input with a published correct output and checks that it produces exactly that.Read the full entry are defined in the glossary.
FIPS 203 is the NIST standard for ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism derived from CRYSTALS-Kyber. It is the post-quantum replacement for the classical key exchange that protects almost all encrypted traffic today: RSA key transport and (elliptic-curve) Diffie–Hellman. Where those rely on integer factorization and discrete logarithms (both broken in polynomial time by Shor's algorithm), ML-KEM rests on the hardness of the Module Learning-With-Errors lattice problem, which no known quantum algorithm solves efficiently.
Why it matters
Key exchange is the first thing to migrate, because it is the surface most exposed to harvest-now-decrypt-later: an adversary can record a TLS handshake and its ciphertext today and decrypt it retroactively once a cryptographically-relevant quantum computer exists. ML-KEM closes that window. In practice it is deployed as the post-quantum half of a hybrid, X25519MLKEM768, so a weakness in either the lattice or the classical component still leaves the connection secure.
The details that trip up implementations
The algorithm is only half the standard; FIPS 203 also specifies input checks that a conformant implementation must perform. §7.2 requires the encapsulating party's key to pass a modulus check: every coefficient must be reduced mod q (3329), and a key with an out-of-range coefficient must be rejected. §7.3 requires a ciphertext type (length) check. And decapsulation uses implicit rejection: on an invalid ciphertext it returns a deterministic pseudo-random shared secret rather than an error. That is only safe if the reject path is indistinguishable, by timing, from the accepting path.
Passing the KATs is not conformance
NIST's ACVP known-answer vectors exercise only honest inputs. We have run implementations that pass every vector yet skip the §7.2 modulus check or leak the reject path by timing. Those are real deviations the vectors never surface. Conformance to the letter of FIPS 203 is a separate axis from a passing KAT run, and from a security audit.
Proving your ML-KEM follows the standard
Migrating to ML-KEM is the easy part; proving the implementation you chose actually follows the standard is the load-bearing question. We inventory where classical key exchange lives in your systems (audit), plan and execute the move to ML-KEM / hybrid key exchange without breaking production (migration), and conformance-test the implementation you ship against FIPS 203's input checks and sizes (certification), which is the exact §7.2/§7.3 behaviour the KAT vectors miss.
Frequently asked questions
What is the difference between ML-KEM and Kyber?
ML-KEM is the NIST-standardized version of the CRYSTALS-Kyber submission. FIPS 203 tightened parameters and specified the exact input checks and encoding; where an implementation says 'Kyber', check whether it targets the final FIPS 203 ML-KEM or an earlier Kyber round, because they are not interoperable.
Should I deploy ML-KEM on its own or as a hybrid?
For general traffic, deploy it as a hybrid, X25519MLKEM768, so the connection stays secure if a weakness is found in either the lattice assumption or the classical curve. NSA's CNSA 2.0 is the exception: it does not require hybrids for national-security systems.
Does passing NIST's test vectors mean an implementation is conformant?
No. The ACVP/KAT vectors exercise only honest inputs. An implementation can pass every vector and still skip the §7.2 modulus check or turn implicit rejection into an explicit error. Both are nonconformant. Conformance testing exercises the malformed-input behaviour the vectors never touch.
What are the ML-KEM-768 key and ciphertext sizes?
Per FIPS 203 Table 3: encapsulation key 1184 bytes, decapsulation key 2400 bytes, ciphertext 1088 bytes, and a 32-byte shared secret. Plan the extra handshake bandwidth (~1.2 KB each way over a classical exchange) into pool sizing and mobile clients.
Work with us on FIPS 203 (ML-KEM)
Related reading
References
- NIST: FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (the normative §7.2/§7.3 checks and Table 3 sizes).
- NIST: SP 800-227: Recommendations for Key-Encapsulation Mechanisms and the ACVP project + ML-KEM vector spec.
- Adversarial vectors: C2SP / CCTV ML-KEM, edge-case vectors including out-of-range coefficients.
- Wikipedia: ML-KEM, Shor's algorithm, Lattice-based cryptography.