基于 PQC 的对称密钥协商逻辑

在向抗量子密码迁移的过程中，保障通信数据的机密性是首要任务。

基于 TLS 1.3 协议，云平台正普遍采用 **混合密钥交换 (Hybrid Key Exchange)**机制，将传统的椭圆曲线算法（如 X25519）与 NIST 选定的后量子密钥封装算法（如 ML-KEM/Kyber）结合，以提供兼顾当前和未来威胁的最高级别安全保障。

客户端发起握手时，核心目标是提前提供两种密钥材料，以便服务器可以直接开始计算会话密钥，实现快速握手 (1-RTT)：

**双密钥生成：**客户端的 PQC-SDK 在本地内存中生成两对临时的（Ephemeral）公私钥：一对 X25519密钥对（经典 DH），一对 **ML-KEM (Kyber)**密钥对（抗量子 KEM）。
密钥发送：客户端将这两个算法的公钥打包进 ClientHello消息的 KeyShare 扩展字段，发送给服务器。

服务器接收到客户端的两种公钥后，并行计算两个共享秘密：

**经典密钥协商 (SS1)：**服务器生成自己的临时 X25519 公私钥。服务器利用自身私钥和客户端的 X25519 公钥，计算出 经典共享密钥 (Shared Secret 1)。
**PQC 密钥封装 (SS2)：**服务器调用 **ML-KEM Encapsulate（封装）**函数。服务器将客户端的 ML-KEM 公钥作为输入，该函数会生成一个 **PQC 共享密钥 (Shared Secret 2)**和对应的 封装密文 (Ciphertext)。
**响应发送：**服务器将自己的 X25519 公钥和 ML-KEM 密文打包进 ServerHello消息，发送给客户端。

客户端收到 ServerHello后，通过其本地保存的私钥，对密钥进行还原：

**经典密钥还原：**客户端利用本地 X25519 私钥和服务器的 X25519 公钥，计算出 Shared Secret 1。
**PQC 密钥还原：**客户端调用 **ML-KEM Decapsulate（解封装）**函数，使用本地的 ML-KEM 私钥对收到的密文进行解密，恢复出 Shared Secret 2。

● 双方在本地将 Shared Secret 1和 Shared Secret 2进行拼接，并将其输入 **HKDF (HMAC-based Key Derivation Function)**算法。

● HKDF 算法负责将这两个密钥安全地混合并提纯，派生出最终的会话主密钥 (Master Secret)。由于 HKDF 的设计特性，只要 $SS1$ 和 $SS2$ 中有一个是安全的，最终的 Master Secret 就是安全的。

● 密钥派生完成后，会话数据即被加密。客户端和服务端继续在加密信道中进行传统的 RSA/ECC 证书链验证。

● 一旦证书和签名验证通过，客户端就确认了服务器的身份，并开始使用基于 PQC 强化的会话主密钥，展开抗量子加密通信。

为什么先协商密钥再验证证书？

在 TLS 1.2的某些模式（如 RSA Key Exchange）中，确实是先验证证书，再用证书里的公钥加密对称密钥发给服务端

但在 **TLS 1.3 (以及 PQC-TLS)**中，顺序完全反过来了：先协商密钥，再验证身份

**隐私 (Privacy):**如果先发证书，证书是明文传输的，黑客可以看到你访问了哪个网站（证书里有域名），TLS 1.3 希望把证书也加密起来传输。
**速度 (1-RTT):**也就是“一价全包”。客户端在发 ClientHello的时候，先假设服务端会支持 X25519 或 Kyber，所以直接把公钥带过去。服务端回消息的时候，密钥就已经协商好了

基于 PQC 的对称密钥协商逻辑#