PQC 迁移工程指南：不是把 RSA 换掉就完了——国密怎么办

量子计算机还没造出来。

但你今天在 TLS 里跑的每一条加密流量，都可能被人录下来了——存到硬盘上，等着将来 某天量子计算机成熟了再解密。这叫 Harvest Now, Decrypt Later（先存储后解密）。

如果你的数据保密期是 10 年，而量子计算机在 10 年内成熟，那你今天的加密就已经 不够用了。迁移到后量子密码学（Post-Quantum Cryptography, PQC）不是”等标准出来 再说”的问题，是现在就该动手的问题。

更麻烦的是：如果你在中国做业务，你还得同时应对国密合规。SM2 也是椭圆曲线—— 一样会被量子计算机击穿。你面临的不是”换一个算法”，而是双重迁移。

本文不讲量子力学，不推导数学公式。我们聊工程：hybrid 怎么做、证书链怎么迁、TLS 握手膨胀多少、国密 + PQC 怎么兼顾。

关于 PQC 算法本身的数学原理和分类，请参考 后量子密码学与抗量子算法。 本文聚焦于迁移工程。

一、为什么现有算法都要换

Shor 算法：公钥密码的末日

1994 年 Peter Shor 提出的量子算法可以在多项式时间内完成：

• 整数分解（破 RSA）
• 离散对数（破 DH / DSA）
• 椭圆曲线离散对数（破 ECDSA / ECDH / SM2）

注意最后一条。SM2 也是基于椭圆曲线的——它和 ECDSA 面临完全相同的量子威胁。 不存在”我用了国密就能抗量子”这回事。

当前估计，破解 RSA-2048 需要约 4000 个逻辑量子比特（纠错后），破解 256 位椭圆 曲线（包括 SM2）需要约 2500 个逻辑量子比特。

Grover 算法：对称算法的降维

Grover 算法将对称密码的暴力搜索复杂度从 \(O(2^n)\) 降到 \(O(2^{n/2})\)。

实际影响没那么恐怖：

结论：对称算法只需要把密钥长度翻倍。AES-256 和 SHA-256 在量子时代仍然安全。 真正需要换的是所有基于数学困难问题的公钥算法。

“先存储后解密”威胁模型

这是最常被低估的风险：

攻击者行为：
  2024: 大规模录制加密流量（成本极低，存储便宜）
  2025-2035: 等待量子计算机成熟
  203X: 用量子计算机解密历史流量

受影响数据：
  - 外交电报、军事通信
  - 金融交易记录
  - 医疗健康数据（保密期 50+ 年）
  - 商业机密、并购谈判
  - 个人隐私通信

如果你的数据保密需求是 \(T_{secret}\) 年，量子计算机预计在 \(T_{quantum}\) 年后成 熟，迁移需要 \(T_{migrate}\) 年，那么当：

\[T_{migrate} + T_{secret} > T_{quantum}\]

你现在就该开始迁移了。

时间线估计

各方的预测差异很大：

工程建议：按 2033 规划，按 2030 做准备。

二、NIST PQC 标准（ML-KEM / ML-DSA / SLH-DSA）

2024 年 8 月，NIST 正式发布了第一批后量子密码标准：

• FIPS 203: ML-KEM（基于 CRYSTALS-Kyber）
• FIPS 204: ML-DSA（基于 CRYSTALS-Dilithium）
• FIPS 205: SLH-DSA（基于 SPHINCS+）

后续还有 FN-DSA（基于 FALCON）和 HQC 在推进中。

ML-KEM：密钥封装机制

ML-KEM 是 TLS 密钥交换的主力替代方案，基于模格（Module Lattice）上的 Learning With Errors（LWE）问题。

ML-KEM 工作流程：
  1. Alice 生成密钥对 (ek, dk)，发送封装密钥 ek 给 Bob
  2. Bob 用 ek 封装一个共享密钥：(ct, ss) = Encaps(ek)
  3. Bob 发送密文 ct 给 Alice
  4. Alice 用 dk 解封装：ss = Decaps(dk, ct)
  5. 双方得到相同的共享密钥 ss

