4. 经典密钥协商协议回顾

在进入抗量子混合密钥协商方案设计之前，必须先把经典密钥协商的“地基”看清楚。因为混合方案并不是凭空出现的，它通常是把一个经典密钥协商（如 ECDHE）与一个后量子密钥封装（如 ML-KEM）并置，再把两路共享秘密拼接后送入 KDF。若不清楚经典这一路的数学基础、临时密钥语义和前向安全性来源，就无法判断混合方案在哪些环节继承了经典安全性、哪些环节需要后量子组件补位。

一、Diffie-Hellman 的数学基础

Diffie-Hellman（DH）建立在有限循环群的离散对数问题（DLP）之上。设公开参数为大素数 p 和生成元 g，双方各自选取私钥 a、b，公开值分别为 A = g^a mod p、B = g^b mod p。交换公开值后，双方计算 K = B^a = A^b = g^(ab) mod p，得到相同的共享秘密。攻击者即使看到 g、p、A、B，若无法求解离散对数，就难以恢复 g^(ab)。这里的关键安全假设是：在所选群中 DLP 是困难的，且 g 生成的子群足够大，能抵抗 Pohlig-Hellman 等针对小子群的攻击。

工程上，DH 参数必须谨慎选择。传统 TLS 中常见的 ffdhe2048、ffdhe3072 等命名组，就是预定义的标准化有限域参数，避免服务器临时生成弱参数。若使用自定义参数，必须验证 p 为安全素数、g 位于正确子群，否则可能遭遇小子群约束攻击。这也是为什么现代协议更倾向于使用标准化命名组，而不是让实现者自由发挥。

二、ECDH：把群换成椭圆曲线

ECDH 把运算从有限域乘法群搬到椭圆曲线点群上。设曲线为 y² = x³ + ax + b (mod p)，基点 G 的阶为 n。私钥 d 是 [1, n-1] 内的整数，公钥为 Q = dG（点乘）。双方各自计算 d_A·Q_B 与 d_B·Q_A，由于点乘满足结合律，二者都等于 d_A·d_B·G，即共享的曲线点，再取其 x 坐标（或经 KDF 处理）作为共享秘密。

ECDH 的安全假设是椭圆曲线离散对数问题（ECDLP）困难。相比同安全强度的有限域 DH，ECDH 的密钥和参数短得多：约 256 位的曲线（如 P-256、X25519）可提供约 128 位经典安全强度，而有限域 DH 要达到同等强度需要 3072 位以上。这使 ECDH 在 TLS 握手、移动端和物联网场景中成为主流。需要注意的是，曲线选择同样关键：必须使用安全曲线，并做公钥合法性校验（是否在曲线上、是否为零点、是否在正确子群），否则可能遭受无效曲线攻击。

三、临时密钥交换：DHE 与 ECDHE

静态 DH/ECDH 中，私钥长期固定，一旦私钥泄露，历史会话全部可被解密。临时密钥交换（Ephemeral）改为每次握手现场生成一次性私钥：DHE 使用临时有限域参数，ECDHE 使用临时椭圆曲线密钥对。握手结束后私钥即销毁，公开值只用于当次会话。这样，即使服务器长期签名私钥日后泄露，攻击者也无法据此恢复过去会话的共享秘密——这正是前向安全性（Forward Secrecy，也称完美前向保密 PFS）的来源。

需要区分两个概念：前向安全性保护的是“会话密钥”，而不是“身份认证”。在 TLS 中，ECDHE 只负责协商共享秘密，服务器身份仍由证书和签名保证。若攻击者能实时实施中间人攻击并伪造证书，前向安全性并不能阻止当次会话被劫持。因此 ECDHE 必须与可靠的身份认证机制配合使用。

四、在 TLS 1.3 中的集成方式

TLS 1.3 对密钥协商做了大幅精简：删除了静态 RSA 密钥传输和静态 DH，密钥交换统一采用带临时密钥的 (EC)DHE，并通过 key_share 扩展在 ClientHello 中直接携带客户端临时公钥。服务器在 ServerHello 中返回自己的 key_share，双方随即用 HKDF 从共享秘密派生出握手密钥。整个握手只需一次往返即可完成密钥协商，且默认提供前向安全性。

以 X25519 为例，客户端生成临时私钥 sk_c，计算 pk_c = X25519(sk_c, 9)（9 为基点），放入 key_share；服务器返回 pk_s；双方计算 Z = X25519(sk_c, pk_s) = X25519(sk_s, pk_c)，再把 Z 作为 HKDF-Extract 的输入，结合握手 transcript 派生出 client_handshake_traffic_secret 与 server_handshake_traffic_secret。由于 transcript 被绑定进密钥派生，任何握手消息篡改都会导致密钥不一致，从而被检测到。

TLS 1.3 还支持 HelloRetryRequest：若客户端猜测的组服务器不支持，服务器可要求重试并指定组。这影响的是握手时延，不改变前向安全性语义。工程实现中应关注组配置顺序、是否启用 X25519、是否保留 P-256 兼容性，以及是否禁用弱曲线。

五、安全假设与工程要点

把上述内容归纳起来，经典密钥协商在 TLS 1.3 中的安全依赖几条假设：其一，所选群或曲线的离散对数问题在经典计算模型下困难；其二，临时私钥的随机性足够好，且生成后不被泄露或复用；其三，公钥合法性校验到位，能抵御小子群、无效曲线等攻击；其四，身份认证链路（证书、签名算法）可靠，否则前向安全性无法阻止实时中间人。此外，TLS 1.3 的 transcript 绑定和 HKDF 派生结构，使握手消息篡改可被检测，这属于协议层面的完整性保障。

从实现角度看，一个可检查的配置示例是：在服务端启用 TLS_AES_128_GCM_SHA256 与 TLS_CHACHA20_POLY1305_SHA256，密钥交换组优先 X25519，保留 secp256r1 兼容，禁用 ffdhe2048 以下的有限域组和所有非临时 RSA 密钥传输套件。验证时可用 openssl s_client -connect host:443 -groups X25519 -tls1_3 观察协商结果，确认 Server Temp Key 显示为 X25519 且会话可正常建立；再用抓包确认 ClientHello 中携带了 key_share 扩展。这些检查能帮助确认“临时密钥 + 前向安全性”确实生效，而不是仅停留在配置声明上。