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.
NSA CNSA 2.0 mandates ML-KEM for all National Security System key exchange, with hybrid classical/PQC implementations as an acceptable interim step. The 2033 migration deadline applies to completed ML-KEM deployment, not just planning.
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
Approximately 128-bit classical and 128-bit quantum security. Smallest key and ciphertext sizes. Suitable for constrained environments.
ML-KEM-768 (recommended)
Approximately 192-bit classical and 180-bit quantum security. NIST's primary recommended parameter set for most use cases.
ML-KEM-1024
Approximately 256-bit classical and 254-bit quantum security. For environments requiring the highest security margins.