What Is It?
ML-KEM (Module Lattice-based Key Encapsulation Mechanism) is the first NIST-standardized post-quantum key encapsulation mechanism, published as FIPS 203 in August 2024. It is based on CRYSTALS-Kyber, selected during NIST's multi-year post-quantum cryptography competition.
ML-KEM establishes a shared secret key between two parties. This is the same function served by ECDH and RSA key exchange in classical systems producing the symmetric key material that protects the bulk of encrypted communications. ML-KEM provides security against both classical and quantum attacks on this mechanism.
Key encapsulation is distinct from public-key encryption. ML-KEM does not encrypt arbitrary messages; it generates and transports a random symmetric key. The resulting shared secret is then used with a symmetric cipher (typically AES-256-GCM) for the actual data encryption.
Why Does It Matter?
Key encapsulation establishes the session keys protecting the bulk of encrypted communications. If an adversary can break key encapsulation, they can decrypt the session either now or through harvest-now-decrypt-later collection. ECDH and RSA key exchange are both vulnerable to Shor's algorithm on a sufficiently large quantum computer.
ML-KEM is the NIST-designated replacement. Deploying ML-KEM (or hybrid ECDH + ML-KEM) for key exchange is the primary technical mitigation for HNDL risk on data in transit. All major browsers and several large-scale TLS deployments have already integrated hybrid ML-KEM key exchange.
CNSA 2.0 specifies ML-KEM-1024 for National Security System key establishment. NSA does not generally recommend hybrid solutions for NSS, although specific protocol and interoperability exceptions exist. NSS operators must follow current NSA guidance, CNSSP 15 milestones, and applicable validation requirements rather than assume any hybrid implementation is approved.
How It Works
ML-KEM is based on the Module Learning With Errors (M-LWE) problem: distinguishing a matrix of structured samples from random data is computationally hard. No known classical or quantum algorithm solves this efficiently at the parameter sizes used in FIPS 203.
The mechanism has three operations:
KeyGen
Generate a public/private key pair. The public key is shared with the encapsulating party. Key sizes range from 800 bytes (ML-KEM-512) to 1568 bytes (ML-KEM-1024).
Encaps
Use the public key to generate a ciphertext and a shared secret. The ciphertext is sent to the key holder. Ciphertext sizes range from 768 bytes (ML-KEM-512) to 1568 bytes (ML-KEM-1024).
Decaps
Use the private key to recover the same shared secret from the ciphertext. Both parties now have identical key material without the secret ever being transmitted.
Enterprise Impact
ML-KEM integrates into a wide range of existing protocols and infrastructure. Major integration points:
TLS 1.3
Hybrid key exchange combining ECDH (X25519) with ML-KEM-768 is already deployed at scale by Google, Cloudflare, and Amazon. It is available in OpenSSL 3.2+, BoringSSL, and most major TLS libraries.
SSH
ML-KEM hybrid variants are available in OpenSSH 9.0+ and commercial SSH implementations.
VPNs and IPsec
Post-quantum IKE/IPsec extensions are in active development and deployment. ML-KEM is the designated algorithm for post-quantum IKE key exchange.
HSMs and hardware
Cryptographic hardware vendors are adding ML-KEM support. HSM firmware upgrades or replacement may be required for some deployments.
Performance
ML-KEM-768 key generation, encapsulation, and decapsulation each complete in well under one millisecond on modern hardware. Performance is not a deployment blocker.
NIST Guidance
FIPS 203 specifies ML-KEM in three parameter sets.
ML-KEM-512
NIST security category 1, benchmarked against key search on AES-128. Smallest ML-KEM key and ciphertext sizes; assess whether this category meets the application's requirements.
ML-KEM-768 (recommended)
NIST security category 3, benchmarked against key search on AES-192. Widely used for hybrid internet protocols; choose parameters according to protocol support and security requirements.
ML-KEM-1024
NIST security category 5, benchmarked against key search on AES-256. Specified by CNSA 2.0 for National Security System key establishment; implementation validation requirements also apply.