三个安全级别：

对比 X25519：公钥 32 字节，共享密钥 32 字节。ML-KEM-768 的公钥是 X25519 的 37 倍。

ML-DSA：数字签名

同样基于模格，用于替代 RSA/ECDSA/SM2 签名：

对比 ECDSA P-256：公钥 64 字节，签名 64 字节。ML-DSA-65 的签名是 ECDSA 的 52 倍。

SLH-DSA：基于哈希的保守方案

SLH-DSA（SPHINCS+）是纯粹基于哈希函数安全性的签名方案。它的安全假设最少——只要 哈希函数安全，签名就安全。代价是签名非常大：

公钥很小，但签名可以达到 49 KB。适合作为根证书签名的保守备选——根证书验证 频率低，大一点可以接受。

FN-DSA（FALCON）：紧凑但复杂

FN-DSA 基于 NTRU 格，签名比 ML-DSA 小得多：

但它需要浮点运算和离散高斯采样，实现难度高、侧信道防护难。目前不推荐在资源受限 环境使用。

算法大小对比一览

密钥交换公钥大小（bytes）：
  X25519:       |██| 32
  ML-KEM-768:   |████████████████████████████████████████████| 1184

签名大小（bytes）：
  ECDSA P-256:  |█| 64
  RSA-2048:     |████████| 256
  SM2:          |█| 64
  ML-DSA-65:    |████████████████████████████████████████████████████████████████████████████████████████████████████████████| 3309
  FN-DSA-512:   |██████████████████████| 666
  SLH-DSA-128s: |████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 7856

三、TLS 中的 PQC：握手大小膨胀

如果你读过 不到 500 行 C 实现 TLS 1.3 握手， 你知道 TLS 1.3 的 1-RTT 握手流程大致是：

现在的问题是：把 X25519 换成 ML-KEM-768，把 ECDSA 换成 ML-DSA-65，每条消息都 会膨胀。

Hybrid Mode：经典 + PQC 并行

直接切到纯 PQC 太激进——万一算法出问题呢？所以当前的主流方案是 Hybrid Mode：同时使用经典算法和 PQC 算法。

例如 TLS 1.3 密钥交换：

// 经典模式（当前）
// ClientHello.key_share: X25519 public key (32 bytes)

// Hybrid 模式（Chrome/Firefox 已支持）
// ClientHello.key_share: X25519 public key (32 bytes)
//                      + ML-KEM-768 encapsulation key (1184 bytes)

// Named group: x25519_mlkem768 (0x11EC, aka X25519Kyber768Draft00)

安全保证：只要其中一个算法没被破解，整体就是安全的。经典算法防当前威胁，PQC 算法防未来量子威胁。

ClientHello 大小膨胀

实测数据（Chrome 131+，x25519_mlkem768）：

膨胀了 4 倍多，但仍在单个 TCP 段内（< 1460 bytes MTU），不会导致 TCP 层面 的额外往返。

证书链膨胀：真正的痛点

密钥交换的膨胀还算温和，证书链才是大问题。

一条典型的 TLS 证书链包含 2-3 个证书（叶子 + 中间 CA + 可选根 CA），每个证书都 包含签名和公钥。

当前（ECDSA P-256 证书链，3 证书）：
  叶子证书:   公钥 64B + 签名 64B  →  ~600B（含其他字段）
  中间 CA:    公钥 64B + 签名 64B  →  ~600B
  根 CA:     公钥 64B + 签名 64B  →  ~600B
  总计:      ~1800B

ML-DSA-65 证书链：
  叶子证书:   公钥 1952B + 签名 3309B  →  ~5800B
  中间 CA:    公钥 1952B + 签名 3309B  →  ~5800B
  根 CA:     公钥 1952B + 签名 3309B  →  ~5800B
  总计:      ~17400B

Hybrid（ECDSA + ML-DSA-65）证书链：
  每证书额外 ~5200B
  总计:      ~18000B+

