What Is ML-KEM?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the post-quantum key encapsulation mechanism standardized by NIST as FIPS 203 in August 2024. It is derived from the CRYSTALS-Kyber algorithm submitted to the NIST PQC Standardization Project and is the primary post-quantum replacement for ECDH and RSA key transport in key establishment protocols. ML-KEM is used to establish shared secret keys between two parties over an untrusted channel, with security based on the Module Learning With Errors (Module-LWE) mathematical problem.
ML-KEM is a key encapsulation mechanism rather than a key agreement protocol. In a KEM, the encapsulation operation generates a random shared secret and a corresponding ciphertext. The decapsulation operation uses the private key to recover the shared secret from the ciphertext. This is functionally equivalent to key agreement both parties end with the same shared secret but the operational flow differs from ECDH. The shared secret derived from ML-KEM is used as input to a key derivation function to produce the final session keys used for symmetric encryption.
“This standard specifies key-encapsulation mechanisms (KEMs). A KEM is a set of algorithms that, under certain conditions, can be used by two parties to establish a shared secret key over a public channel.”
The Problem ML-KEM Solves
RSA and ECDH, the algorithms ML-KEM replaces, are mathematically vulnerable to Shor's algorithm on a sufficiently large quantum computer. RSA key transport relies on the hardness of integer factorization; ECDH relies on the elliptic-curve discrete logarithm problem. Both can be solved efficiently by Shor's algorithm, which means any session key established using RSA or ECDH is potentially recoverable by a future quantum computer given the TLS handshake transcript.
This vulnerability drives the harvest-now, decrypt-later threat. Adversaries can archive TLS handshake records containing ECDH key exchanges today and apply Shor's algorithm to them in the future to recover session keys. ML-KEM addresses this by basing key encapsulation on Module-LWE, which is believed to resist Shor's algorithm and all other known quantum algorithms. Post-quantum key exchange using ML-KEM closes the HNDL vulnerability for traffic captured after migration.
Mathematical Foundation: Module Learning With Errors
ML-KEM's security is based on the Module Learning With Errors (Module-LWE) problem. Learning With Errors (LWE) is a mathematical problem introduced by Oded Regev in 2005 that involves distinguishing noisy linear equations over a finite field from random equations. The hardness of LWE is connected to worst-case instances of lattice problems, specifically the Short Vector Problem (SVP), which is believed to be hard for both classical and quantum computers. Module-LWE uses a structured variant that provides smaller key and ciphertext sizes while maintaining the security connection to hard lattice problems.
The Module-LWE problem has been extensively analyzed by the international cryptographic research community during the NIST PQC standardization process. No quantum algorithms are known that solve Module-LWE significantly faster than the best classical algorithms, which is why NIST selected it as the basis for the primary post-quantum key encapsulation standard. The security estimates for ML-KEM parameter sets are based on the best known classical and quantum lattice attacks as evaluated during the NIST standardization process.
FIPS 203 Parameter Sets: ML-KEM-512, -768, and -1024
NIST FIPS 203 defines three parameter sets offering different security-performance trade-offs. ML-KEM-512 targets NIST security level 1, providing security at least as strong as AES-128 against both classical and quantum adversaries. ML-KEM-768 targets NIST security level 3, corresponding to AES-192 security strength. ML-KEM-1024 targets NIST security level 5, corresponding to AES-256 security strength. NIST security levels are defined such that an attack against a level-N algorithm is at least as hard as breaking AES with a key size of 128, 192, or 256 bits.
NIST recommends ML-KEM-768 for most production deployments. It provides a strong security margin with acceptable performance and size characteristics. ML-KEM-1024 offers additional security margin for the highest-sensitivity applications at the cost of larger key and ciphertext sizes. ML-KEM-512 is suitable for resource-constrained environments where performance is a primary consideration and NIST level 1 security is deemed sufficient.
How ML-KEM Key Encapsulation Works
ML-KEM involves three operations: key generation, encapsulation, and decapsulation. Key generation produces a public key and a private key. The public key, derived from the Module-LWE problem instance, is transmitted to the other party. Encapsulation takes the public key, generates a random shared secret, and computes a ciphertext that encodes the shared secret encrypted under the public key. The encapsulator retains the shared secret and transmits the ciphertext.
Decapsulation takes the private key and the received ciphertext and recovers the shared secret. The security of the scheme relies on the hardness of the Module-LWE problem: without the private key, recovering the shared secret from the ciphertext requires solving Module-LWE, which is believed to be computationally hard for both classical and quantum computers. Both parties then derive symmetric session keys from the shared secret using a key derivation function such as HKDF.
Hybrid Key Establishment: ML-KEM Combined with ECDH
During the PQC migration period, ML-KEM is commonly deployed in hybrid mode alongside ECDH typically ECDH with Curve25519 (X25519). In a hybrid key establishment, both algorithms run in parallel during the TLS handshake. ML-KEM encapsulates a secret and ECDH establishes a separate secret. Both secrets are combined through a key derivation function to produce the final session key. An adversary must break both ML-KEM and ECDH simultaneously to recover the session key.
The IETF draft-ietf-tls-hybrid-design specification defines how hybrid key exchange is integrated into TLS 1.3. Hybrid TLS provides HNDL protection immediately: traffic captured today using hybrid ML-KEM plus ECDH cannot be decrypted using only Shor's algorithm, since the ML-KEM component is quantum-resistant. NSA CNSA 2.0 endorses hybrid deployment as an interim strategy for National Security Systems during the migration period, balancing security against backward compatibility requirements.
ML-KEM in TLS 1.3
TLS 1.3, defined in IETF RFC 8446, uses ephemeral key exchange as the mandatory key establishment mechanism. The IETF PQUIP working group and the TLS working group have developed specifications for integrating ML-KEM (and hybrid ML-KEM schemes) into TLS 1.3 using named group extensions. ML-KEM-768 and ML-KEM-1024 are the primary candidates for TLS deployment, with hybrid schemes combining ML-KEM-768 with X25519 being the most commonly implemented option.
Major browsers, TLS libraries (OpenSSL, BoringSSL, Rustls), and cloud providers have progressively added ML-KEM and hybrid TLS support following FIPS 203 finalization. Organizations deploying hybrid TLS should ensure both their TLS servers and the clients they serve support the same hybrid key exchange group. Server-side deployment is typically achievable before client-side support is universal, with hybrid servers supporting both hybrid and classical clients through TLS group negotiation.
ML-KEM in VPN and IPsec
VPN protocols using IKEv2 for key establishment are subject to the same ECDH vulnerability as TLS. IKEv2 supports negotiation of different key exchange methods through its traffic selector mechanisms, making ML-KEM integration feasible without protocol-level changes. The IETF has active work on ML-KEM integration for IKEv2 through the IPsecME working group. Enterprise VPN vendors and firewall manufacturers are progressively adding ML-KEM support to their IKEv2 implementations.
CNSA 2.0 requirements for National Security Systems explicitly include VPN and other IPsec-based communications as systems requiring migration to post-quantum key exchange. Defense contractors and federal agencies using commercial VPN products for sensitive communications should assess whether their VPN vendors have roadmaps for ML-KEM integration and whether hybrid deployment is available in the interim. NIST SP 1800-38 includes VPN infrastructure as a migration priority alongside TLS.
ML-KEM in SSH
SSH uses public-key cryptography for both key exchange and host/user authentication. The OpenSSH project, which implements the most widely deployed SSH client and server, added ML-KEM hybrid key exchange support in version 9.0 (2022) using a pre-standardization implementation, and updated to support FIPS 203 parameter sets following standardization. The IETF SSHM (Secure Shell) working group has produced specifications for post-quantum key exchange in SSH.
SSH administrators should upgrade to OpenSSH versions supporting standardized ML-KEM and configure hybrid ML-KEM key exchange as the preferred algorithm. Host key authentication in SSH uses digital signatures (typically ECDSA or EdDSA) rather than key exchange, which means host key authentication must separately migrate to ML-DSA or SLH-DSA to be fully post-quantum secure. Key exchange migration and host key authentication migration are separate steps in the SSH post-quantum migration process.
Performance Characteristics
ML-KEM offers strong performance relative to RSA key exchange and competitive performance compared to ECDH. Key generation, encapsulation, and decapsulation are all fast operations in software. ML-KEM-768 key sizes and ciphertext sizes are larger than ECDH key material but smaller than RSA key material. The primary performance impact of ML-KEM adoption in TLS is the increased size of the ClientHello message containing the ML-KEM public key, which may affect connections on high-latency or bandwidth-constrained links.
In hybrid mode, the performance overhead is the sum of ML-KEM and ECDH operations. For ML-KEM-768 plus X25519, this results in larger TLS handshake messages than ECDH alone but is generally acceptable for production network environments. Environments with strict latency requirements or resource-constrained embedded systems may need to evaluate ML-KEM-512 or pure ML-KEM (without ECDH hybrid) to optimize for performance, accepting a reduction in backward classical security.
Library and Ecosystem Support
ML-KEM support is available in major cryptographic libraries following FIPS 203 finalization. OpenSSL has added ML-KEM support in version 3.x with the FIPS provider. BoringSSL (used by Google and Android) has had ML-KEM support since before FIPS 203 finalization via its Kyber implementation. liboqs (Open Quantum Safe) provides a cross-platform reference implementation. Language-native libraries in Python, Go, Rust, and Java have post-quantum extensions available either natively or through extension packages.
Organizations integrating ML-KEM should verify that their library implementations use FIPS 203 parameter sets rather than pre-standardization Kyber parameter sets, which differ in ways that make them interoperability-incompatible. Pre-standardization implementations labeled as Kyber512, Kyber768, or Kyber1024 are not the same as FIPS 203 ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Libraries updated after FIPS 203 publication should support the finalized parameter sets; older implementations should be verified and updated.
Migration Path from ECDH to ML-KEM
Migrating from ECDH to ML-KEM for TLS key exchange follows a staged approach. In the first stage, deploy hybrid ML-KEM plus ECDH on servers while maintaining backward compatibility with classical clients. Server-side hybrid TLS deployment requires updating the TLS library and configuration to offer hybrid key exchange groups. Clients that do not support ML-KEM will negotiate ECDH as a fallback through standard TLS group negotiation.
In the second stage, expand hybrid TLS to client-side deployments. Once both client and server support hybrid ML-KEM, all new connections use hybrid key exchange and benefit from HNDL protection. In the final migration stage, after validating that all significant client populations support ML-KEM, remove ECDH-only fallback configurations on servers and configure ML-KEM (or hybrid ML-KEM) as the only accepted key exchange. The CISA joint guidance on quantum-readiness provides a structured framework for this staged migration approach.
References
- [1]NISTNIST FIPS 203(2024)Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)
- [2]
- [3]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [4]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [5]IETFIETF draft-ietf-tls-hybrid-design(2024)Hybrid key exchange in TLS 1.3
- [6]IETFIETF RFC 9180(2022)Hybrid Public Key Encryption (HPKE)
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-DSA Explained
ML-DSA (NIST FIPS 204) is the primary post-quantum digital signature algorithm, replacing ECDSA and RSA signatures in PKI, code signing, and authentication. This guide explains how it works, its parameter sets, and migration from ECDSA.