Xray 科普 · TLS 1.3 · Post-Quantum Cryptography

Xray 科普：TLS 的三个加密环节与后量子加密

从 TLS 1.3 握手流程出发，区分密钥交换、身份认证与数据加密；理解 ML-KEM、ML-DSA 的作用、性能代价，以及浏览器和服务器软件的支持边界。

Key Exchange · 密钥交换Authentication · 身份认证Encryption · 数据加密Xray / Nginx / Caddy / 浏览器

先记住：后量子迁移不是把所有加密算法都换掉。当前最重要的变化是：用 ML-KEM 增强密钥交换，逐步用 ML-DSA 等算法升级数字签名；数据面仍主要使用 AES-GCM 或 ChaCha20-Poly1305 这样的对称 AEAD 算法。最新版 Xray 支持 X25519MLKEM768 和 ML-DSA-65（用于 REALITY 额外签名验证）。

1三个环节的常见算法与后量子方案

01 · Key Exchange

密钥交换：双方如何得到共享秘密？

传统算法

X25519P-256 / P-384 ECDHE

后量子方案

ML-KEM-768X25519MLKEM768

✓ Xray 支持：X25519MLKEM768（REALITY / TLS 混合密钥交换；需客户端、服务端及 target 支持）。

X25519MLKEM768 是混合密钥交换：同时结合 X25519 与 ML-KEM-768。TLS 按规范组合两部分共享秘密，再派生会话密钥；它不是身份认证算法。

02 · Authentication

身份认证：如何证明服务器身份？

传统签名算法

ECDSARSA-PSSEd25519

后量子签名

ML-DSA-44 / 65 / 87SLH-DSA

✓ Xray 支持：ML-DSA-65（REALITY 额外签名验证；不是通用 TLS 证书链认证）。

ML-DSA（前身为 CRYSTALS-Dilithium）用于数字签名。TLS 中要区分两件事：CertificateVerify 的握手签名，以及 CA 对证书的签名。完整迁移还涉及证书链、根信任库和客户端互通；仅有密码库支持不等于公网 HTTPS 已普遍采用。

03 · Encryption

数据加密（Encryption）：如何保护实际传输内容？

当前常见 AEAD 算法

AES-128-GCMAES-256-GCMChaCha20-Poly1305

后量子方案

目前无需专门替换

对称密码受到 Grover 算法的影响与公钥密码不同。使用足够长的密钥（例如 AES-256）仍是主流的量子风险缓解方式；TLS 1.3 没有一个与 ML-KEM 对应的“后量子 AES”。

2TLS 1.3：三个环节如何衔接

客户端
浏览器 / Xray 客户端

TLS 1.3 握手

服务器
Nginx / Caddy / Xray

① 密钥交换Key Exchange

ClientHello → 支持的密钥交换组与密钥份额（Key Share）

← ServerHello：选择密钥交换组并完成协商

目标：双方协商出共享秘密，再由 TLS 密钥调度派生握手密钥和流量密钥。

② 身份认证Authentication

← Certificate：服务器证书链

← CertificateVerify：服务器对握手上下文签名

Finished：双方验证握手完整性

目标：验证服务器身份和握手完整性。证书链签名与 TLS 握手签名相关，但属于不同的验证环节。

③ 数据加密Encryption

应用数据 ⇄ 使用流量密钥进行 AEAD 保护

HTTPS / HTTP/2 / HTTP/3（QUIC）等

目标：使用 AEAD 算法保护实际传输内容的机密性与完整性。在 TLS 术语中，这属于记录层保护（Record Protection）；本图沿用与前两项一致的功能名称 Encryption。

TLS 1.3 重要细节：ServerHello 之后，Certificate、CertificateVerify、Finished 等后续握手消息本身也已由握手流量密钥加密；第 ③ 环节重点展示的是握手完成后的应用数据保护。

密钥协商 + 身份验证 → 握手完成 → 使用流量密钥保护应用数据

3浏览器支持：密钥交换已先行，公网后量子证书仍在迁移

重要区分：浏览器支持 X25519MLKEM768（或相应的后量子混合组），不代表它已经普遍接受 ML-DSA 公网证书。浏览器版本、操作系统 TLS 后端、发行渠道和策略设置都会影响实际结果。

浏览器	后量子混合密钥交换	ML-DSA 公网证书认证	解读
Chrome / Chromium 系	已部署 / 支持	生态迁移中	具体能力随版本和平台变化；私有 PKI、实验性支持与公共根信任不是同一回事。
Microsoft Edge	随 Chromium 演进	生态迁移中	不能仅凭 Chromium 版本推断所有 Windows TLS 场景的证书能力。
Firefox	逐步支持 / 已部署	尚非普遍公网部署	以具体发行版本和平台测试结果为准。
Safari	随系统版本演进	生态迁移中	iOS、macOS 的系统 TLS 与浏览器版本紧密相关。
Brave	基于 Chromium	生态迁移中	具体支持取决于 Brave 版本及底层平台。

