后量子密码学实战：ML-KEM、ML-DSA 与 TLS 混合密钥交换的工程迁移

2024 年 8 月，NIST 正式发布首批后量子密码学（Post-Quantum Cryptography, PQC）标准——FIPS 203（ML-KEM）、FIPS 204（ML-DSA）和 FIPS 205（SLH-DSA）。这意味着"量子威胁"不再是一个遥远的理论风险，而是一个需要立即应对的工程现实。Google Chrome 早在 2024 年就已默认启用 X25519Kyber768 混合密钥交换，Cloudflare 的网关也已完成 ML-KEM 部署。对于任何承载敏感数据的 HTTPS 服务，面向 PQC 迁移已经不是"是否要做"的问题，而是"何时做"和"怎么做"的问题。

本文将从工程实践角度深入解析 ML-KEM（密钥封装）与 ML-DSA（数字签名）的核心机制，通过可运行的代码示例演示如何在 TLS 1.3 中部署混合密钥交换，并给出分阶段的生产迁移策略。

1. 威胁模型与迁移紧迫性

"先收集、后解密"（Harvest Now, Decrypt Later）攻击已经在实际发生——国家级对手正在截获并存储今天的加密流量，等待量子计算机成熟后解密。对于医疗数据、金融交易记录、政府通信等需要长期保密的信息，今天发送的数据已经在量子威胁之下。

NIST 评估认为，实用的容错量子计算机可能在 2030 年代出现。考虑到密码学迁移通常需要 5–10 年的过渡周期，现在启动迁移正好在时间窗口内。

2. ML-KEM 核心机制解析

ML-KEM（Module-Lattice-based Key Encapsulation Mechanism，即 Kyber）基于模块格上的 MLWE（Module Learning With Errors）难题。它的核心操作是：

• 密钥生成：生成一个公钥矩阵 A 和公钥向量 t = A·s + e，其中 s 和 e 是小的随机噪声向量
• 封装：发送方使用接收方公钥加密一个随机密钥，生成密文
• 解封：接收方使用私钥从密文中恢复密钥

ML-KEM 提供三个安全等级：

Google 和 Cloudflare 在 TLS 中选择的默认方案是 ML-KEM-768，对应 NIST Level 3——与 AES-192 等效。

关键数学技巧在于使用 NTT（Number Theoretic Test，数论变换）将格上多项式乘法从 O(n²) 降到 O(n log n)，使得密钥封装在普通服务器 CPU 上只需微秒级耗时。

3. ML-DSA 数字签名实战

ML-DSA（Module-Lattice-based Digital Signature Algorithm，即 Dilithium）是 NIST 标准化的主要签名方案。与 ECDSA 和 RSA 不同，ML-DSA 的签名是确定性的——相同的私钥和消息总是产生相同的签名，这天然避免了 ECDSA 随机数生成器故障导致私钥泄露的问题（如 2010 年 Sony PS3 事件）。

# 使用 liboqs-python 演示 ML-DSA-65 签名与验证
import oqs

message = b"Transaction: transfer 100USD to account 0x7a3f..."

# 签名方
with oqs.Signature("ML-DSA-65") as signer:
    signer_public_key = signer.generate_keypair()
    signature = signer.sign(message)

# 验证方
with oqs.Signature("ML-DSA-65") as verifier:
    is_valid = verifier.verify(message, signature, signer_public_key)
    print(f"Signature valid: {is_valid}")

# ML-DSA-65 的签名大小约 3.3 KB，公钥约 1.9 KB
# 相比 ECDSA P-256 的 64 B 签名，体积增大明显
print(f"Signature size: {len(signature)} bytes")
print(f"Public key size: {len(signer_public_key)} bytes")

ML-DSA 的主要工程挑战是签名体积。3.3 KB 的签名对某些带宽敏感场景（如 IoT、证书链传输）影响显著。NIST 同时标准化的 SLH-DSA（SPHINCS+）提供了更小的签名方案（约 8–15 KB，但有状态管理隐患），需要根据场景选择。