从 ~1.8 KB 膨胀到 ~17 KB，增长 接近 10 倍。

对 QUIC 的影响

QUIC（HTTP/3 的底层传输协议）的问题更大：

QUIC Initial 包大小限制：1200 bytes（RFC 9000）

问题：
  1. ServerHello + 证书链无法塞进一个 Initial 包
  2. 需要多个 QUIC 包 → 增加握手延迟
  3. 如果中间设备对 QUIC 包大小有假设 → 可能被丢弃

对策：
  - 证书压缩（RFC 8879, TLS Certificate Compression）
  - 使用 Merkle Tree Certificate（实验性）
  - 分离签名算法（CA 签名用 SLH-DSA，叶子用 ML-DSA）
  - 将 PQC 证书在 DNS 中预分发（DANE/TLSA）

实测数据

在标准 Linux 环境下，用 OpenSSL 3.5+（oqs-provider）对不同配置的 TLS 1.3 握手 进行了测试：

# 测试命令
openssl s_time -connect localhost:4433 -new -time 10 2>/dev/null | tail -1

# 也可以用 s_client 测单次握手时间
time openssl s_client -connect localhost:4433 \
  -groups x25519_mlkem768 \
  -sigalgs mldsa65 \
  </dev/null 2>/dev/null

结论：ML-KEM 密钥交换的开销可以忽略。瓶颈在 ML-DSA 签名验证和证书链 数据量。SLH-DSA 的性能代价太大，不适合高频 TLS 握手。

实测数据补充

上面的表格聚焦于数据量和握手时间，这里补充一份更完整的对比，包括各算法组合在线上传输字节数、内存峰值和 50ms RTT 下的端到端握手延迟。数据来源：OQS（Open Quantum Safe）项目 liboqs 0.10.x 基准测试 + NIST 提交文档 + 实测（Intel Xeon Gold 6348，OpenSSL 3.5 + oqs-provider）。

几个关键观察：

1. 50ms RTT 下三者握手时间几乎相同——因为 1-RTT 模式下 RTT 是主导因素（100ms 往返 vs 1-2ms 计算），PQC 的计算开销被网络延迟”淹没”了。PQC 的真正代价不在延迟，在带宽。
2. PQC 握手数据量是经典方案的 6-7 倍——22 KB vs 3.2 KB。在高并发场景（10 万 QPS），这意味着额外 ~2 GB/s 的出口带宽。
3. 内存峰值差 15 倍——180 KB vs 12 KB。对嵌入式设备（Cortex-M4, 256KB RAM）来说，PQC 握手几乎占满可用内存，需要精细的内存管理。
4. SM2 介于两者之间——比 X25519/Ed25519 慢（通用素数 vs Mersenne-like），但远比 PQC 紧凑。在量子威胁到来前，SM2 仍然是合规场景的合理选择。

Tongsuo 国密 + PQC 混合配置

铜锁（Tongsuo）是目前唯一同时支持国密算法和实验性 PQC 的开源 TLS 库。以下是从编译到测试的完整配置。

1. 编译 Tongsuo（开启 PQC 支持）

# CMakeLists.txt 或手动编译命令
# Tongsuo 使用 ./config 脚本，不是 CMake，但思路等价

# 克隆并编译
git clone https://github.com/Tongsuo-Project/Tongsuo.git
cd Tongsuo

# 关键：enable-pqc 开启后量子算法支持
./config enable-ntls enable-sm2 enable-sm3 enable-sm4 \
         enable-pqc \
         --prefix=/usr/local/tongsuo

make -j$(nproc)
sudo make install

2. openssl.cnf Provider 配置

# /usr/local/tongsuo/ssl/openssl.cnf
# 配置 PQC + 国密 provider

[openssl_init]
providers = provider_sect
ssl_conf   = ssl_sect

[provider_sect]
default = default_sect
# Tongsuo 内置国密 + PQC 支持，无需额外 provider
# 如果使用 OQS provider，取消注释以下行：
# oqsprovider = oqsprovider_sect

