What Is FIPS 203?
FIPS 203 is the National Institute of Standards and Technology standard for ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), published on August 13, 2024. It is the primary NIST-standardized post-quantum algorithm for key establishment and replaces RSA key exchange and elliptic-curve Diffie-Hellman (ECDH) in protocols such as TLS, SSH, VPNs, and encrypted messaging.
A key encapsulation mechanism generates a shared secret between two parties over an untrusted channel. That shared secret is then used to derive symmetric encryption keys. This is the same conceptual role ECDH plays in TLS 1.3: the session's symmetric keys are derived from the shared secret rather than transmitted directly. ML-KEM fills this role with security properties that hold against both classical and quantum attackers.
ML-KEM is derived from the CRYSTALS-Kyber submission to the NIST post-quantum competition. The standardized algorithm includes changes from the original submission, so implementations must target FIPS 203 rather than any pre-standard Kyber specification. Pre-standard Kyber implementations are not interoperable with FIPS 203 ML-KEM.
How ML-KEM Works
ML-KEM's security rests on the Module Learning With Errors (M-LWE) problem. An M-LWE instance is a system of linear equations over a polynomial ring where small random errors have been introduced. Recovering the secret from these noisy equations is computationally infeasible for both classical and quantum computers at the parameter sizes used in FIPS 203.
The mechanism has three operations: KeyGen generates a public key and a private key. Encaps takes a public key and produces a ciphertext plus a shared secret. Decaps takes the private key and the ciphertext and recovers the same shared secret. Only the party with the private key can run Decaps, so the shared secret is established without transmitting it directly.
ML-KEM is IND-CCA2 secure, meaning it provides security against adaptive chosen-ciphertext attacks. This is the standard security model for key encapsulation and provides the same security guarantees that RSA-OAEP and ECDH provide in their respective roles.
Parameter Sets
FIPS 203 defines three parameter sets targeting different security levels. The choice of parameter set determines key size, ciphertext size, and computational cost.
ML-KEM-512
Targets NIST security category 1, comparable to 128-bit classical security against quantum attackers. Public key: 800 bytes, ciphertext: 768 bytes. Appropriate in resource-constrained environments where lower security margins are acceptable.
ML-KEM-768
Targets NIST security category 3, comparable to 192-bit classical security. Public key: 1,184 bytes, ciphertext: 1,088 bytes. Recommended for most enterprise and internet-facing applications. Used in the IETF hybrid X25519MLKEM768 named group.
ML-KEM-1024
Targets NIST security category 5, comparable to 256-bit classical security. Public key: 1,568 bytes, ciphertext: 1,568 bytes. Required by NSA CNSA 2.0 for all National Security Systems.
Hybrid Deployment in TLS
The recommended first step for most deployments is hybrid key exchange: combining ML-KEM with X25519 in a single TLS 1.3 handshake. The shared secrets from both are combined using a key derivation function. Both the classical algorithm and ML-KEM must be broken independently for an attacker to compromise the session.
The IETF has standardized X25519MLKEM768 as a NamedGroup for TLS 1.3. This hybrid group is the recommended starting point for internet-facing services. Major browsers have shipped support for this hybrid group. Server-side support is available through recent OpenSSL versions, BoringSSL, and cloud-managed TLS termination services.
Migration should begin by enabling hybrid TLS on internet-facing servers, accepting both classical and post-quantum key shares simultaneously. This provides quantum resistance for clients that support ML-KEM while remaining interoperable with clients that do not yet support it.
Implementation Considerations
ML-KEM is supported in recent versions of OpenSSL (3.2 and later, via the OQS provider), BoringSSL, the AWS-LC library, and most major cloud TLS termination services. IETF standardization covers TLS 1.3 key groups, HPKE, and SSH key exchange.
ML-KEM addresses key establishment only. A complete post-quantum TLS deployment requires both ML-KEM for key exchange and ML-DSA or SLH-DSA for certificate and handshake signatures. These are separate migration efforts and should be planned together.
Hardware security modules (HSMs) used to store private keys must be updated or replaced to support ML-KEM if they are involved in TLS termination. HSM vendor roadmaps should be reviewed early in migration planning.
Limitations and Tradeoffs
ML-KEM keys and ciphertexts are larger than ECDH equivalents. For TLS, this increases handshake message sizes, which may affect the initial congestion window on low-bandwidth or high-latency connections. Measurement in constrained environments is recommended before broad deployment.
NIST IR 8547 provides guidance on transition timelines and the planned phase-out of classical-only key exchange. Organizations subject to NSA CNSA 2.0 must consult that advisory for National Security System requirements and deadlines.
References
Frequently Asked Questions
Is ML-KEM the same as CRYSTALS-Kyber?
ML-KEM (FIPS 203) is standardized from the CRYSTALS-Kyber submission but includes modifications. Implementations must target FIPS 203. Pre-standard Kyber implementations are not interoperable with FIPS 203 ML-KEM.
Which ML-KEM parameter set should I use?
ML-KEM-768 is recommended for most enterprise and internet-facing deployments. NSA CNSA 2.0 requires ML-KEM-1024 for National Security Systems. ML-KEM-512 is appropriate only where the lower security margin is acceptable and size constraints are severe.
Does ML-KEM replace AES?
No. ML-KEM replaces key exchange mechanisms such as ECDH and RSA key transport. AES-256, used for bulk data encryption, is already resistant to known quantum attacks at that key size and does not need to be replaced.