1. 过渡工程全景

混合密码体系过渡，指的是在既有密码基础设施仍在承载业务的前提下，将系统从一种密码算法、协议版本或信任模型，逐步迁移到另一种（通常是抗量子或更高强度）体系的全过程。它不同于“停机替换”：过渡期间，新旧两套密码能力必须同时存在、可互操作、可回退，并且每一次密钥、证书、协议协商的变化都要可审计。理解这一点，是后续所有工程决策的起点。

为什么不能一次性切换？因为密码能力嵌入在证书链、TLS握手、代码签名、密钥管理系统（KMS）、硬件安全模块（HSM）和各类终端固件中，任何一处不兼容都会导致业务中断。因此过渡工程的核心矛盾是：安全目标要求尽快淘汰弱算法，而可用性目标要求旧系统继续工作。混合密码体系正是为化解这一矛盾而设计的中间形态——在同一协议或同一证书中同时携带经典算法与新型算法，由双方协商决定实际使用哪一套。

驱动因素：不是单一威胁，而是多重压力叠加

推动过渡的驱动因素通常有四类。第一类是算法生命周期压力：SHA-1已被主流浏览器拒绝，RSA-1024早已不推荐，RSA-2048和ECC P-256也被认为在量子计算成熟后不再安全。第二类是合规与标准要求：NIST在2024年正式发布ML-KEM（FIPS 203）、ML-DSA（FIPS 204）和SLH-DSA（FIPS 205），金融、政务、能源等行业开始将抗量子算法纳入采购与测评要求。第三类是“先收集、后解密”威胁：攻击者今天截获并存储加密流量，等量子计算机可用后再解密，这意味着长期保密数据的过渡窗口比想象中更紧迫。第四类是供应链传导：上游操作系统、浏览器、云服务商一旦默认启用混合密钥交换，下游应用即使不主动改造，也会被动进入过渡状态。

典型场景：不同对象的过渡节奏差异很大

过渡工程不是一张统一时间表，而是按对象分层的。最常见的场景包括：Web/TLS服务，在TLS 1.3中启用X25519+ML-KEM-768混合密钥交换，客户端和服务端各自声明支持的组，协商失败则回退到经典组；PKI与证书体系，在证书链中同时签发经典证书和混合证书，或采用双证书策略，根CA逐步交叉签名；代码签名与固件更新，由于终端设备更新周期长，往往需要同时验证新旧两种签名；数据存储与密钥封装，对长期归档数据采用混合KEM封装数据密钥，确保即使经典算法被攻破，数据仍受新型算法保护。

这些场景的共同点是：过渡不是“替换一个算法”，而是“维护一套双轨能力”。下面这张图把过渡工程的生命周期与各阶段的关键对象、判断条件放在一起，便于建立整体视图。

工程生命周期：四个阶段与一条反馈回路

从工程视角看，过渡生命周期可以归纳为四个阶段，但它们不是严格串行的，而是允许回退和迭代。

第一阶段是资产盘点与分级。需要回答：哪些系统使用了密码？用的是什么算法、什么协议版本、什么证书链？数据需要保密多久？这一步的产出是一张过渡优先级表。例如，一个面向公众的HTTPS网关，如果仍支持TLS 1.2且使用RSA密钥交换，应排在优先级前列；而一个内网、数据保密期只有3个月的报表系统，可以稍后处理。盘点的关键是不要只看应用层，还要看操作系统、中间件、HSM固件和终端SDK。

第二阶段是混合方案设计。核心决策包括：混合组怎么选（如X25519+ML-KEM-768）、证书是双签还是交叉签、回退阈值设多少、旧客户端占比多大时可以强制新算法。这里必须做兼容性矩阵：列出客户端类型、支持的协议版本、是否支持混合组、回退后的行为。一个常见的教学示例参数是：服务端同时启用X25519和X25519+ML-KEM-768，客户端按5%、20%、50%、100%的比例逐步放量，每次放量后观察24小时协商失败率，若失败率超过0.5%则暂停并回退到上一比例。

第三阶段是灰度部署与协商。这一阶段最值得观察的指标是协商成功率和回退原因分布。如果大量客户端回退到经典组，说明客户端侧尚未升级，需要推动终端更新或调整放量节奏。日志中应记录：客户端声明的组列表、服务端选择的组、是否发生回退、回退原因（不支持、超时、策略拒绝）。这些数据是后续收敛的依据。

第四阶段是收敛与退役。当混合组协商成功率稳定在目标值以上、旧客户端占比降到可接受范围后，逐步关闭经典算法、吊销旧证书、更新合规证据，并保留审计日志。退役不是“删掉旧代码”，而是确认旧算法不再被任何生产流量使用。

一个可执行的过渡检查表示例

下面这份检查表可直接用于单个系统的过渡启动评估，字段和判断依据均围绕密码过渡本身，不引入无关管理指标。