跳到主要内容
加密解密2026-10-04Begin4 分钟阅读

后量子迁移自查清单:从算法盘点到 hybrid TLS,2026 年该做完的 12 件事

为什么现在就要动

后量子迁移最容易被误解的一点:它不是等量子计算机造出来再说的事。三张已经公开的时刻表把起点钉在了现在:

时刻表节点
美国联邦(CNSA 2.0 / OMB)2025-2030 逐步收紧,2030-2033 主体迁移完成
浏览器 / CAChrome、Firefox 已默认启用 X25519+ML-KEM 混合密钥交换;PQC 证书里程碑集中在 2026-2028
欧盟 / 英国 NCSC参照 NIST 标准族(FIPS 203/204/205),2030 年前后完成

Windows 在 2026 年 7 月把混合 ML-KEM 直接带进了 Schannel TLS 栈。也就是说,你的用户此刻访问支持混合握手的站点时,链路里可能已经在跑后量子密钥交换了——问题是大多数服务端还没跟上。

另一个驱动是「先截存、后解密」(harvest now, decrypt later,详见配套文章):今天被记录的 RSA/ECC 加密流量,等量子计算成熟后可以回溯解密。数据寿命长的系统,等不起。

迁移的自查框架:四步 + 12 项

第一步:算法盘点(CBOM)

迁移的第一件事不是换算法,是搞清楚你现在用着什么。 cryptographic bill of materials(CBOM,密码物料清单)要覆盖的位置比想象中多:

  • TLS 证书与握手算法(RSA / ECDSA / ECDHE 曲线)
  • JWT / OAuth 的签名算法(RS256?还是 ES256?)
  • SSH 主机密钥与用户密钥
  • 代码签名 / 包签名(npm、maven、内部发布管道)
  • 数据库与备份的静态加密
  • VPN / IPsec / 内部服务间通信
  • 第三方依赖里硬编码的算法调用

盘点的输出是一张「算法 × 位置 × 寿命」表。多数团队第一次做会发现自己拥有的 RSA 密钥比想象多一个量级。

第二步:按暴露度排优先级

不是所有密码学资产都要同时迁。排序依据两条轴:

  • 数据寿命:这条链路保护的数据,多少年后仍然是机密?(医疗档案、基因数据 > 普通会话)
  • 签名寿命:这个签名的验证窗口多长?(根证书 10-20 年 > 短时 JWT)

寿命越长,HNDL 风险越高,越先迁。

第三步:hybrid TLS(性价比最高的一步)

迁移不是把 RSA 换成 ML-KEM 的单变量替换,行业共识是混合模式:经典算法 + 后量子算法同时跑,任何一个被攻破,另一个仍然保护会话。

服务端现状(2026-10):

  • OpenSSL 3.5+ 提供 X25519MLKEM768 密钥交换组
  • 主流 CDN / 负载均衡陆续开放开关
  • 浏览器侧(Chrome/Firefox)已默认支持,服务端开了就能协商上

一个务实提醒:ML-KEM 的公钥/密文比 X25519 大一个量级,握手包体积增加会挤到 TCP 初始拥塞窗口——高延迟链路上首字节时间可能轻微回退,灰度时盯一下。

第四步:crypto-agility(别让下一次迁移还这么痛)

  • 算法选择是否配置化(而不是散落在代码里的硬编码 RS256)?
  • 证书轮换流程是否自动化到「一周内全量换发」能力?
  • 依赖库是否支持可插拔 provider(OpenSSL 3.x provider / JDK provider)?
  • 是否有算法下线监控(日志里还有多少 RSA-1024 握手在发生)?

12 项 checklist 汇总

  • 完成 CBOM:列出全部公钥密码学使用位置
  • 标注每条链路的数据寿命与签名寿命
  • 识别 HNDL 高危链路(寿命 > 7 年的机密数据)
  • TLS 终结层(CDN / 负载均衡 / nginx)确认 hybrid X25519+ML-KEM 可用性
  • 灰度开启 hybrid TLS 并监控握手成功率与 TTFB
  • 新签证书一律 ≥ RSA-3072 或 ECDSA P-256 起步
  • 内部 SSH 开始分发 Ed25519 主机密钥
  • JWT 签名从 RS256 迁向 ES256/EdDSA 的评估
  • 确认依赖库 PQC 支持版本(OpenSSL 3.5+、liboqs、Bouncy Castle)
  • 建立算法下线监控面板
  • 证书轮换自动化演练一次
  • 在安全政策文档里写入 PQC 迁移时间表

实现注记 / Implementer's note

做这个站的加密工具时我对浏览器侧的现状体会很深:WebCrypto(crypto.subtle)至今只有 RSA/ECDH/AES 这些经典算法,ML-KEM 没有原生接口——想在浏览器里跑 PQC 只能走 wasm(liboqs 一族),体积和加载成本都还没到「随手开个在线工具」的程度。这也是站里 RSA 工具仍然以经典算法为教学对象的原因:先让读者把经典体系吃透,PQC 的差异(密钥尺寸、封装语义)才有了对照系。顺带一提,用证书解码器看一张你自己的证书,签名算法一栏今天几乎必然还是 RSA/ECDSA——等你在里面看到复合 PQC OID 的那天,迁移就已经到你门口了。

相关阅读