FIPS 203 — ML-KEM

FIPS 203 specifies the Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM), the post-quantum replacement for RSA and Diffie-Hellman key establishment. Derived from CRYSTALS-Kyber, it was finalized by NIST on 13 August 2024.

What ML-KEM does

A key-encapsulation mechanism (KEM) lets two parties agree on a shared secret over an insecure channel. The sender uses the recipient's public encapsulation key to produce a ciphertext and a 32-byte shared secret; the recipient decapsulates the ciphertext with their private key to recover the same secret. That secret then keys a symmetric cipher such as AES-256-GCM. In a protocol, ML-KEM provides the security function that replaces RSA key transport and Diffie-Hellman/ECDH key establishment, but its interface semantics are the KEM's Encaps/Decaps operations rather than the mutual key agreement of classical DH. It does not replace digital signatures; use ML-DSA, SLH-DSA, or future FN-DSA for those.

Parameter sets and sizes

Three parameter sets target NIST security categories 1, 3, and 5. ML-KEM-768 is the recommended default for general use. All sizes are in bytes.

Parameter set	NIST level	Encapsulation key	Decapsulation key	Ciphertext	Shared secret
ML-KEM-512	1	800	1632	768	32
ML-KEM-768	3	1184	2400	1088	32
ML-KEM-1024	5	1568	3168	1568	32

How it works internally

ML-KEM is built in two layers:

K-PKE — an internal IND-CPA-secure public-key encryption scheme based on Module Learning With Errors (Module-LWE). Polynomials live in a ring modulo q = 3329, and security comes from the hardness of recovering a small secret given noisy linear equations.
Fujisaki-Okamoto (FO) transform — wraps K-PKE to achieve IND-CCA2 security. On decapsulation, ML-KEM re-encrypts the recovered message and checks it matches the ciphertext, with implicit rejection (returning a pseudorandom secret) on failure so that decryption errors do not leak.

Hashing and randomness expansion use SHAKE-128 and SHAKE-256 (XOF functions from the Keccak/SHA-3 family), plus SHA3-256/512.

Warning

Never use the raw K-PKE directly — its CPA-only security is unsafe against active attackers. Always use the full ML-KEM KEM with the FO transform, and derive your symmetric keys from the shared secret via an approved KDF.

Security basis: Module-LWE

The conjectured hardness of Module-LWE is believed to resist both classical and quantum attackers, including Shor's algorithm (which breaks RSA/ECC but does not apply to lattice problems). The module structure balances the efficiency of ring-LWE with the conservative security margin of plain LWE.

Where it is used

TLS 1.3 key exchange, most commonly as the hybrid X25519MLKEM768 group. The relevant IETF TLS bindings are still at draft stage, so production deployments should track the final RFCs and library support.
SSH post-quantum key exchange.
IPsec/IKEv2, VPNs, and any protocol establishing session keys.
Hybrid public-key encryption (HPKE) and messaging protocols.

Code sketch

# Conceptual ML-KEM-768 flow (using an oqs-style API)
import oqs

with oqs.KeyEncapsulation("ML-KEM-768") as receiver:
    public_key = receiver.generate_keypair()     # 1184-byte ek

    # Sender encapsulates against the receiver's public key
    with oqs.KeyEncapsulation("ML-KEM-768") as sender:
        ciphertext, secret_send = sender.encap_secret(public_key)  # 1088-byte ct

    # Recipient recovers the same 32-byte secret
    secret_recv = receiver.decap_secret(ciphertext)

assert secret_send == secret_recv

Note

The shared secret is always exactly 32 bytes regardless of parameter set. Feed it through an approved KDF (e.g., HKDF) before use; do not use it directly as an encryption key for variable contexts.

ML-KEM deep dive →

Algorithm internals and design rationale.

What is a KEM? →

Key encapsulation explained.

Hybrid key exchange →

Combining classical and PQC.

Standards & references

FIPS 203 (ML-KEM) — the authoritative standard specified on this page.
NIST PQC project — program background and related publications.
Open Quantum Safe — liboqs implementations and interoperability tooling.
Resources — full standards register

FIPS 203 ML-KEM

