3. 后量子密码算法族概览
后量子密码（PQC）并不是某一种单一算法，而是围绕五类主要数学困难问题形成的算法族。理解这些算法族的差异，是后续做混合部署选型的基础。NIST 在 2022—2024 年的标准化进程中，最终入选的算法几乎全部来自格、哈希和无编码（编码类）三大方向，而多变量和同源方案虽未进入通用加密标准，却在特定场景中仍有价值。本节按“困难问题—代表算法—密钥/密文特征—适用场景”四条线索逐一梳理。
一、基于格的方案（Lattice-based）
格是 n 维欧氏空间中的离散点集，其核心困难问题包括 SVP（最短向量问题）、CVP（最近向量问题）以及带误差学习 LWE / 环上带误差学习 RLWE。格方案的优势是同时支持加密、密钥封装（KEM）和数字签名，且运算以多项式乘法和模约减为主，硬件实现友好。
代表算法：ML-KEM（原 CRYSTALS-Kyber，FIPS 203）用于密钥封装，安全等级分为 ML-KEM-512/768/1024；ML-DSA（原 CRYSTALS-Dilithium，FIPS 204）用于数字签名；FN-DSA（原 FALCON，FIPS 206 草案）基于 NTRU 格，签名更短但实现更复杂；SLH-DSA虽属哈希族，但其底层也常借助格结构优化。Kyber 的公钥约 800–1568 字节，密文约 768–1568 字节，签名约 2.4–4.6 KB，是当前通用场景的首选。
二、基于编码的方案（Code-based）
编码类方案依赖纠错码的译码困难性，最经典的是 McEliece 体制和 Niederreiter 体制，其安全性基于“一般线性码译码问题”的 NP 困难性。优点是历史长、抗量子分析充分；缺点是公钥体积巨大。
代表算法：Classic McEliece，公钥可达 1 MB 以上，密文仅约 128–256 字节。NIST 将其选为第四轮候选，主要用于对公钥存储不敏感、但对密文长度敏感的场景，如某些嵌入式密钥分发。另一个代表是 BIKE 和 HQC，基于准循环码，公钥缩小到几 KB，但安全性分析仍在推进中。
三、基于多变量的方案（Multivariate）
多变量密码基于有限域上多变量二次方程组求解的困难性（MQ 问题）。签名验证只需代入求值，速度极快；但公钥和签名尺寸较大，且历史上多次被攻破（如 Rainbow 在 2022 年被彻底破解）。
代表算法：Rainbow（已淘汰）、GeMSS、LUOV。目前 NIST 未将多变量方案纳入标准，但在资源极度受限、只需签名验证的场合仍有研究价值。其公钥通常几十 KB 到几百 KB，签名几十到几百字节。
四、基于哈希的方案（Hash-based）
哈希签名（如 Merkle 树签名、XMSS、LMS）的安全性仅依赖哈希函数的抗碰撞性，是最保守、最易被信任的一类。缺点是签名尺寸大、有状态管理要求（一次性签名不能重复使用）。
代表算法：SLH-DSA（原 SPHINCS+，FIPS 205），无状态、签名约 7–30 KB，公钥仅 32–64 字节，适合固件签名、代码签名等低频签名场景。LMS/XMSS 已被 RFC 8391 标准化，适合有状态管理的物联网设备。
五、基于同源的方案（Isogeny-based）
同源密码基于椭圆曲线之间同源映射的计算困难性，最大特点是密钥和密文极短，但运算速度慢、参数选择敏感。SIKE 曾在 NIST 第三轮入选，但 2022 年被 Castryck-Decru 攻击彻底破解，目前同源方向仍在寻找更安全的构造。
代表算法：SIKE（已破解）、CSIDH。CSIDH 公钥仅 64 字节，但计算一次密钥交换需数百毫秒，适合对带宽极度敏感、对延迟不敏感的场景。
六、选型对比与混合部署建议
把五类方案放在一起看，可以得出几条清晰的选型原则。第一，通用场景优先选格：ML-KEM 用于密钥封装，ML-DSA 用于签名，二者在 TLS 1.3、SSH、IPsec 中已有成熟实现，且 NIST 已发布正式标准。第二，对公钥体积不敏感、对密文长度敏感时选编码类，如 Classic McEliece 适合长期归档加密。第三，签名验证资源极度受限时考虑多变量，但必须接受其安全性尚未被充分验证的风险。第四，需要最保守信任模型时选哈希签名，SLH-DSA 适合固件签名，但签名体积大、不适合高频交互。第五，同源方案目前不建议生产部署，SIKE 被破解的教训说明其安全性分析仍需时间。
在混合部署中，常见的做法是“经典算法 + PQC 算法”双栈并行。例如 TLS 1.3 中同时协商 X25519 和 ML-KEM-768，两者密钥封装结果通过 KDF 合并，即使其中一方被攻破，另一方仍能提供保护。签名侧则可采用“ECDSA + ML-DSA”双证书链，逐步过渡。需要特别注意的是，PQC 算法的密钥和签名尺寸远大于经典算法，部署前必须评估 TLS 记录分片、证书链长度、MTU 分片等工程约束，避免因尺寸膨胀导致握手失败或性能骤降。