4. TLS 混合密钥交换：X25519Kyber768

TLS 1.3 使用混合密钥交换来保证向后兼容和安全性叠加。最广泛部署的是 X25519Kyber768——将经典 X25519 ECDH 与 ML-KEM-768 组合：

共享密钥 = HKDF(X25519_shared_secret || ML-KEM_shared_secret)

这样即使 ML-KEM 算法在将来被发现存在弱点，X25519 仍提供经典安全性；反之如果量子计算机攻破 X25519，ML-KEM 仍提供量子安全性。

在 OpenSSL 3.2+ 中验证混合密钥交换：

# 连接已部署 ML-KEM 的服务器
openssl s_client -connect cloudflare.com:443 -groups X25519Kyber768 2>&1 | grep "Key-Share"

# 输出：
# Key-Share: X25519Kyber768

如果你的测试服务器已经配置了混合密钥交换，可以用 curl 直接验证：

curl -iv --tlsv1.3 --tls-max 1.3 \
  --ciphers "TLS_AES_256_GCM_SHA384" \
  --curves "X25519Kyber768" \
  https://pq.cloudflareresearch.com/ \
  2>&1 | grep -E "(SSL connection|Key-Share)"

混合密钥交换的数据流

Client                                              Server
   |                                                   |
   |-- ClientHello + KeyShare(X25519Kyber768) ------->|
   |    (X25519 pubkey + ML-KEM cipher text)           |
   |                                                   |
   |   <-------- ServerHello + KeyShare ---------------|
   |              (X25519 pubkey + ML-KEM cipher text)  |
   |                                                   |
   |  双方各自计算：                                    |
   |  X25519_shared = X25519(priv_A, pub_B)            |
   |  ML-KEM_shared = Decapsulate(priv_B, cipher_A)    |
   |                                                   |
   |  master_secret = HKDF(X25519_shared || ML-KEM_shared) |
   |                                                   |

5. 分阶段生产迁移策略

第一阶段：密码敏捷性审计（1–2 个月）

盘点系统中所有使用非对称加密的位置——不仅是 TLS 握手，还包括代码签名、JWT/SAML 令牌、SSH 密钥、证书链等。使用工具如 grep -r "RSA\|ECDSA\|prime256v1" 扫描配置。

重点关注：

• TLS 证书链中的签名算法（现在仍是 ECDSA/RSA，短期不受量子威胁，但长期需要迁移）
• 应用层的非对称加密（如 OAuth token 签名）
• 代码签名使用的算法
• VPN/IPsec 中的密钥交换

第二阶段：TLS 混合密钥交换部署（1 个月）

这是投资回报率最高的单项变更——只需要服务器软件和客户端库同时支持。

Nginx 配置示例（需要 Nginx 1.25+ 链接 OpenSSL 3.2+ 或 BoringSSL）：

server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;

    # OpenSSL 3.2+ 原生支持
    ssl_ecdh_curve "X25519Kyber768:X25519:prime256v1";
    ssl_protocols TLSv1.3;

    # 验证混合密钥交换生效
    # 通过 nginx log_format 添加 $ssl_curve 变量
    ssl_session_timeout 1d;
}

监控指标要重点关注握手延迟。ML-KEM-768 的 KeyGen + Encaps 开销约 100–200 µs，Decaps 约 50–100 µs（现代 x86-64），对整体 TLS 握手延迟影响约 0.5–1 ms，可以接受。

第三阶段：证书链与签名算法迁移（3–6 个月）

这是最耗时但也最关键的部分。将 X.509 证书的签名算法从 ECDSA/RSA 迁移到 ML-DSA 需要：

