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 lattice-based KEM selected through the NIST PQC Standardization Project and is a primary post-quantum replacement for ECDH and RSA key transport in key establishment protocols. ML-KEM establishes shared secret keys between two parties over an untrusted channel, with security based on the Module Learning With Errors (Module-LWE) 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.
Source summary (not a direct quotation)
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.
Choose an ML-KEM parameter set according to the applicable security policy, protocol, and resource limits. ML-KEM-768 offers a category 3 option, while ML-KEM-1024 provides category 5 at larger key and ciphertext sizes. ML-KEM-512 targets category 1. FIPS 203 does not prescribe a universal production default; CNSA 2.0 specifies ML-KEM-1024 for NSS.
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 hybrid-design work describes combining key exchange algorithms in TLS 1.3. A correctly implemented ML-KEM and ECDH construction can provide protection against harvest-now-decrypt-later attacks under its cryptographic assumptions. NSA does not require hybrid deployment for NSS security. NSS operators must follow the current CNSA 2.0 FAQ and protocol-specific guidance rather than assume blanket hybrid approval.
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.
National Security System VPN deployments must follow applicable NSA profiles and CNSA 2.0 transition requirements. The December 2024 NSA FAQ discusses an IKEv2 interoperability case combining existing key establishment with ML-KEM-1024; it is not general permission to deploy arbitrary hybrid VPN schemes. Commercial users should assess vendor support, interoperability, and the requirements that apply to their systems.
ML-KEM in SSH
SSH uses public-key cryptography for both key exchange and host/user authentication. OpenSSH 9.0 (April 2022) made sntrup761x25519-sha512 the default post-quantum hybrid key exchange; it was not ML-KEM. OpenSSH 9.9 added mlkem768x25519-sha256, which became the default in OpenSSH 10.0 (April 2025). Post-quantum key exchange does not by itself make SSH host or user signature authentication post-quantum.
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 several cryptographic libraries following FIPS 203 finalization. OpenSSL 3.5 introduced native ML-KEM support; current documentation describes its default and FIPS providers. Provider availability is not proof that a particular installed module has completed FIPS validation. Organizations must verify the exact library version, finalized parameter sets, module validation status where required, and protocol integration.
Organizations integrating ML-KEM should verify that implementations use the finalized FIPS 203 algorithm and parameter sets rather than pre-standardization variants. Matching security levels or similar names do not prove interoperability. Check the library's versioned documentation and test against finalized ML-KEM-512, ML-KEM-768, or ML-KEM-1024 implementations.
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]NISTNIST SP 1800-38 (preliminary draft)(2023)Migration to Post-Quantum Cryptography (preliminary drafts and current project guidance)
- [3]NSANSA CNSA 2.0(2024)The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ
- [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.