4. PQC算法家族与选型
在把后量子密码（PQC）落到 mTLS 身份认证之前，必须先回答一个工程问题：面对 NIST 已经标准化的算法家族，我该选哪一个，用在链路的哪一段？ 选型不是“挑一个最安全的”，而是在安全级别、密钥/签名尺寸、CPU 开销、握手往返、协议兼容性之间做权衡。本节先梳理 NIST 标准化进程与算法分类，再给出可操作的选型判断。
一、NIST PQC 标准化进程：从征集到落地
NIST 于 2016 年启动后量子密码标准化征集，2017 年收到 69 份完整提交，经过多轮筛选与第三轮评估，最终在 2022 年 7 月公布了首批入选算法，并于 2024 年 8 月正式发布三项标准：
- FIPS 203（ML-KEM）：基于模格上带错误学习问题（MLWE）的密钥封装机制，源自 CRYSTALS-Kyber，用于密钥建立。
- FIPS 204（ML-DSA）：基于模格上短整数解与自同构问题（MLWE + SIS）的数字签名，源自 CRYSTALS-Dilithium，用于身份认证与签名。
- FIPS 205（SLH-DSA）：基于哈希的无状态签名，源自 SPHINCS+，作为不依赖格假设的备份签名方案。
此外，NIST 在 2022 年第四轮中选出 Falcon（基于 NTRU 格的签名，草案方向为 FN-DSA）与 HQC（基于纠错码的 KEM）作为后续补充，形成“格为主、哈希与码为辅”的算法格局。理解这条时间线很重要：它决定了当前工程实践中可依赖的标准接口是 ML-KEM、ML-DSA、SLH-DSA，而 Falcon/HQC 更多处于“可评估、待标准定稿”的阶段。
二、KEM 与签名：两类算法解决两类问题
PQC 算法按功能分为两大族，这与 TLS/mTLS 的握手结构直接对应：
- KEM（密钥封装机制）：解决“双方如何协商出共享密钥”。典型流程是接收方生成公私钥对并公开公钥，发送方用公钥封装出一个临时共享密钥并输出密文，接收方用私钥解封装得到同一密钥。ML-KEM、HQC 属于此类，替代的是 ECDHE/RSA 密钥传输。
- 数字签名：解决“如何证明身份与消息完整性”。签名方用私钥签名，验证方用公钥验证。ML-DSA、SLH-DSA、Falcon 属于此类，替代的是 ECDSA/RSA 签名，正是 mTLS 中客户端/服务器证书链与 CertificateVerify 的核心。
关键区别在于：KEM 不提供身份认证，签名不提供密钥协商。mTLS 双向认证需要两者配合——用 KEM 建立会话密钥，用签名验证对端证书与握手消息。因此选型必须分别对 KEM 和签名做决策，不能混为一谈。
三、安全级别：NIST 五档与参数集对应
NIST 用五个安全级别描述算法强度，级别越高，经典与量子攻击下的难度越大。ML-KEM 与 ML-DSA 各提供三档参数集，SLH-DSA 提供更细的“快速/小签名”变体：
| 算法 | 参数集 | NIST 安全级别 | 公钥/密文或签名尺寸（约） | 典型用途 |
|---|---|---|---|---|
| ML-KEM | ML-KEM-512 | 1（≈AES-128） | 公钥 800 B / 密文 768 B | 轻量客户端、带宽敏感 |
| ML-KEM | ML-KEM-768 | 3（≈AES-192） | 公钥 1184 B / 密文 1088 B | 通用推荐，TLS 默认 |
| ML-KEM | ML-KEM-1024 | 5（≈AES-256） | 公钥 1568 B / 密文 1568 B | 高保障场景 |
| ML-DSA | ML-DSA-44 | 2 | 签名 2420 B | 证书链、一般认证 |
| ML-DSA | ML-DSA-65 | 3 | 签名 3309 B | mTLS 推荐 |
| ML-DSA | ML-DSA-87 | 5 | 签名 4627 B | 高保障、长周期 |
| SLH-DSA | SLH-DSA-128s / 128f | 1 | 签名 7856 B / 17088 B | 备份签名、固件签名 |
注意：安全级别不是“越高越好”。ML-KEM-1024 与 ML-DSA-87 会显著增大握手字节数，在受限网络或高并发下可能成为瓶颈。工程上通常选择 ML-KEM-768 + ML-DSA-65 作为默认组合，与 AES-192/256 的对称强度匹配。
四、性能特征：尺寸、CPU 与握手开销
PQC 与经典算法最大的差异在“尺寸”而非“速度”。以 ML-KEM-768 为例，公钥约 1.2 KB、密文约 1.1 KB，而 X25519 公钥仅 32 B；ML-DSA-65 签名约 3.3 KB，ECDSA P-256 签名仅 64 B。这意味着：
- 握手字节数上升：证书链中每个签名从几十字节变为数千字节，多级链可能增加数 KB 到数十 KB，需关注 TCP 初始拥塞窗口与分片。
- CPU 开销可控：ML-KEM 封装/解封装在毫秒级以下，ML-DSA 签名/验签也在毫秒级，通常不是瓶颈；SLH-DSA 签名较慢，验签相对快，适合低频签名场景。
- 密钥生成与存储：PQC 私钥尺寸也增大，HSM/密钥库需确认支持 ML-KEM/ML-DSA 的密钥类型与导入格式。
五、选型决策：按场景匹配算法
把上述维度落到 mTLS 工程，可按以下判断路径选型：
- 密钥交换：默认 ML-KEM-768；若对端仅支持经典算法，启用 X25519MLKEM768 混合；带宽极敏感且安全要求可接受时考虑 ML-KEM-512。
- 证书与身份签名：默认 ML-DSA-65；若组织要求不依赖格假设，采用 SLH-DSA 作为根 CA 或备份签名；高保障场景用 ML-DSA-87。
- 兼容性：检查 TLS 库（OpenSSL 3.5+、BoringSSL、Go 1.24+ 等）是否已支持对应算法与混合组；确认证书链长度与 OCSP/CRL 的尺寸影响。
- 性能验证：在目标硬件上实测握手时延、吞吐与内存占用，重点观察大证书链下的 TLS 记录分片与重传。