1. 课程导入与抗量子迁移背景

在开始设计任何一套密钥协商方案之前，我们需要先回答一个根本问题：为什么现有的密钥协商机制在未来会失效，以及我们为什么要用"混合"的方式来应对这种失效。本节将围绕量子计算对经典密钥协商的威胁、抗量子密码迁移的紧迫性、混合密钥协商的设计目标，以及整门课程的技术路线展开，为后续各章的算法细节与工程实现建立统一的认知框架。

一、经典密钥协商的信任基础正在被动摇

当前互联网中绝大多数安全会话依赖两类密钥协商机制：基于大整数分解或离散对数难题的有限域/椭圆曲线 Diffie-Hellman（如 ECDH、DH），以及基于 RSA 的密钥传输。它们的安全性建立在"计算困难性"假设之上——攻击者即使拿到公开参数，也无法在可接受时间内求解私钥。例如 NIST P-256 曲线上的 ECDH，其离散对数问题在经典计算机上需要约 2^128 次运算量级，这正是我们信任它的原因。

量子计算改变了这个前提。Shor 算法可以在多项式时间内求解大整数分解与离散对数问题，这意味着一旦出现足够规模、足够容错的量子计算机，ECDH、DH、RSA 的私钥都能被直接计算出来。更值得警惕的是"先存储、后解密"（Harvest Now, Decrypt Later）攻击：攻击者今天就可以录制加密流量，等量子计算机成熟后再解密。对于需要长期保密的数据——医疗记录、身份档案、长期合同、政务数据——这种威胁是当下就已经发生的，而不是未来才发生。

需要区分的是，Grover 算法对对称密码只带来平方级加速，AES-256 仍可保持约 128 位安全强度，因此本课程关注的重点是公钥密钥协商，而非对称加密本身。

二、抗量子迁移的紧迫性与现实约束

抗量子密码（PQC）迁移不是"等量子计算机出现再说"的事情。迁移周期长、涉及面广：从协议标准、库实现、证书体系到终端设备固件，往往需要数年时间。NIST 已于 2024 年正式发布 ML-KEM（FIPS 203，基于格）、ML-DSA（FIPS 204）与 SLH-DSA（FIPS 205）等标准，为迁移提供了可依据的规范。产业界的共识是：现在开始规划，才能在威胁真正到来前完成切换。

但直接替换并不现实。PQC 算法在密钥尺寸、密文尺寸、计算开销上与经典算法差异显著。以 ML-KEM-768 为例，其公钥约 1184 字节、密文约 1088 字节，远大于 X25519 的 32 字节公钥；而部分基于编码或哈希的候选方案签名体积更大。同时，PQC 算法相对年轻，其安全性分析历史远短于 RSA/ECC，存在被后续密码分析突破的可能。这些约束共同指向一个工程结论：不能把全部信任一次性押在新算法上。

三、混合密钥协商的设计目标

混合密钥协商（Hybrid Key Exchange）的核心思想是：在同一次握手中共用一条经典密钥协商（如 X25519）和一条抗量子密钥协商（如 ML-KEM），将两者导出的共享秘密通过 KDF 组合成最终会话密钥。其设计目标可以归纳为四点：

  • 双重保障：只要经典算法或 PQC 算法中任意一个未被攻破，会话密钥就保持安全。即使 ML-KEM 未来被密码分析削弱，X25519 仍提供兜底；反之，量子计算机攻破 X25519 时，ML-KEM 仍守住防线。
  • 向后兼容：在现有 TLS 1.3 等协议框架内以扩展方式引入，不破坏既有部署与中间设备。
  • 可验证的组合：组合过程必须使用标准化、可审计的 KDF 与标签，避免"简单拼接"带来的降级或混淆风险。
  • 可迁移：当 PQC 算法需要升级或替换时，混合框架允许平滑过渡，而不必再次重构整个握手流程。

下面的信号链图展示了混合密钥协商在一次握手中的数据流与组合关系，帮助建立整体结构认知：

混合密钥协商：双通道共享秘密的组合链 发起方 生成两路密钥对 经典通道 X25519 共享秘密 ss_ecdh（32B） 抗量子通道 ML-KEM-768 共享秘密 ss_kem（32B） KDF 组合 HKDF-Extract/Expand 会话密钥 32B 对称密钥 安全兜底逻辑 量子计算机攻破 X25519 → ML-KEM 仍保护会话 ML-KEM 未来被分析削弱 → X25519 仍保护会话 两者同时失效才会导致会话密钥泄露

四、组合过程的关键细节

混合不是把两段字节简单拼接。以 TLS 1.3 的混合密钥协商草案思路为例，组合通常采用 HKDF：先以两路共享秘密作为输入材料，配合明确的标签（如 "hybrid shared secret"）和握手上下文（ClientHello 与 ServerHello 的 transcript hash）进行 Extract，再 Expand 出握手密钥。标签与上下文的作用是防止通道混淆和降级攻击——如果攻击者试图只让一方使用单通道，transcript 不一致会导致双方导出不同密钥，握手随即失败。

一个可参考的示例参数（属于教学假设，非实测结果）：X25519 输出 32 字节共享秘密，ML-KEM-768 输出 32 字节共享秘密，HKDF-SHA256 的 Extract 输入为 ss_ecdh || ss_kem 共 64 字节，盐值取空，info 字段为 "tls13 hybrid kex"，最终 Expand 出 32 字节会话密钥。工程实现中必须保证两路秘密的拼接顺序在双方一致，且顺序本身写入规范，不能依赖实现约定。

五、课程整体路线图

本课程共 30 章，整体按"背景—原理—算法—协议—实现—验证—迁移"的脉络推进。前几章建立威胁模型与混合设计目标；随后深入 ML-KEM 的格基原理、密钥封装流程与参数选择，以及 X25519 的运算细节；中段聚焦混合组合的 KDF 设计、TLS 1.3 扩展集成、消息格式与状态机；后段进入工程实现，包括密钥尺寸对分片与 MTU 的影响、性能基准测试方法、互操作性测试与故障排查；最后讨论迁移策略、算法敏捷性与长期运维。每一章都会围绕真实对象、参数与判断依据展开，力求让读者不仅能理解"为什么"，也能落地"怎么做"。

← 上一章 📖 返回目录 下一章 →