[default_sect]
activate = 1

# [oqsprovider_sect]
# module = /usr/local/lib/ossl-modules/oqsprovider.so
# activate = 1

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
# 优先 hybrid 密钥交换，回退经典
Groups = x25519_mlkem768:curveSM2:x25519:prime256v1
SignatureAlgorithms = sm2sig_sm3:ecdsa_secp256r1_sha256
MinProtocol = TLSv1.3

3. 测试 Hybrid 握手

# 启动服务端（SM2 证书 + 支持 PQC 密钥交换）
/usr/local/tongsuo/bin/openssl s_server \
    -accept 4433 \
    -sign_cert sm2_sign.crt -sign_key sm2_sign.key \
    -enc_cert sm2_enc.crt -enc_key sm2_enc.key \
    -enable_ntls \
    -groups x25519_mlkem768:curveSM2 \
    -ciphersuites "TLS_SM4_GCM_SM3:TLS_AES_128_GCM_SHA256"

# 客户端测试 hybrid 握手
/usr/local/tongsuo/bin/openssl s_client \
    -connect 127.0.0.1:4433 \
    -groups x25519_mlkem768 \
    -sigalgs "sm2sig_sm3" \
    -enable_ntls \
    -brief

# 期望输出包含：
#   Protocol version: TLSv1.3
#   Ciphersuite: TLS_SM4_GCM_SM3
#   Peer signing digest: SM3
#   Server Temp Key: X25519MLKEM768 (hybrid)

# 如果服务端不支持 ML-KEM，自动降级：
/usr/local/tongsuo/bin/openssl s_client \
    -connect 127.0.0.1:4433 \
    -groups curveSM2 \
    -sigalgs "sm2sig_sm3" \
    -enable_ntls \
    -brief

# 期望降级到纯 SM2 ECDHE

注意：截至 2026 年底，Tongsuo 的 PQC 支持仍标记为实验性。x25519_mlkem768 的 named group 编号可能随 IETF 标准化进程调整。生产环境使用前请关注 Tongsuo 的 release notes。国密 + PQC 的混合密码套件（如 sm2_mlkem768）尚未有行业标准定义——这是一个需要国家密码管理局和标准化组织推动的工作。

四、国密 + PQC：双重迁移困境

如果你还不了解国密 TLS 体系，可以先看 国密 TLS vs 标准 TLS 1.3。

SM2 的量子威胁

SM2 定义在一条 256 位的素数域椭圆曲线上（sm2p256v1）。和 NIST P-256 / Curve25519 一样，Shor 算法可以在量子计算机上高效求解椭圆曲线离散对数问题。

SM2 vs ECDSA 在量子威胁面前完全等价：

  SM2:    基于 sm2p256v1 椭圆曲线  →  Shor 算法可破
  ECDSA:  基于 P-256 椭圆曲线      →  Shor 算法可破
  EdDSA:  基于 Curve25519          →  Shor 算法可破

  所有椭圆曲线密码 → 量子不安全

SM4（对称加密，128 位密钥）受 Grover 算法影响，安全强度降至 64 位，理论上不够 安全。SM3（哈希，256 位）在量子时代仍然可接受。

中国的 PQC 研究现状

中国密码学界在 PQC 领域非常活跃：

• 格密码：中国科学院、清华大学等团队有大量基于格的方案研究
• Aigis-sig / Aigis-enc：清华大学提出的基于格的签名/加密方案
• LAC（Lattice-based Cryptosystem）：中科院提出，曾进入 NIST 第二轮候选
• NTRU 变体：多个团队在研究基于 NTRU 的优化方案

但截至 2026 年底，中国尚未发布自主的 PQC 国家标准。密码管理局的态度是： - 密切跟踪国际标准化进展 - 加速国内 PQC 研究 - 暂时不废弃 SM2，而是研究混合方案

迁移路径：SM2 → PQC

路径 A：国际 PQC 方案
  SM2 → ML-DSA / ML-KEM（NIST 标准）
  优势：成熟、互操作性好
  问题：合规——国密要求使用国产算法

