2. 后量子密码算法族与协议适配基础
后量子密码（PQC）并不是某一种算法的名字，而是若干条数学路线并行发展的算法族。要把它们集成进 TLS、SSH、IPsec、S/MIME 或自研协议，第一步不是写代码，而是先看清每个算法族的“物理尺寸”和“运算性格”——密钥多大、签名多长、公钥运算贵不贵、能不能一次算完。这些参数直接决定协议字段是否放得下、握手要不要多跑一轮、报文会不会被分片。本节围绕格基、编码、多变量、哈希签名四条主线，梳理它们对协议字段与交互轮次的实际影响。
四条算法族路线的特性差异
格基（Lattice-based）是当前标准化程度最高的一族，ML-KEM（FIPS 203，源自 Kyber）和 ML-DSA（FIPS 204，源自 Dilithium）都属于它。格基方案基于 LWE/SIS 问题的困难性，密钥和签名尺寸中等：ML-KEM-768 公钥约 1184 字节、密文约 1088 字节；ML-DSA-65 公钥约 1952 字节、签名约 3309 字节。它的优势是运算快、可做 KEM 也可做签名，缺点是公钥和签名都比传统 ECC 大一到两个数量级。
编码（Code-based）以 Classic McEliece 为代表，安全性基于纠错码译码难题，历史最久、参数最保守。它的公钥极大（m=12 时约 261 KB），但密文很小（约 128 字节），且加密/解密运算量低。这种“公钥巨大、密文极小”的极端不对称，使它几乎只适合做 KEM，且对协议的公钥分发通道提出很高要求。
多变量（Multivariate）如 Rainbow 已被攻破，目前主流是 UOV、MAYO 等。它基于多变量二次方程组求解困难性，签名短（MAYO 约 321 字节）、验签快，但公钥较大（MAYO-1 约 1168 字节），且历史上多次出现参数被攻破的案例，选型时需格外关注最新密码分析进展。
哈希签名（Hash-based）以 SLH-DSA（FIPS 205，源自 SPHINCS+）为代表，安全性只依赖哈希函数，被认为最保守。代价是签名极大（约 7856 至 49856 字节）且签名运算慢，但验签相对快、公钥很小（32 或 64 字节）。它适合做固件签名、根证书等低频、高安全场景，不适合高频握手。
尺寸与开销如何映射到协议字段
协议适配的核心矛盾是：PQC 把密钥和签名“撑大”了，而协议报文格式、MTU、缓存、状态机都是按 ECC 尺寸设计的。以 TLS 1.3 握手为例，ClientHello 的 key_share 扩展要携带 KEM 公钥，ServerHello 要回传密文，Certificate 消息要装下签名公钥和证书链签名。若把 X25519 换成 ML-KEM-768，单个 key_share 从 32 字节涨到约 1184 字节；若证书链用 ML-DSA-65，一条证书的签名就从约 64 字节涨到约 3309 字节。
这会触发三个连锁问题。第一是分片：TLS 记录层最大明文 16 KB，一条含多级证书链的 Certificate 消息很容易超过，导致 TCP 分片或需要协议层分片重组。第二是放大：ClientHello 变大后，若服务端不回 HelloRetryRequest，攻击者可用小请求撬动大响应，需要重新评估抗放大阈值。第三是缓存与状态：服务端为每个连接保存的握手状态、会话票据、密钥材料都变大，高并发场景下内存压力显著上升。
示例估算（假设值，用于说明方法）：某 TLS 1.3 服务端证书链为“叶证书 + 中间证书”，均使用 ML-DSA-65。单条签名约 3309 字节，两条约 6618 字节；两条公钥约 1952×2=3904 字节；加上证书元数据，Certificate 消息约 10.5 KB。若客户端 key_share 用 ML-KEM-768（约 1184 字节），ServerHello 密文约 1088 字节，则单次完整握手在证书阶段就可能触及 16 KB 记录上限，需要评估是否启用证书压缩或改用混合模式。
交互轮次：哪些算法会改变握手节奏
并非所有 PQC 都会增加轮次。KEM 类算法（ML-KEM、McEliece）本身是“一次封装、一次解封装”，可以嵌入现有的一次往返密钥交换，不增加轮次。真正可能改变节奏的是两类情况：一是签名验证失败后的重试，例如客户端不支持服务端首选算法时触发 HelloRetryRequest，多一个往返；二是大消息触发的分片重组，虽然逻辑上仍是一轮，但实际传输被拆成多个 TCP 段，时延和丢包重传概率上升。
哈希签名由于签名极大，若用于在线握手，单条 CertificateVerify 就可能超过 MTU，导致多次分片；因此工程上通常把它放在离线根证书或固件签名环节，在线握手改用格基或混合签名。多变量签名短、验签快，适合对带宽敏感的在线场景，但必须确认所选参数未被最新攻击削弱。
适配时的关键判断与操作
实际集成时，建议按以下顺序做判断，而不是一上来就改代码。第一步，量尺寸：把候选算法的公钥、密文、签名、私钥尺寸列成表，对照协议每个字段的最大长度限制，标出哪些字段会溢出。第二步，算轮次：确认所选 KEM 是否可嵌入现有一次往返，签名是否只在证书链出现；若签名用于在线 CertificateVerify，评估是否超过 MTU。第三步，定策略：在线握手优先格基或“ECC + PQC”混合模式，根证书和固件签名用哈希签名，KEM 若追求最小密文可考虑 McEliece 但需接受巨大公钥。第四步，验分片：用真实证书链构造握手报文，观察是否触发 TCP 分片、是否出现 HelloRetryRequest，记录握手时延和内存占用变化。
混合模式的价值：把 X25519 与 ML-KEM-768 组合，即使 PQC 算法未来被攻破，传统 ECC 仍提供保护；同时混合后的 key_share 约 1216 字节，仍在多数协议可接受范围内。这是当前过渡期最稳妥的工程选择。
不要忽略私钥与状态尺寸：ML-DSA 私钥约 4032 字节，SLH-DSA 私钥虽小但签名状态需谨慎管理。服务端若为每个连接缓存密钥材料，内存占用会随并发数线性放大，容量规划必须把 PQC 尺寸纳入。
总结来看，四条算法族没有绝对优劣，只有与协议场景的匹配度。格基适合在线握手，编码适合极小密文 KEM，多变量适合短签名在线验签，哈希签名适合离线高安全场景。协议适配的本质，是把算法参数翻译成字段长度、分片行为、轮次变化和内存开销，再据此决定混合策略与部署位置。