FIPS 203 is the NIST standard for ML-KEM — a 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 — a property 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 — 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.
How quantakrypto helps
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) — 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 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.