路径 B：等待国密 PQC 标准
  SM2 → 国密 PQC（待发布）
  优势：满足合规要求
  问题：时间不确定，可能赶不上量子威胁

路径 C：混合过渡（推荐）
  SM2 → SM2 + ML-KEM/ML-DSA (Hybrid) → 国密 PQC
  优势：兼顾合规和抗量子
  问题：实现复杂，需要定义新的密码套件

合规 vs 安全的矛盾

这是一个非常现实的问题：

场景：一家中国银行的核心系统

合规要求：
  ✓ 必须使用 SM2/SM3/SM4（等保 / 密评要求）
  ✓ 必须通过密码应用安全性评估

安全需求：
  ✓ 数据保密期 30+ 年（金融数据、客户信息）
  ✓ 需要抗量子保护

矛盾：
  SM2 不抗量子 → 安全不够
  ML-KEM 抗量子 → 不合规
  
解法：Hybrid（SM2 + ML-KEM）
  → SM2 满足合规
  → ML-KEM 提供抗量子
  → 两个算法独立运行，不影响对方的安全性

混合方案：SM2 + PQC Hybrid

具体到 TLS 握手：

密钥交换 Hybrid：
  ClientHello.key_share:
    named_group: sm2_mlkem768 (自定义)
    key_exchange:
      sm2_public_key (64 bytes)    // 国密合规
      mlkem768_ek (1184 bytes)     // 抗量子

  共享密钥推导:
    ss = KDF(sm2_shared_secret || mlkem768_shared_secret)

签名 Hybrid：
  CertificateVerify:
    签名 = SM2_Sign(transcript) || ML-DSA-65_Sign(transcript)
    验证 = SM2_Verify(sig1) AND ML-DSA-65_Verify(sig2)

这种方案要求 TLS 库支持自定义 named groups 和双签名。OQS（Open Quantum Safe） 的 fork 提供了部分实验性支持，但距离生产可用还有距离。

五、工程迁移策略

不要试图一步到位。分阶段走：

阶段 1：密码算法清单和依赖分析

在写一行代码之前，先搞清楚你在用什么：

# 扫描代码中的密码算法使用
grep -rn "RSA\|ECDSA\|ECDH\|P-256\|secp256r1\|X25519" src/
grep -rn "SM2\|SM3\|SM4\|sm2p256v1" src/
grep -rn "AES-128\|AES_128" src/  # 可能需要升级到 AES-256

# 检查 TLS 配置
grep -rn "ssl_protocols\|ssl_ciphers\|tls_version" config/
openssl s_client -connect your-server:443 2>/dev/null | \
  grep -E "Protocol|Cipher|Server public key"

# 检查证书
openssl x509 -in cert.pem -noout -text | grep -E "Algorithm|Public-Key"

# 检查依赖库版本
openssl version     # 需要 3.5+ for PQC
python -c "import ssl; print(ssl.OPENSSL_VERSION)"

输出一份密码资产清单：

阶段 2：Hybrid Mode 过渡

目标：在不破坏兼容性的前提下，添加 PQC 保护。

# Nginx 配置（假设使用 oqs-provider 编译的 OpenSSL 3.5+）
ssl_protocols TLSv1.3;
ssl_ecdh_curves x25519_mlkem768:X25519:prime256v1;

# 优先使用 hybrid，回退到经典
# 客户端不支持 ML-KEM 时自动降级到 X25519

# Python (使用 oqs-python 或 pqcrypto 库)
import oqs

# Hybrid 密钥封装
kem_classic = X25519()
kem_pqc = oqs.KeyEncapsulation("Kyber768")

# 封装
classic_pk = kem_classic.generate().public_key
pqc_pk = kem_pqc.generate_keypair()

# 解封装后混合
shared_secret = hkdf(
    classic_shared_secret + pqc_shared_secret,
    info=b"hybrid-kem"
)