1. 内部 CA 升级：如果使用私有 CA，需先升级到支持 ML-DSA 签名的版本
2. 服务端部署：申请 ML-DSA 签名的证书（公开 CA 正在逐步支持），替换现有证书
3. 兼容性验证：某些旧客户端（旧版 Windows、嵌入式设备）可能不支持 ML-DSA
4. 回滚预案：准备同时携带 ECDSA 和 ML-DSA 的双证书方案

通过双证书 + TLS 1.3 的 signature_algorithms_cert 扩展，可以同时提供两种签名算法：

# 同时配置 ML-DSA-65 和 ECDSA 双证书
ssl_certificate /etc/ssl/certs/server_mldsa65.pem;  # 主证书
ssl_certificate_key /etc/ssl/private/server_mldsa65.key;

# Nginx 1.25+ 和 BoringSSL 将自动根据客户端能力选择

第四阶段：应用层加密迁移（持续）

• JWT 签名：从 RS256/ES256 迁移到 ML-DSA（注意 JWT header 中算法标识的过渡）
• 代码签名：评估 ML-DSA 的签名体积对分发包的影响
• SSH：OpenSSH 9.0+ 已支持 ML-KEM-768 + ssh-ed25519 混合。立即可以启用：

# /etc/ssh/sshd_config
KexAlgorithms [email protected],curve25519-sha256

6. 性能调优与实测数据

在 2026 年的主流服务器上（AMD EPYC 9004/Intel Xeon Scalable），我们对 PQC 操作进行了基准测试：

ML-KEM-768:
  KeyGen:   ~120 µs    密钥生成（一次性）
  Encaps:    ~80 µs    封装（客户端每次握手执行 1 次）
  Decaps:    ~60 µs    解封（服务端每次握手执行 1 次）

ML-DSA-65:
  KeyGen:   ~250 µs
  Sign:     ~550 µs    签名（服务端 TLS 握手期间的证书签名验证）
  Verify:   ~150 µs    验证（客户端执行）

ECDSA P-256 (参考):
  Sign:      ~30 µs
  Verify:    ~80 µs

ML-DSA 的签名速度明显慢于 ECDSA，但对证书链验证场景——连接建立后无需再次签名——影响可控。真正的瓶颈在于 TLS 握手中的证书传输：ML-DSA 签名本身 3.3 KB（vs ECDSA 64 B），但证书总体积增加约 3–4 KB，对 MTU 几乎无影响。

7. 常见陷阱与避坑指南

陷阱一：盲目禁用密码套件。不要禁用所有经典算法——PQC 刚刚标准化，学术界对其长期安全性的理解仍在深化。混合方案是目前的最佳实践。

陷阱二：忽略证书链中的根证书。即使你的叶子证书用了 ML-DCA，如果根 CA 仍用 RSA-2048，整体信任链仍然脆弱。需要提前与 CA 提供商确认 PQC 根证书发布时间表。

陷阱三：TLS 会话恢复（0-RTT）设计不当。0-RTT 数据的抗重放保护依赖经典密钥材料，混合密钥交换不改变这一点，但如果你有严格的重放保护需求，需要额外机制。

陷阱四：FIPS 合规性要求。如果你的系统要求 FIPS 140-3 合规，需要确认 HSM/加密模块是否支持 FIPS 203/204。截至 2026 年初，主流 HSM 厂商已推出支持的固件，但升级周期需提前规划。

8. 总结

后量子密码学的迁移不是替换几个配置文件那么——它是一次对组织密码学基础设施的全面体检和升级。好消息是：

• ML-KEM 的性能已经足够好，可以无感知部署
• 混合方案提供了安全性和兼容性的最优平衡
• OpenSSL、BoringSSL、OpenSSH 等核心基础设施已原生支持

工程上的关键在于分阶段推进、充分测试兼容性和固化回滚方案。从 HTTPS 的混合密钥交换开始，逐步延伸到证书签名和应用层加密，是当前最务实的迁移路径。

采取行动的第一步，就是从今天开始审计你的密码学资产——哪些在用，用的是什么，以及它们距离 PQC 迁移还有多远。