Post-Quantum TLS 1.3

TLS 1.3 was one of the first mainstream protocols to add hybrid post-quantum key exchange. The mechanism is a hybrid key exchange that runs an elliptic-curve exchange and ML-KEM in parallel, so key establishment is quantum-resistant while keeping a classical safety net. Authentication still relies on classical certificates unless PQ signatures are also deployed. The named group is X25519MLKEM768.

The hybrid group: X25519MLKEM768

In TLS 1.3 the key exchange algorithm is advertised as a named group in the supported_groups extension. The current IETF draft hybrid group is:

X25519MLKEM768 — IANA TLS NamedGroup codepoint 4588 (0x11EC), marked Recommended. Combines X25519 (classical ECDH) with ML-KEM-768 (FIPS 203). It is specified by the IETF TLS ECDHE-MLKEM work (draft-ietf-tls-ecdhe-mlkem). The group is officially registered in the IANA TLS NamedGroup registry and marked Recommended; This remains tied to the IETF draft until the final RFC is published.
The earlier draft used the name X25519Kyber768Draft00, codepoint 0x6399, built on pre-standard Kyber. "Kyber" became ML-KEM when NIST finalized FIPS 203, and the codepoint changed accordingly. Treat 0x6399 as legacy.

The hybrid group combines the ECDHE shared secret and the ML-KEM shared secret in the order defined by the specification before feeding them into the TLS 1.3 key schedule. Implementers must not invent their own concatenation order or KDF, and in particular must not reuse the handling from the early X25519Kyber768Draft00. An attacker must break both X25519 and ML-KEM-768 to recover the key.

Warning

Hybrid key exchange (e.g., X25519MLKEM768, IANA group 0x11EC = 4588) protects the confidentiality of recorded sessions against Harvest Now, Decrypt Later (HNDL). It does NOT make the handshake fully post-quantum: if the certificate chain still uses RSA/ECDSA, authentication remains quantum-vulnerable in the long term. Full migration also requires PQ or hybrid signatures across PKI and certificates.

Where it works today

Hybrid key exchange is now widely available in major client stacks and increasingly deployed on servers, but adoption is uneven and authentication is still mostly classical:

OpenSSL 3.5+ natively supports ML-KEM / ML-DSA / SLH-DSA. In builds and configurations that enable the new TLS groups, hybrid groups such as X25519MLKEM768 may be offered or preferred by default, while keeping a classical X25519 fallback; confirm the actual behavior with the specific OpenSSL version, distribution build, and TLS configuration.
BoringSSL supports it, which is what backs Chrome.
Chrome enabled hybrid post-quantum key exchange by default on desktop in 2024, then extended it to Android; Firefox desktop enabled it by default around late 2024. By 2025, both Chrome and Firefox default to X25519MLKEM768.

Note

Apple enables quantum-secure TLS by default for system services and apps using URLSession or Network framework; apps using legacy or custom TLS stacks may need separate migration. Platform-level support does not mean every application or protocol is automatically post-quantum protected. Apps using custom TLS stacks, legacy libraries, embedded clients, or non-TLS protocols may require separate migration work.

Because it is negotiated, a hybrid-capable client falls back gracefully to classical X25519 against a server that does not offer the group.

Trying it with OpenSSL

With OpenSSL 3.5 or newer you can request the hybrid group explicitly and confirm what was negotiated:

# List the groups your OpenSSL build supports
openssl list -1 -tls-groups | grep -i mlkem

# Force the hybrid group when connecting
openssl s_client -connect example.com:443 -groups X25519MLKEM768

# In the handshake output, look for the negotiated group:
#   Negotiated TLS1.3 group: X25519MLKEM768

On the server side, configure the curves/groups preference so the hybrid group is offered first while keeping classical fallbacks:

# Example OpenSSL-style configuration
Groups = X25519MLKEM768:x25519:secp256r1

Authentication still lags: KEMTLS

Hybrid key exchange protects confidentiality against HNDL, but the certificates that authenticate the server are still signed with classical RSA/ECDSA. Moving authentication to PQC is harder because ML-DSA and SLH-DSA signatures and public keys are large, and the full chain is sent on every handshake — see X.509.

KEMTLS is a research approach that sidesteps signatures in the handshake entirely: instead of the server proving identity with a signature, the client encapsulates to the server's long-term KEM public key, and possession of the decapsulation key authenticates the server. This reuses efficient KEMs (like ML-KEM) for authentication and avoids large signatures on the handshake critical path. It is experimental, not yet standardized.

The IETF binding for ML-DSA certificate authentication in TLS, draft-ietf-tls-mldsa, is also still an Internet-Draft — so both the hybrid handshake and PQC authentication specs remain drafts even though the underlying NIST algorithms are final.

Standards & references

Warning

Do not confuse the legacy X25519Kyber768Draft00 (0x6399) with the standard X25519MLKEM768 (0x11EC). They are not interoperable and the draft group should be retired once peers support the final codepoint.

后量子 TLS 1.3