关键原则： - Hybrid 的两个算法必须独立——一个被破不影响另一个 - 共享密钥的合并必须使用密码学安全的 KDF，不能简单拼接 - 回退机制必须无缝——对不支持 PQC 的旧客户端保持兼容

阶段 3：证书链迁移

证书迁移是最复杂的部分，因为涉及整个 PKI 信任链。按自顶向下的顺序：

迁移顺序（关键！）：
  1. Root CA 先迁移（发 PQC 根证书 + 经典根证书）
  2. 中间 CA 迁移（用 PQC 根签发 PQC 中间证书）
  3. 叶子证书迁移（用 PQC 中间 CA 签发 PQC 叶子证书）

为什么要自顶向下？
  因为下层证书的签名需要上层证书验证。
  如果根 CA 还没支持 PQC，下层的 PQC 证书无法被验证。

双证书并行期间的处理：

服务端同时持有两套证书：
  cert_classic.pem  →  ECDSA 签名链
  cert_pqc.pem      →  ML-DSA 签名链

TLS 握手时：
  if 客户端支持 ML-DSA:
    发送 PQC 证书链
  else:
    发送经典证书链
  
  通过 signature_algorithms 扩展协商

阶段 4：纯 PQC 模式

当所有客户端和服务端都支持 PQC 后，淘汰经典算法：

检查清单：
  □ 所有客户端 TLS 库支持 ML-KEM / ML-DSA
  □ 所有 CA 可以签发 PQC 证书
  □ 所有 HSM 支持 PQC 密钥存储
  □ 所有监控 / WAF / IDS 可以解析 PQC 握手
  □ 性能测试通过（特别是高并发场景）
  □ 回退机制经过测试

  只有全部 ✓ 才能关闭经典算法

各阶段的风险和回退策略

六、实际问题清单

性能影响

PQC 的性能开销分两种：

计算开销（ML-KEM 很快，ML-DSA 可接受）：

// 粗略的 CPU 周期对比（x86-64, 单核）
//
// 密钥交换（KeyGen + Encaps + Decaps）:
//   X25519:       ~150,000 cycles
//   ML-KEM-768:   ~300,000 cycles  ← 只慢了 2x，可以接受
//
// 签名（Sign + Verify）:
//   ECDSA P-256:  ~500,000 cycles
//   ML-DSA-65:    ~800,000 cycles  ← 慢 1.6x
//   SLH-DSA-128f: ~50,000,000 cycles  ← 慢 100x，谨慎使用
//   FN-DSA-512:   ~600,000 cycles  ← 接近 ECDSA，但实现复杂

带宽开销（这才是大问题）： - 高并发 HTTPS 服务：每次握手多传 15-20 KB - 10 万 QPS × 20 KB = 2 GB/s 额外带宽 - 对 CDN 和边缘节点影响显著

硬件安全模块（HSM）的 PQC 支持

当前 HSM 厂商 PQC 支持情况（2026 年底）：

  Thales Luna:     ML-KEM ✓  ML-DSA ✓  SLH-DSA ✓  (firmware 7.x+)
  Entrust nShield: ML-KEM ✓  ML-DSA ✓  SLH-DSA △  (部分型号)
  AWS CloudHSM:    ML-KEM ✓  ML-DSA ✓  (通过 PQC 预览)
  国密 HSM:        SM2 ✓     PQC ✗    (等待标准)

  △ = 部分支持 / 实验性
  ✗ = 不支持

国密 HSM 目前不支持任何 PQC 算法。这意味着在国密场景下，PQC 密钥只能在软件 中管理——安全性显著降低。

嵌入式 / IoT 设备的 PQC 能力

ML-KEM-768 最低资源需求：
  RAM:   ~10 KB（算法执行）
  Flash: ~20 KB（代码）
  CPU:   ARM Cortex-M4 级别即可

ML-DSA-65 最低资源需求：
  RAM:   ~40 KB
  Flash: ~50 KB
  CPU:   ARM Cortex-M4（较慢但可用）

SLH-DSA：
  RAM 需求较低（无状态），但签名时间在低端 MCU 上可达数秒

