后量子迁移自查清单:从算法盘点到 hybrid TLS,2026 年该做完的 12 件事
为什么现在就要动
后量子迁移最容易被误解的一点:它不是等量子计算机造出来再说的事。三张已经公开的时刻表把起点钉在了现在:
| 时刻表 | 节点 |
|---|---|
| 美国联邦(CNSA 2.0 / OMB) | 2025-2030 逐步收紧,2030-2033 主体迁移完成 |
| 浏览器 / CA | Chrome、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 的那天,迁移就已经到你门口了。
相关阅读
相关工具
相关文章
个保法 PIA 影响评估自查:五类触发场景、评估三要素与实操框架
《个人信息保护法》第 55-56 条的个人信息保护影响评估(PIA):哪五类处理活动必须事前评估、评估报告的三要素结构、报告留存三年的要求,以及数据地图→风险矩阵→措施核对的自查框架。附与等保/密评的三位一体关系。
Passkeys 完全指南:为什么服务器再也存不了你的密码副本
Passkey(WebAuthn/FIDO2)的工作原理拆解:公私钥挑战响应怎么取代共享秘密、为什么天然抗钓鱼(origin 绑定)、服务器只存公钥意味着什么、同步与设备绑定两种形态的取舍,以及企业落地的三大难题(注册/多设备/恢复)。附与密码、TOTP 的能力对照表。
等保 2.0 自查清单:GB/T 22239 五个技术层面逐项对照,测评前的自查框架
网络安全等级保护 2.0(等保测评)前的实操自查框架:定级备案流程、五个技术层面 + 五个管理层面的高频检查项、二级与三级的差异要点、与密评的并行关系,以及送测前最常见的卡点与整改顺序。