1.3 与传统密码关系

1.3 与传统密码关系

本节摘要：SOURCE 1.3 与 2.6：PQC 不会在一天内替换 RSA/ECC，混合密码系统（经典 + PQC）是过渡主流；对称 AES-GCM、哈希 SHA-3 仍为核心，但密钥长度需上调。

你能学到什么

1. 描述混合 KEM 握手流程
2. 说明密码敏捷性 Crypto-Agility 含义
3. 对比「替换」与「并存」迁移策略

一、共存而非一夜替换

SOURCE 2.6 混合系统：会话密钥由经典 KEM 与 PQC KEM 共同导出，攻破任一即可，需同时攻破两者才安全。

# 概念：混合共享秘密
# shared = KDF(ecdh_shared + kyber_shared)
​

二、密码敏捷性

• 算法标识符可配置（TLS code point）
• 支持快速切换算法套件
• 为未知 cryptanalysis 留回退

⚠️ 常见坑：只换证书不换 KEM——TLS 1.3 握手仍暴露 ECDH。

💡 关键直觉：混合期是「双保险」，不是「双倍浪费」。

核心回顾

• 混合 KEM 是近期 TLS 主流方案
• 对称算法保留、加长密钥
• 密码敏捷支持算法轮换
• 迁移是分阶段非大爆炸

深入讨论：混合密码系统在 TLS 中的具体形态

TLS 1.3 的混合密钥交换不是简单地「多加一组密钥」，而是要解决三个工程问题：组合分组在协议里如何标识、两个 KEM 的共享秘密如何拼接、以及如何在两种假设都被攻破的前提下保证语义安全。IETF 的做法是定义一组新的 TLS 密码套件码点，比如 X25519MLKEM768，客户端在 ClientHello 里同时携带经典密钥份额与 PQC 密钥份额，服务器各自独立完成计算后，将两条共享秘密输入 HKDF 拼接导出会话密钥。这样做的好处是攻击者必须同时破解 ECDH 与 Kyber 才能恢复会话，单点失败不影响整体安全。

从运营角度，「密码敏捷性」比算法本身更难落地。现实中的证书链可能横跨多年签发的中间 CA，浏览器与客户端内核的算法列表更新周期各不相同，CDN 边缘节点的配置由多家供应商管理。要让系统在「Kyber 被攻破」或「某组合码点被禁用」时快速切换，就必须把算法选择从二进制里抽离出来，变成可配置的列表，并配套证书签发、性能基线与回退演练。

# 概念：混合共享秘密的拼接方式（伪代码示意）
# ecdh_ss  = X25519(priv_a, pub_b)
# kyber_ss = Kyber768.Decaps(ciphertext, kyber_sk)
# hybrid   = HKDF-Expand(
#     ikm = ecdh_ss + kyber_ss,      # 两条共享秘密顺序拼接
#     info = b"hybrid-tls13-v1"
# )
# session_key = AES-256-GCM key from hybrid
​

对大多数企业而言，推荐的落地顺序是先在内网域名启用混合套件并测量握手延迟，再把 CDN 与对外门户切换到同一配置，最后才处理旧客户端兼容。要注意的是，混合只解决密钥交换，证书链的签名算法仍需要单独安排 Dilithium 替换，否则攻击面依然存在。本章第 3 节正是把这两件事的边界讲清楚：密钥交换交给混合 KEM，身份与签名交给 PQC 签名，两条线并行推进而不是互相替代。

工程实践扩展：共存期的证书与密钥生命周期管理

共存期最容易被忽视的工作是证书生命周期管理。经典证书链与 PQC 证书链并行存在时，证书签发、续期、吊销与信任锚校验都变成双份，CA 端需要同时维护两种签名算法，客户端需要同时验证两条链。若管理不当，会出现「证书到期只续了一条链」「吊销列表只更新了一边」的错位，比纯经典时代更容易出错。

另一个实际问题是对称密钥的轮换节奏。AES-256 的密钥轮换周期通常按业务风险设定，混合迁移本身不改变轮换逻辑，但要确保记录层算法升级（比如从 AES-128-GCM 换到 AES-256-GCM）与 KEM 升级在同一发布窗口内完成，避免出现「密钥交换已抗量子、会话加密却仍是 AES-128」这种割裂状态。

# 共存期双链管理的日常核对项
1. 每张证书同时记录经典签名与 PQC 签名的到期日
2. 续期脚本必须生成双签名证书并验证两条链均有效
3. CRL / OCSP 响应同时覆盖两种算法标识
4. 客户端支持矩阵标注混合套件的最小版本要求
5. 密钥轮换事件与 KEM 升级绑定在同一个发布窗口
6. 会话加密统一为 AES-256-GCM，禁止新旧混用
7. 每季度抽测一条典型链路的双链完整验证
​

把这些核对项固化到发布流程后，共存期就不再是「两套系统各跑各的」，而是同一套生命周期被两种算法同时覆盖。等到纯 PQC 时机成熟，只需把经典侧从配置里摘除，剩下的是已经被验证过的流程骨架，切换成本会显著低于「从零开始」。这正是「共存而非替换」策略在运营层面的回报。