3.3 混合密码系统
3.3 混合密码系统
本节摘要：SOURCE 2.6：混合 KEM 同时运行 ECDH 与 Kyber，共享密钥由双方输出组合导出。IETF 正在标准化 TLS 1.3 hybrid key exchange。本节对比纯 PQC 与混合的安全/兼容权衡。
读前必看
- 描述 TLS 1.3 混合握手步骤
- 解释「攻破任一即破会话」的安全论证
- 说明与纯 Kyber 部署的对比
一、混合 KEM 流程（SOURCE 2.6）
- 客户端发起：支持
X25519Kyber768Draft00等组合 - 经典 ECDH 与 Kyber Encaps 并行
shared_secret = KDF(ecdh_ss || kyber_ss)- 后续记录层仍用 AES-GCM
混合 vs 纯 PQC
二、对比表
| 模式 | 优点 | 缺点 |
|---|---|---|
| 纯 ECDH | 成熟、小 | 不抗 Shor |
| 纯 Kyber | 抗量子 | 实现/new code point 风险 |
| 混合 | 双假设安全 | 握手略大、略慢 |
⚠️ 常见坑：混合只加 Kyber 却用 AES-128——Grover 下应 AES-256。
💡 关键直觉：2020s 主流是混合；纯 PQC 是终局方向。
核心回顾
- 混合 = 经典 + PQC 并行 KEM
- IETF 草案定义 code point 与组合
- 会话安全需两种假设同时破
- 对称层配合 AES-256
深入讨论：混合密码系统的安全论证与兼容性边界
混合密码系统最有价值的设计点，是它的安全性不依赖对 PQC 的过度信任。会话密钥由经典份额与 PQC 份额拼接导出，即使未来 Kyber 被攻破，攻击者仍需要破解 ECDH；反过来如果 ECDH 的某个实现出现漏洞，Kyber 份额仍能兜底。也就是说，混合方案把安全建立在「两者至少有一个是安全的」之上，这种论证方式让负责合规与审计的人可以在过渡期内安心采用尚未被时间充分检验的新算法。
工程上最棘手的部分是兼容性。混合套件的握手消息比纯 ECDH 大了约 2.5 KB，某些老客户端、中间盒或防火墙对 ClientHello 扩展有长度限制，可能出现连接失败。因此业界普遍采用「协商式启用」：服务器与客户端都支持混合码点时走混合，任一方不支持时回退到纯 ECDH 或经典套件。回退本身会引入降级风险，所以混合部署必须配合版本清单与降级告警，而不能静默处理。
# 混合部署检查清单 1. 确认浏览器 / 客户端版本支持混合码点（如 X25519MLKEM768） 2. 核对 CDN 与负载均衡器是否透传超大 ClientHello 3. 记录回退路径：不支持混合时明确回退到哪个经典套件 4. 用 AES-256-GCM 作为记录层对称算法，避免 Grover 弱点 5. 上线前在测试环境测量握手 RTT 增量并设定告警阈值 6. 保留经典签名证书链，与 PQC 证书并行验证期 7. 制定降级告警：混合连接占比异常下降时及时排查
这些步骤表面上是配置问题，实质上是把「双假设安全」落实成可运营的系统能力。混合不是终点，它只是从经典到纯 PQC 之间的一个过渡形态；但正是这个过渡形态，给了企业在不中断业务的前提下，把量子威胁从「远期风险」变成「已处理的近期风险」的时间窗口。
工程实践扩展：混合套件的灰度发布与观测
混合套件上生产，最怕的不是算法本身，而是「静默回退」。当客户端不支持混合码点时，连接会回退到经典套件，如果监控只统计握手成功数而不看算法分布，团队会误以为全部流量都已抗量子，实际却可能只剩部分流量走了混合路径。因此灰度发布的第一个监控项就是「混合连接占比」，并设置异常下降告警。
灰度策略建议按流量特征分步推进：先放行内部测试域名，验证功能与性能；再开放到外网边缘节点，观察跨区域延迟与连接失败率；最后全量启用前，做一次老客户端抽样，确认回退路径真实可用。每一步都以监控数据为准，而不是以「配置已下发」为准。同时要保留一键回退的能力，回退脚本与配置快照应随灰度一起准备好，而不是等到出问题再临时编写。
# 混合套件灰度监控指标体系 指标 阈值建议 告警级别 混合连接占比 > 95% 90% 以下告警 握手延迟增量 < 15 ms 超 30 ms 告警 连接失败率 < 0.05% 超 0.1% 告警 证书链校验失败率 < 0.01% 持续上升即告警 回退到经典套件占比 < 5% 超过 10% 排查 TLS 版本分布 1.3 占比保持 突降排查中间盒
灰度期的每一条告警，本质上都是对部署假设的一次验证。混合占比异常通常意味着客户端版本碎片化或中间盒限制；延迟突增可能指向 CDN 边缘未完成算法加速。把这些指标沉淀成一套可复用的观测模板，后续「纯 PQC 切换」时可以直接沿用，而不必重新摸索。