FIPS 203 规范了基于模格的密钥封装机制 ML-KEM，它是 RSA 与 Diffie-Hellman 密钥建立的后量子替代方案。该标准源自 CRYSTALS-Kyber，由 NIST 于 2024 年 8 月 13 日正式发布。

ML-KEM 的作用

密钥封装机制 KEM 让双方能在不安全信道上协商出共享密钥。发送方使用接收方的公开封装密钥生成一段密文和一个 32 字节共享密钥，接收方用自己的私钥对密文解封装即可还原出同一密钥。该密钥随后用于为 AES-256-GCM 等对称密码提供密钥。ML-KEM 在协议中承担替代 RSA 密钥传输与 Diffie-Hellman/ECDH 密钥建立的安全功能，但其接口语义是 KEM 的 Encaps/Decaps，而不是传统 DH 的双方密钥协商。它并不替代数字签名；签名用途请使用 ML-DSA、SLH-DSA 或未来的 FN-DSA。

参数集与尺寸

三个参数集分别对应 NIST 安全类别 1、3、5。ML-KEM-768 是通用场景下的推荐默认值。所有尺寸单位为字节。

参数集	NIST 等级	封装密钥	解封装密钥	密文	共享密钥
ML-KEM-512	1	800	1632	768	32
ML-KEM-768	3	1184	2400	1088	32
ML-KEM-1024	5	1568	3168	1568	32

内部工作原理

ML-KEM 由两层构成：

K-PKE——一个内部的 IND-CPA 安全公钥加密方案，基于模带误差学习（Module-LWE）。多项式存在于模 q = 3329 的环中，安全性来自在给定带噪线性方程的情况下恢复小秘密的困难性。
Fujisaki-Okamoto FO 变换——将 K-PKE 封装以达到 IND-CCA2 安全。解封装时，ML-KEM 会重新加密所恢复的消息并校验其是否与密文一致，失败时采用隐式拒绝返回一个伪随机密钥，从而使解密错误不发生泄露。

哈希与随机数扩展使用 SHAKE-128 与 SHAKE-256，即 Keccak/SHA-3 家族的可扩展输出函数，以及 SHA3-256/512。

警告

切勿直接使用原始 K-PKE，它仅具备 CPA 安全，无法抵御主动攻击者。务必使用带 FO 变换的完整 ML-KEM，并通过经批准的 KDF 从共享密钥派生对称密钥。

安全基础模 LWE

模 LWE 的猜想困难性被认为可同时抵御经典与量子攻击者，包括 Shor 算法——该算法可攻破 RSA/ECC，但不适用于格问题。模结构在环 LWE 的高效率与纯 LWE 的保守安全裕度之间取得平衡。

应用场景

TLS 1.3——密钥交换，最常见的是混合群组 X25519MLKEM768。相关 IETF TLS 绑定仍处于草案阶段，生产部署应跟踪最终 RFC 与库支持。
SSH——后量子密钥交换。
IPsec/IKEv2——VPN，以及任何需建立会话密钥的协议。
混合公钥加密 HPKE——与消息传递协议。

代码示例

# ML-KEM-768 概念流程 使用 oqs 风格 API
import oqs

with oqs.KeyEncapsulation("ML-KEM-768") as receiver:
    public_key = receiver.generate_keypair()     # 1184 字节 ek

    # 发送方使用接收方公钥进行封装
    with oqs.KeyEncapsulation("ML-KEM-768") as sender:
        ciphertext, secret_send = sender.encap_secret(public_key)  # 1088 字节 ct

    # 接收方还原出相同的 32 字节密钥
    secret_recv = receiver.decap_secret(ciphertext)

assert secret_send == secret_recv

注意

无论哪个参数集，共享密钥始终恰为 32 字节。使用前请通过经批准的 KDF（例如 HKDF）处理，不要在变化的上下文中直接将其用作加密密钥。

标准与参考

FIPS 203 ML-KEM — 本页所述的权威标准。
NIST PQC 项目 — 项目背景与相关出版物。
Open Quantum Safe — liboqs 实现与互操作工具。
资源链接 — 完整标准登记册

Previous上一页← Standards Landscape标准全景 Next下一页FIPS 204 · ML-DSAFIPS 204 ML-DSA →