题干与适用场景
公司有移动端、Web、设备和第三方 API 客户端，仍使用 RSA 或椭圆曲线。请设计一套迁移到后量子密码的计划，说明如何处理兼容性、性能、密钥轮换和回滚。
NIST 已发布 FIPS 203、204、205，分别规范 ML-KEM、ML-DSA 和 SLH-DSA。面试重点不是背算法名称，而是把长期机密性、客户端生命周期和运维风险转成分阶段决策。IETF 的混合 TLS 草案仍属于草案，不能当成所有网络的既定兼容承诺。
面试官考察点
面试官会看你能否盘点实际密码资产，区分密钥建立与数字签名，解释“先收集后解密”的风险，设计密码敏捷性接口，并用兼容率、失败率和性能预算控制迁移。还要说明哪些结论需要安全、合规、供应商和产品团队共同确认。
回答前需要澄清的问题
- 哪些数据需要保密十年或更久，哪些签名必须长期验证？
- 客户端版本、固件升级能力、离线周期和第三方依赖如何分布？
- 当前 RSA、ECDH、ECDSA 的调用点、证书链、HSM 和备份在哪里？
- 传输层、静态数据、代码签名和令牌签名是否共享同一密钥生命周期？
- 可接受的握手延迟、包大小、CPU、内存和失败率预算是多少？
- 能否保留旧算法一段时间，谁有权批准降级与紧急回滚？
30 秒回答框架
“我先建立密码资产清单和数据保密期限，再按暴露面、替换难度和客户端可更新性排序。将密钥建立与签名分开设计，通过版本化算法套件和能力探测支持经典、后量子或混合模式；默认拒绝静默降级。先在可控服务和新客户端灰度，记录握手成功率、响应大小、CPU、回退和密钥轮换指标。只有兼容性、性能、审计和回滚门槛都满足，才扩大范围，并保留旧密钥的验证窗口而不继续产生新的旧格式。”
分步骤深入解答
第一步：盘点算法与数据寿命
扫描 TLS、VPN、服务间 RPC、数据库加密、备份、签名、证书、固件和供应商 SDK 的调用点。给每个资产记录算法、密钥长度、用途、拥有者、轮换方式、客户端版本和数据保密期限。优先处理需要长期保密且今天已被采集的流量，再处理验证寿命长的签名。
第二步：建立风险分层与目标基线
用资产重要性、攻击可行性、迁移窗口、不可更新客户端比例和替换成本打分。基线应明确哪些新连接必须使用后量子或混合方案，哪些旧连接只能在有审批、短期限和监控的兼容窗口内继续。不要把“量子计算何时出现”当成唯一决策变量。
第三步：把密码实现变成可替换能力
通过版本化的算法套件、密钥类型和证书策略隔离业务代码与密码库。服务端接受能力声明，但不能让客户端任意选择弱算法；策略中心应能暂停某套件、切换供应商库并记录生效范围。密文和签名元数据要携带版本，避免未来无法识别历史格式。
第四步：选择密钥建立与签名路径
ML-KEM 适合密钥封装，ML-DSA 与 SLH-DSA 用于签名；它们的密钥、证书和性能特征不同。对 TLS 等协议可评估经典加密与 ML-KEM 的混合握手，但先确认目标实现、草案状态、网关和终端支持。签名迁移要单独验证证书链长度、验证成本和长期存档。
第五步：设计兼容与回滚边界
先让新客户端通过能力探测选择新套件，旧客户端进入明确的兼容池。降级必须可观测、限时、按租户或设备审批，不能因为握手失败就无限回到旧算法。回滚只撤回新流量入口，不删除仍需验证的旧公钥；每次回滚都记录原因、范围和再次启用条件。
第六步：用灰度实验验证代价
在内部服务、可更新移动端和低风险租户中测试连接成功率、握手延迟、消息大小、CPU、内存、带宽、证书缓存和 HSM 吞吐。分别压测峰值、弱网、离线恢复和多地域。把后量子开销与业务 SLO 对照，发现异常时按版本和客户端类型回退，而不是关闭所有安全策略。
第七步：同步密钥、供应商与审计
定义新旧密钥的生成、托管、轮换、吊销、备份和销毁窗口。验证 HSM、云 KMS、证书机构、代理和第三方 SDK 是否支持目标格式；将算法套件变化写入审计事件。安全团队负责策略，平台团队负责实现，法务或合规团队确认适用期限和证据留存。
第八步：设定发布门槛与长期退出
发布门槛至少包括兼容成功率、性能预算、旧算法流量占比、异常回退率、密钥轮换成功率和审计完整性。每个阶段设停止线与负责人；当旧格式流量低于阈值后，停止签发新的旧证书，再经过验证窗口才撤销接受能力。保留迁移记录，便于下一次算法替换。
设计取舍与边界
混合模式与纯后量子模式
混合模式可降低单一新算法失误的影响，但会增加握手大小、实现复杂度和协商测试量。纯后量子模式更简单地表达目标，却可能排除无法升级的客户端。选择应由兼容矩阵和风险门槛驱动，而不是由宣传口号决定。
安全强度与性能预算
更大的密钥、密文或签名会影响 MTU、握手、缓存和 HSM 吞吐。应按真实流量测量，并为移动网络、设备 CPU 和峰值并发留出余量。性能优化不能通过静默降级换取。
回滚与旧密钥保留
回滚入口与密钥销毁是两件事。旧公钥可能仍需验证历史签名，因此不能上线回滚后立即删除。可停止新签发、限制新连接、保留只读验证，并在证据足够后再销毁。
失败演练与演进计划
旧设备无法升级
建立设备版本清单，设置隔离网关和明确的到期日期。验证隔离不会把旧设备的弱算法扩散到新客户端，并向拥有者提供升级或替换路径。
握手变大导致连接失败
在真实代理、负载均衡和移动网络中测试分片、MTU、超时和重试。若新套件失败，回到已审批的兼容池并告警，不允许客户端自行尝试更多弱套件。
第三方只支持旧签名
为第三方建立版本化接口和过渡证书，限制旧签名的有效期与权限。把升级承诺写入供应商合同和验收指标，不能把不可控依赖隐藏在“后续处理”。
常见误区与追问
误区一：把算法替换当成一次配置发布
追问：你如何找到所有密码调用点、备份和离线设备？候选人应说明资产清单、依赖图和责任人。
误区二：把 FIPS 发布等同于客户端全部兼容
追问：目标库、证书机构、HSM、网关和浏览器的支持证据在哪里？候选人应区分标准完成与产品实现可用。
误区三：失败就静默回退到 RSA
追问：降级由谁批准、持续多久、如何告警和退出？候选人应给出可审计的兼容窗口。
误区四：只测平均延迟
追问：峰值并发、弱网、包大小、CPU、内存和证书缓存如何验证？候选人应描述分层压测与停止线。
延伸追问与参考答案
为什么要把密钥建立和签名分开迁移？
密钥建立保护会话机密性，签名保护身份和完整性；算法、证书链、密钥尺寸和验证寿命不同。拆开后可以按风险和客户端能力分别灰度，避免一次替换阻塞全部业务。
如何证明系统具备密码敏捷性？
展示算法套件版本化、策略切换、密钥元数据、供应商替换、兼容矩阵、审计事件和回滚演练。仅能修改一个配置文件并不足以证明业务、证书和设备链路都可替换。
什么时候可以停止接受旧算法？
当新客户端覆盖率、连接成功率、性能和审计门槛达标，旧流量已被定位且拥有者完成升级后，先停止新签发，再经过只读验证窗口，最后撤销接受能力。每一步都应有回滚条件和负责人。