迁移项目每天都要回答的四个问题：哪个算法定案了、哪个协议能用了、哪个库的哪个版本实现了、哪条死线先到。本表按算法 / 协议 / 实现 / 部署四层横向对照，逐条标注标准化阶段 S1–S5，并列出中国商用密码线、境内外双轨合规与出口管制边界。只收录可被官方文件核验的状态。
| 管辖 / 框架 | 节点 | 要求 | 影响面 |
|---|---|---|---|
| 美国 NSA CNSA 2.0 | 2025 | 浏览器、服务器、云服务须支持并优先CNSA 2.0 | 对美国家安全系统供货的全部软件 |
| 美国 NSA CNSA 2.0 | 2026 | 传统网络设备(VPN、路由器)须支持并优先 | 网络设备厂商 |
| 美国 NSA CNSA 2.0 | 2027-01-01 | 软件 / 固件签名进入排他性使用;新系统与采购须支持抗量子 | 全部对美国防供货方,最早的硬死线 |
| 美国 NSA CNSA 2.0 | 2027 | 操作系统须支持并优先 | OS 厂商 |
| 美国 NSA CNSA 2.0 | 2030 | 网络设备排他性使用;无法升级的遗留设备须完成迁移 | 硬件替换周期由此倒推 |
| 美国 NSA CNSA 2.0 | 2031 | 覆盖类别内强制使用,除非明确豁免 | — |
| 美国 NSA CNSA 2.0 | 2033 | 操作系统、定制应用、云服务排他性使用 | — |
| 美国 NSA CNSA 2.0 | 2035 | 全部国家安全系统完成抗量子(对齐 NSM-10) | — |
| 欧盟 协调实施路线图 | 2026 年底 | 成员国须制定国家 PQC 路线图,并启动高 / 中风险场景试点 | 欧盟成员国关基 |
| 欧盟 协调实施路线图 | 2030 年底 | 高风险场景迁移完成 | — |
| 欧盟 协调实施路线图 | 2035 | 多数中低风险系统完成 | — |
| 英国 NCSC | 2028 | 关基运营者完成密码依赖测绘 | 英国关基,测绘先于迁移 |
| 英国 NCSC | 2035 | 完成 PQC 迁移 | — |
| 中国 三部门令第 5 号 | 2025-08-01 | 《关键信息基础设施商用密码使用管理规定》施行:三同步 + 建成运行后每年至少一次密评 | 境内全部关基运营者,已生效 |
| 中国 三部门令第 5 号 | 每年 1 月 31 日前 | 向保护工作部门报告上一年度商密使用情况与密评开展情况 | 固定年度申报死线 |
| 中国 商用密码标准研究院 | 2026-06-30 | 新一代公钥密码算法提案提交截止(已截止) | 国内算法供给侧 |
| 中国 商用密码标准研究院 | 形式审查后 | 公布第一轮评估候选算法 | 本表最高优先级待跟踪项 |
最早的实质死线是 2027-01-01 的软件 / 固件签名排他性使用,不是各家宣传里常引的 2030 或 2035。签名排他早于加密迁移,因为签名一旦被伪造不可追溯,而「先收割后解密」至少还留有时间窗。
境内机构还有一条容易被忽略的节奏:三部门令第 5 号已于 2025-08-01 生效,关基每年至少一次密评、每年 1 月 31 日前申报。这条不是未来的死线,是已经在跑的年度循环。
| 算法 | 类型 | 标准编号 | 状态 | 关键节点 |
|---|---|---|---|---|
| ML-KEM(原 CRYSTALS-Kyber) | 密钥封装 | FIPS 203 | S1 已定案 | 2024-08-13 发布 |
| ML-DSA(原 CRYSTALS-Dilithium) | 数字签名(格) | FIPS 204 | S1 已定案 | 2024-08-13 发布 |
| SLH-DSA(原 SPHINCS+) | 数字签名(无状态哈希) | FIPS 205 | S1 已定案 | 2024-08-13 发布 |
| FN-DSA(原 Falcon) | 数字签名(格,签名体积小) | FIPS 206 | S2 草案 | 定稿预计 2026 年底至 2027 年初 |
| HQC | 密钥封装(纠错码) | 待编号 | S3 起草中 | 2025-03-11 入选;FIPS 预计 2027 |
| LMS / HSS、XMSS / XMSS^MT | 数字签名(有状态哈希) | NIST SP 800-208 | S1 已定案 | 仅限固件 / 软件签名等受控场景 |
| 下一代国密公钥算法 | 公钥密码 | 未定 | S5 征集评估中 | 见第 5 节 |
HQC 与 ML-KEM 数学基础不同(纠错码 vs 格),NIST 并行标准化是为防单一数学假设被攻破——选型时应把 HQC 当作保险而非替代品,系统须支持算法可替换(crypto-agility),否则格假设一旦出问题需要二次全量迁移。
有状态哈希签名(LMS / XMSS)安全性最保守,但私钥状态一旦重用即彻底失效,运维要求远高于普通签名。RFC 10033 就是为这件事写的。
| 项目 | 起始版本 | 覆盖算法 | 默认启用 | 备注 |
|---|---|---|---|---|
| OpenSSL | 3.5.0(2025-04-08) | ML-KEM / ML-DSA / SLH-DSA | 是 | LTS 支持至 2030-04-08,覆盖全部主要迁移死线;默认组含 X25519MLKEM768 |
| BoringSSL / Chrome | Chrome 131 起 | ML-KEM | 是 | 由预标准 Kyber 切换到 FIPS 203 定稿版 |
| AWS-LC | 见备注 | ML-KEM / ML-DSA | — | 首个把 ML-KEM 纳入 FIPS 140-3 验证的开源模块;不含 SLH-DSA |
| Go 标准库 | 1.24 | ML-KEM(crypto/mlkem) | — | 多数应用使用 ML-KEM-768 参数集 |
| OpenSSH | RHEL 10.0 随附版 | mlkem768x25519-sha256、sntrup761x25519-sha512 | — | 混合密钥交换 |
| liboqs | 0.16.0(2026-07-09) | 全算法族(含候选算法) | — | liboqs-python 0.16.0(2026-07-23)、liboqs-go 0.16.0(2026-08-11) |
| GnuTLS / NSS | RHEL 10.0 随附版 | ML-KEM(TLS) | — | 与 OpenSSL 同批进入发行版 |
选型判据里最容易被忽略的一条是 FIPS 验证边界:AWS-LC 把 ML-KEM 纳入了 FIPS 140-3 验证,liboqs 没有。研究与原型可用 liboqs,受 FIPS 约束的生产系统不能直接用它交付。
本节只保留中文读者常用的几项。完整的厂商 × 产品 × 算法能力矩阵(70+ 家,含 HSM、CA、签名服务、IP core)见 PKI Consortium 维护的 PQC Capabilities Matrix(PQCCM),GitHub 上以 PR 方式持续更新,免费公开。那份矩阵由各厂商自行提交维护,覆盖面是本表做不到的,本表不重复造它。
| 观测点 | 指标 | 值 | 时点 |
|---|---|---|---|
| Cloudflare | 人类流量中已用后量子密钥协商的比例 | >65% | 2026-07 |
| Cloudflare | 同上 | 过半(>50%) | 2026-04-07 |
| Cloudflare | 同上 | 约 2% | 2024 年初 |
| 浏览器 | Chrome / Edge / Firefox 默认启用 TLS 混合 PQC | 已默认 | 2026 |
| 握手套件 | 公网事实标准 | X25519MLKEM768 | 2026 |
两年从 2% 到 65%,是整个 PQC 迁移里唯一已经基本完成的一段。它完成得快,是因为 TLS 握手可以单边升级:不改证书、不改 CA、不改审计流程。
证书体系(ML-DSA 签名链、CA 根信任、HSM、代码签名)才是难的那一半,它要求 CA、浏览器根计划、HSM 厂商、审计四方同时动,公网占比目前仍极低。看到「互联网已 65% 抗量子」就以为自己的系统安全了,是这条赛道上最常见的误读。
https://qbitbrief.com/pqc/ · 转载请注明出处