结论：
  中高端 IoT（Cortex-M4+）→ ML-KEM + ML-DSA 可行
  低端 IoT（Cortex-M0/M0+）→ 可能只能用 ML-KEM，签名需要服务端处理
  极低端（8-bit MCU）→ PQC 基本不可行，需要架构层面解决

标准化时间线和互操作性

已确定：
  2024.08  FIPS 203/204/205 发布（ML-KEM, ML-DSA, SLH-DSA）
  2025     Chrome/Firefox 默认启用 X25519+ML-KEM-768
  2025     OpenSSL 3.5 内置 PQC 支持
  2026     FN-DSA (FALCON) 标准预计发布
  2026     HQC 标准化推进

预期：
  2027-28  主流 CA 开始签发 PQC 证书
  2028-30  企业级 TLS 产品全面支持 PQC
  2030+    国密 PQC 标准发布（预期）
  2033     NSA CNSA 2.0 截止日期

互操作性挑战：
  - 不同 TLS 库的 PQC 实现可能有差异（OID、编码格式）
  - Hybrid 模式的 named group 编号尚未完全统一
  - 国密 + PQC 的组合尚无行业标准

建议行动项

不管你在迁移的哪个阶段，现在可以做的事：

立即行动（0-6 个月）：
  □ 完成密码算法清单（阶段 1）
  □ AES-128 → AES-256（对称算法升级，工作量最小）
  □ 评估 TLS 库版本，规划升级到支持 PQC 的版本
  □ 在测试环境部署 Hybrid TLS，测量性能影响

短期（6-18 个月）：
  □ 生产环境启用 Hybrid 密钥交换（X25519+ML-KEM-768）
  □ 开始评估证书链迁移方案
  □ 与国密 HSM 厂商沟通 PQC 支持计划

中期（18-36 个月）：
  □ 证书链迁移（Root CA → 中间 CA → 叶子）
  □ 在高敏感系统启用 Hybrid 签名
  □ 跟踪国密 PQC 标准进展，准备切换

长期（36+ 个月）：
  □ 评估纯 PQC 模式
  □ 淘汰不支持 PQC 的客户端
  □ 全面切换到国密 PQC（标准发布后）

总结

PQC 迁移不是”等量子计算机来了再说”。先存储后解密攻击意味着今天的加密流量 在明天就可能被破解。

几个关键要点：

1. 所有公钥算法都要换——RSA、ECDSA、SM2 一个都跑不掉
2. 对称算法升到 AES-256 就够了——Grover 算法的威胁有限
3. Hybrid 模式是当前最佳实践——经典 + PQC 双保险
4. 证书链膨胀是最大的工程挑战——比密钥交换难处理得多
5. 国密场景更复杂——SM2 合规和 PQC 安全需要同时满足
6. 不要等——现在就开始做密码资产清单和 Hybrid 测试

延伸阅读

• 后量子密码学与抗量子算法 — PQC 算法的数学原理和安全证明
• 不到 500 行 C 实现 TLS 1.3 握手 — 理解 TLS 1.3 协议细节，才能理解 PQC 怎么嵌入
• 国密 TLS vs 标准 TLS 1.3 — SM2/SM3/SM4 在 TLS 中的使用，国密合规的完整图景

参考资料

1. NIST FIPS 203 - ML-KEM
2. NIST FIPS 204 - ML-DSA
3. NIST FIPS 205 - SLH-DSA
4. RFC 9180 - Hybrid Public Key Encryption (HPKE)
5. IETF draft-ietf-tls-hybrid-design - Hybrid Key Exchange in TLS 1.3
6. NSA CNSA 2.0 Algorithm Suite
7. Open Quantum Safe (OQS) Project
8. Cloudflare: Post-quantum TLS performance
9. Chrome: Post-Quantum Key Agreement
10. GM/T 0009-2023 SM2 密码算法使用规范
11. 密码法（2020 年 1 月 1 日施行）
12. PQCrypto 2024 会议论文集