2. 后量子密码算法基础与TLS集成点

要在实验环境里把后量子算法真正跑进TLS 1.3，第一步不是改代码，而是弄清楚“哪些算法、各自解决什么问题、在握手流程的哪个位置被调用”。TLS 1.3的握手可以粗略拆成两条密码学主线：一条是密钥交换，双方协商出共享密钥；另一条是身份认证，用证书和签名证明“对端是谁”。后量子算法正是分别替换这两条主线上的传统原语——格基KEM替换ECDHE，哈希签名替换ECDSA/RSA签名。理解这个对应关系，后续的OpenSSL/OQS实验才不会变成盲目试错。

一、三类算法的定位与特性

格基KEM（Kyber / ML-KEM）。Kyber基于模格上的LWE（Learning With Errors）问题，其安全性依赖于“带噪声的线性方程组难以求解”这一困难性。NIST在2024年将其标准化为ML-KEM（FIPS 203），提供ML-KEM-512/768/1024三档参数，对应NIST安全等级1/3/5。它的工程特性非常突出：公钥约800～1568字节、密文约768～1568字节，封装/解封装耗时在微秒到数十微秒量级，是目前综合性能最好的KEM。代价是公钥和密文体积远大于X25519的32字节，这会直接推高ClientHello与ServerHello的尺寸，是实验中必须观察的第一个现象。

哈希签名（SPHINCS+）。SPHINCS+属于无状态哈希签名，安全性只依赖哈希函数的抗碰撞性，不依赖格、编码等代数结构，因此被视为“保守派”选择，NIST标准化为SLH-DSA（FIPS 205）。它的特点是签名极大（约7.8KB～49.8KB）、签名速度慢（毫秒级），但验证相对快，且没有密钥状态管理问题。在TLS中它适合放在证书签名链上，而不适合高频握手场景。

NTRU。NTRU是基于多项式环上格问题的早期KEM方案，历史比Kyber更久，已有NTRU-HPS、NTRU-HRSS等参数集，并进入部分标准化轨道。它与Kyber同属格基家族但结构不同（NTRU格 vs 模格LWE），在实验中常作为Kyber的对照实现，用于比较密钥尺寸、握手时延和互操作性。

二、算法与TLS 1.3集成点的对应关系

TLS 1.3的密钥交换通过key_share扩展携带临时公钥，通过supported_groups声明支持的群。后量子KEM的集成方式有两种主流路径：其一是纯PQ，即把ML-KEM作为一个新的“群”直接放进key_share；其二是混合模式，即把X25519与ML-KEM的公钥拼接，共享密钥也拼接后送入HKDF，这样即使某一方被攻破仍保有安全性。混合模式是当前工程实践的主流，也是实验中最值得对比的配置。

身份认证侧，后量子签名进入的是CertificateVerify消息和证书链的签名算法字段。服务器用SLH-DSA或ML-DSA私钥对握手 transcript 签名，客户端用证书中的公钥验证。这里的关键约束是：证书的签名算法OID、CA链、以及客户端signature_algorithms扩展必须同时支持该算法，否则握手会在证书验证阶段失败。

三、实验中的关键观察点与判断依据

在OQS-OpenSSL或BoringSSL的实验分支上，最直接的验证方式是抓取握手报文并检查扩展字段。例如用openssl s_client -groups x25519_mlkem768 -connect 127.0.0.1:4433发起连接，若服务端支持混合群，ClientHello的supported_groups中会出现对应ID，ServerHello的key_share长度会明显大于纯X25519（约1.2KB以上）。如果握手在CertificateVerify阶段失败，通常不是KEM的问题，而是证书签名算法不被signature_algorithms接受，此时应检查证书的OID与客户端声明列表是否交集为空。

另一个值得量化的观察点是握手字节数与RTT。以ML-KEM-768混合X25519为例，ClientHello因携带KEM公钥会增大约1.1KB，若超过单个TCP段或路径MTU，可能触发分片，在弱网环境下表现为额外RTT。实验时可对比纯X25519、X25519+ML-KEM、纯ML-KEM三组配置的握手总字节与完成时间，形成一张对照记录，这比单纯“能连上”更能说明集成质量。