3.4PQC应用场景与迁移策略

3.4 PQC 应用场景与迁移策略

PQC 能跑在普通终端上，因此它的应用场景几乎覆盖所有需要密码保护的地方。难点不在"能不能用"，而在"怎么平滑迁过去"。

应用场景

迁移策略

• 混合模式：经典算法（如 ECC/RSA）与 PQC 算法并行使用，任一被破都不致立即失守，是最稳妥的过渡姿势。
• 逐步替换：在新版本、新模块中逐步引入 PQC，分阶段淘汰纯经典实现。
• 新建系统：绿地系统直接采用 PQC，不背历史包袱。

💡 迁移要优先考虑"长保密期"数据：证书、长期密钥、归档密文应最先迁移，因为它们的暴露窗口最长。

⚠️ 混合模式虽安全，但会增大握手数据量与计算开销，在时延敏感的物联网场景要做性能预算，别盲目全量叠加。

深入讨论：混合模式的工程实现与取舍

混合模式的具体做法，是在密钥交换与签名两个层面同时运行经典与 PQC 算法。以 TLS 握手为例：客户端与服务器既执行 ECDHE 交换经典密钥份额，也执行 ML-KEM 封装出 PQC 密钥份额，两条共享秘密拼接后经 KDF 导出最终会话密钥——攻击者必须同时攻破两种算法才能恢复会话，任何单一路线失守都不影响整体。签名侧则并行使用经典证书与 PQC 证书，验证方任选其一通过即视为有效。

混合的成本是真实存在的：握手数据量增大（PQC 公钥与密文加起来比纯 ECDHE 大数倍），密钥生成与封装的 CPU 开销上升，证书链体积可能接近 MTU 上限。在物联网等时延与内存敏感的终端上，需要为「双套算法并行」做性能预算，必要时降档（如用 ML-KEM-512 配经典曲线），而不是无条件全量叠加。权衡的锚点是数据保密期：暴露窗口越长，越值得承担混合开销。

# 混合模式部署分场景建议
场景              混合组合                    权衡要点
公网 Web TLS      ECDHE + ML-KEM-768         兼容主流客户端，握手略增
VPN 网关          IKEv2 混合组               两端同步升级，带宽可控
代码签名          ECDSA + ML-DSA             双证书链，验证兼容旧工具
物联网 OTA        轻量参数（ML-KEM-512）      算力/内存受限，先跑通再增
长期归档          AES-256 + 混合 KEM 加密     保密期优先，性能次要

# 迁移节奏参考
阶段一：盘点长保密资产，选定试点域名/系统
阶段二：试点启用混合套件，测量延迟与兼容性
阶段三：CDN、CA、客户端 SDK 同步，扩大覆盖
阶段四：按覆盖度收紧纯经典通道，进入纯 PQC
​

把「混合模式」落到分场景组合与分阶段节奏，迁移就从「要不要做」变成「先做哪个、怎么验收」。这套思路与经典密码时代的 TLS 升级经验一脉相承——新能力先行试点、老通道渐进退出、以监控数据为准逐步推进，只是这次替换的对象换成了公钥数学的地基。

在组织层面，迁移成功的关键通常不是技术而是治理：需要指定「密码迁移负责人」，建立跨网络、安全、运维、合规的评审机制，把算法清单、版本与切换计划写进变更管理流程。没有治理锚点的迁移，容易在试点成功后陷入「各自为战、口径不一」的停滞——这比算法本身更值得投入规划精力。

迁移的验收指标也应在试点阶段就定义清楚：混合连接的占比、握手延迟增量、失败率、证书链校验通过率，以及回退脚本的可执行性。这些指标与经典 TLS 升级的验收体系高度一致，可以直接复用既有监控与告警框架，让 PQC 迁移成为「又一轮常规密码升级」，而不是一场特殊战役。

此外，试点范围的选择有讲究：优先选「流量真实、影响可隔离、回退无痛」的系统（如内部门户、测试环境旁的边缘节点），而不是一开始就动核心支付链路。先积累一套经过验证的切换与回退剧本，再向核心系统复制，风险与阻力都会小得多。