TLS 1.3 是最早加入混合后量子密钥交换的主流协议之一。其机制是一种混合密钥交换：并行运行椭圆曲线交换与 ML-KEM，使密钥建立具备抗量子能力同时保留经典安全网但若证书仍使用 RSA/ECDSA 认证链本身仍非抗量子。对应的命名分组是 X25519MLKEM768。

混合分组 X25519MLKEM768

在 TLS 1.3 中密钥交换算法以命名分组的形式在 supported_groups 扩展里通告。当前 IETF 草案规定的混合分组为：

X25519MLKEM768——IANA TLS NamedGroup 码点 4588（0x11EC）标记为 Recommended。将 X25519（经典 ECDH）与 ML-KEM-768（FIPS 203）组合。其规范来自 IETF TLS ECDHE-MLKEM 工作（draft-ietf-tls-ecdhe-mlkem）。该分组已在 IANA TLS NamedGroup 中正式登记并标记为 Recommended；在最终 RFC 发布前，这仍与 IETF 草案绑定。
早期草案使用的名称是 X25519Kyber768Draft00 码点 0x6399 基于尚未标准化的 Kyber。NIST 定稿 FIPS 203 后 Kyber 更名为 ML-KEM 码点也随之变更。0x6399 应视为遗留项。

混合组把 ECDHE 共享秘密与 ML-KEM 共享秘密按规范定义的顺序组合后输入 TLS 1.3 key schedule。实现者不应自行设计拼接顺序或 KDF，尤其不能沿用早期 X25519Kyber768Draft00 的处理逻辑。攻击者必须同时攻破 X25519 与 ML-KEM-768 才能还原密钥。

警告

混合密钥交换（如 X25519MLKEM768，IANA 组 0x11EC = 4588）仅保护"已录制会话"的机密性，抵御先收集、后解密（Harvest Now, Decrypt Later, HNDL）。它并不能让握手完全抗量子：只要证书链仍使用 RSA/ECDSA，认证层在长期仍可被量子攻击者伪造。完整迁移还需在 PKI / 证书侧引入 PQ 或混合签名。

当前可用范围

混合密钥交换已在主流客户端栈中广泛可用，并在服务端逐步部署，但整体采用仍不均衡，认证层仍主要依赖传统 RSA/ECDSA 证书：

OpenSSL 3.5+ 原生支持 ML-KEM / ML-DSA / SLH-DSA。在启用新 TLS 分组的构建与配置中，X25519MLKEM768 等混合分组可能被默认提供或优先使用，并保留经典 X25519 回退；具体行为以所用 OpenSSL 版本、发行版构建与 TLS 配置为准。
BoringSSL 支持它正是 Chrome 的底层库。
Chrome 2024 年在桌面端默认启用混合后量子密钥交换，随后扩展到 Android；Firefox 桌面端也在 2024 年底前后默认启用。到 2025 年，Chrome 与 Firefox 均已默认提供 X25519MLKEM768。

注意

Apple 的量子安全 TLS 默认适用于系统服务以及使用 URLSession 或 Network framework 的应用；使用旧版或自定义 TLS 栈的应用仍可能需要单独迁移。平台级支持并不意味着所有应用或协议都会自动获得后量子保护。使用自定义 TLS 栈、旧版密码库、嵌入式客户端或非 TLS 协议的系统，仍可能需要单独迁移。

由于采用协商机制当对端服务器不提供该分组时支持混合的客户端会平滑回退到经典 X25519。

用 OpenSSL 试一试

OpenSSL 3.5 或更新版本可显式请求混合分组并确认协商结果：

# 列出当前 OpenSSL 构建支持的分组
openssl list -1 -tls-groups | grep -i mlkem

# 连接时强制使用混合分组
openssl s_client -connect example.com:443 -groups X25519MLKEM768

# 在握手输出中查看协商出的分组：
#   Negotiated TLS1.3 group: X25519MLKEM768

在服务器侧配置曲线/分组优先级把混合分组排在最前同时保留经典回退项：

# OpenSSL 风格配置示例
Groups = X25519MLKEM768:x25519:secp256r1

认证仍然滞后 KEMTLS

混合密钥交换可抵御 HNDL 保护机密性但认证服务器身份的证书仍由经典 RSA/ECDSA 签名。把认证迁到后量子更难因为 ML-DSA 与 SLH-DSA 的签名和公钥都很大而完整证书链每次握手都要发送详见 X.509。

KEMTLS 是一种绕开握手签名的研究方案：服务器不再用签名证明身份而是由客户端向服务器的长期 KEM 公钥做封装服务器持有解封装密钥即完成身份认证。该方案复用高效的 KEM（如 ML-KEM）来做认证避免在握手关键路径上传输大签名。目前仍处于实验阶段尚未标准化。

IETF 为 TLS 中 ML-DSA 证书认证制定的绑定规范 draft-ietf-tls-mldsa 同样仍为 Internet-Draft——因此尽管底层 NIST 算法已定稿混合握手与后量子认证两套规范仍处于草案阶段。

标准与参考

警告

切勿将遗留的 X25519Kyber768Draft00（0x6399）与标准的 X25519MLKEM768（0x11EC）混淆。两者不能互通待对端支持最终码点后应停用该草案分组。

Previous上一页← Protocols Overview协议总览 Next下一页SSHSSH →