截至 2026-11：浏览器的后量子混合密钥交换已比后量子证书认证成熟得多。不要把“能协商 X25519MLKEM768”理解成“已普遍信任 ML-DSA 公网证书”；私有 PKI、实验开关、TLS 库支持与公共 Web PKI 信任是不同层次。

4服务器与代理软件：看底层 TLS 实现，不只看软件名称

软件 / 组件	后量子密钥交换	后量子签名 / 认证	关键说明
Nginx	OpenSSL 3.5+ 可用	取决于 OpenSSL / TLS 互通	Nginx 通常通过 OpenSSL 提供 TLS。OpenSSL 3.5 系列支持 X25519MLKEM768；ML-DSA 算法及 TLS 1.3 签名方案还要核实 OpenSSL 版本、provider、证书链和客户端兼容性。仅安装较新 Nginx 不足以证明已启用。
Caddy	Go 1.24+ 默认支持	Go 1.27+ TLS 1.3 支持	Caddy 使用 Go TLS。Go 1.24 起默认包含 X25519MLKEM768；Go 1.27 起 crypto/tls 支持 ML-DSA TLS 1.3 签名。但证书签发、证书链验证及浏览器公共信任仍需单独确认。
Xray / REALITY	支持 X25519MLKEM768	可选 ML-DSA-65 额外验证	REALITY 的 mldsa65Seed / mldsa65Verify 是对 REALITY 返回证书增加的专用后量子签名验证，不等同于通用 TLS 的 ML-DSA 证书链或 CertificateVerify 部署。以 Xray 日志中的实际协商与验证结果为准。

5关键性能与尺寸：代价分别在哪里？

密钥交换：增加握手数据与计算

ML-KEM-768 的公钥为 1,184 B，密文为 1,088 B。混合组比纯 X25519 的 Key Share 大得多，可能增加握手分片或额外网络往返的风险。

性能数字不要绝对化：额外 CPU 时间取决于 CPU、TLS 库、实现和连接模式。不能把某一台机器测得的“慢 1.3 倍”当作所有环境的固定结论；持续传输吞吐通常不是 ML-KEM 直接造成的瓶颈。

X25519MLKEM768 的主要影响发生在握手阶段；长连接通常能摊薄这部分成本。

身份认证：签名和证书体积显著增加

3,309 BML-DSA-65 签名

1,952 BML-DSA-65 公钥

约 64–72 BECDSA P-256 签名

ML-DSA-65 的标准签名长度固定为 3,309 bytes = 3.309 kB = 3.23 KiB；公钥为 1,952 bytes。这里的 3.23 KiB 仅指签名原始字节，不含证书 ASN.1/DER 编码、扩展、证书链及 TLS 消息开销。ECDSA P-256 的签名通常约 64 bytes（TLS/X.509 DER 编码长度会有变化）。

缓解方向包括证书链优化、TLS 证书压缩，以及 Merkle Tree Certificates（MTC）等新型信任证明方案；MTC 仍属于生态演进路线，不应理解为当前所有浏览器和 CA 已经部署。

数据加密（Encryption）：通常不需要换成“后量子对称算法”

Grover 算法在理想模型下可降低穷举搜索复杂度的平方根级别，因此 AES-256 常被视为提供约 128-bit 的量子搜索安全余量。ChaCha20 也是 256-bit 密钥的现代对称算法。两者仍需正确实现、使用安全随机数和协议规定的 nonce 管理。

6Xray 使用者的实用结论

01 · Key Exchange + Authentication

密钥交换与认证：主要影响握手阶段

对已经建立的 Xray 连接，密钥交换与身份认证通常不会降低持续转发吞吐；额外计算和握手数据主要发生在建连阶段。ML-KEM / ML-DSA 的具体开销仍取决于实现、设备性能和连接频率。

在客户端与服务端支持的前提下，可使用并验证 X25519MLKEM768。REALITY 的 ML-DSA 额外验证也应根据实际配置与日志确认。

02 · Encryption

数据加密（Encryption）：继续使用成熟 AEAD

继续使用 AES-256-GCM 或 ChaCha20-Poly1305。它们负责保护实际传输数据的机密性与完整性，目前没有必要为了后量子迁移而更换成所谓的“后量子数据加密算法”。

03 · Enable X25519MLKEM768

尽快更新 Xray，启用后量子混合密钥交换

建议：将 Xray-core 客户端和服务端都升级到最新稳定版。

确认 REALITY target 支持：在客户端执行 xray tls ping 你的-target-域名，将域名替换为 REALITY 配置中的实际 target；必要时指定端口，并检查输出中是否支持 X25519MLKEM768。