2、PQC算法全景图：NIST标准化的四大金刚
好，咱们进入正题。上一章聊了为什么IoT设备必须拥抱PQC，这一章咱们把NIST已经标准化的四个算法——CRYSTALS-Kyber、CRYSTALS-Dilithium、Falcon、SPHINCS+——掰开揉碎讲清楚。
说白了，这四位就是后量子时代的「四大金刚」。它们分别覆盖了公钥加密和数字签名两大场景。我个人习惯，拿到一个新芯片，第一件事就是把这四个算法的参考实现跑一遍，看看硬件底子怎么样。
核心结论先放这儿：
- Kyber：密钥封装机制（KEM），对标传统 RSA/DH 加密。
- Dilithium：数字签名，安全裕度大，实现相对简单。
- Falcon：数字签名，签名尺寸极小，但实现复杂。
- SPHINCS+：数字签名，无状态哈希签名，安全性极其保守。
2.1 CRYSTALS-Kyber：格上的密钥封装
Kyber 是基于 Module-LWE（带错误学习）问题的。你想想看，传统 RSA 靠大整数分解，ECC 靠椭圆曲线离散对数，而 Kyber 靠的是「在一个格子里找一个最近的向量，但给你加了一点点噪声」。破解者要恢复密钥，就得先把这个噪声去掉——这在量子计算机面前也是硬骨头。
Kyber 的流程分三步：密钥生成 → 封装 → 解封装。我在一个智能门锁项目里用过 Kyber-512，密钥生成大概花了 0.3 毫秒（在 Cortex-M4 上），封装和解封装更快。嗯，这里要注意：Kyber 的密文和密钥尺寸是固定的，不像 RSA 那样随密钥长度变化。
| 参数 | Kyber-512 | Kyber-768 | Kyber-1024 |
|---|---|---|---|
| 安全等级 | NIST Level 1 | NIST Level 3 | NIST Level 5 |
| 公钥大小 | 800 字节 | 1,184 字节 | 1,568 字节 |
| 密文大小 | 768 字节 | 1,088 字节 | 1,568 字节 |
| 密钥生成速度 | 快 | 中等 | 慢 |
我的经验： 在 IoT 设备上，Kyber-512 已经足够应对大多数场景。除非你的设备需要处理绝密级数据，否则别上 Kyber-1024——性能开销翻倍，收益却不大。
2.2 CRYSTALS-Dilithium：签名界的「万金油」
Dilithium 也是基于 Module-LWE 的，但它做的是签名。它的特点是：实现简单，安全裕度大，性能均衡。我在一个固件升级验证模块里用过 Dilithium-2，签名验证时间大约 0.5 毫秒，公钥只有 1,312 字节。
Dilithium 的签名过程有点像「零知识证明」的简化版：签名者证明自己知道私钥，但不泄露私钥本身。验证者只需要公钥就能确认签名有效。
为什么说它是「万金油」？因为它对硬件的要求不高，不需要浮点运算，也不需要大内存。你想想看，很多 IoT 芯片连 FPU 都没有，Dilithium 照样跑得欢。
避坑指南： 我曾经在一个项目里直接用 Dilithium 的参考实现，没做任何优化。结果签名生成花了 2 毫秒，但验证却要 5 毫秒——后来才发现是 NTT（数论变换）的实现没做预计算。记住：Dilithium 的 NTT 变换可以提前算好，别每次都重新算。
2.3 Falcon：签名尺寸的「极致瘦身」
Falcon 基于 NTRU 格，它的签名尺寸是所有 NIST 标准签名算法里最小的。Falcon-512 的签名只有 666 字节，而 Dilithium-2 的签名是 2,420 字节。差距有多大？差了将近 4 倍。
但代价是什么？实现极其复杂。Falcon 需要浮点运算（double 精度），而且它的密钥生成和签名过程涉及高精度浮点数的 FFT（快速傅里叶变换）。我在一个带 FPU 的 Cortex-M7 上跑过 Falcon-512，密钥生成花了 10 毫秒——比 Dilithium 慢了 20 倍。
| 特性 | Falcon-512 | Falcon-1024 |
|---|---|---|
| 安全等级 | NIST Level 1 | NIST Level 5 |
| 公钥大小 | 897 字节 | 1,793 字节 |
| 签名大小 | 666 字节 | 1,280 字节 |
| 浮点依赖 | 强依赖 | 强依赖 |
我的建议： 如果你的 IoT 设备有 FPU，而且对签名尺寸有严格要求（比如 LoRa 通信，一帧只能传几百字节），Falcon 是首选。否则，老老实实用 Dilithium。
2.4 SPHINCS+：保守派的「最后防线」
SPHINCS+ 跟前面三个完全不同。它不依赖格，而是基于 哈希函数。说白了，它的安全性只取决于你选的哈希函数（比如 SHA-256）的安全性。量子计算机对哈希函数只有平方根级别的加速，所以 SPHINCS+ 的安全性极其保守。
但代价也很大：签名尺寸大，速度慢。SPHINCS+-128s 的签名有 7,856 字节，比 Dilithium 大了 3 倍多。签名生成时间在 Cortex-M4 上可能要 100 毫秒以上。
我记得有一次做车载 T-Box 的安全启动，客户要求「绝对安全」，我就选了 SPHINCS+。结果签名验证花了 200 毫秒，差点没通过启动时间要求。后来换成了 Dilithium，才把时间压到 50 毫秒以内。
注意： SPHINCS+ 的签名尺寸和速度跟安全等级强相关。选「s」（小签名）变体还是「f」（快）变体，要根据你的实际场景来。我曾经见过有人选了 SPHINCS+-128f，签名尺寸直接飙到 16 KB——这在 IoT 设备上基本不可用。
2.5 四大算法全景对比
下面这张 SVG 图，是我自己画的全景对比。你可以看到四个算法在「安全性」、「性能」、「实现复杂度」和「尺寸」四个维度上的相对位置。
2.6 如何选择？我的决策框架
好了，四个算法都讲完了。你可能会问：那我到底该用哪个？
我个人习惯用这个决策树：
- 需要加密？ → 直接上 Kyber-512 或 Kyber-768。
- 需要签名？ → 看设备有没有 FPU：
- 有 FPU，且签名尺寸敏感 → Falcon-512。
- 无 FPU，或签名尺寸不敏感 → Dilithium-2。
- 安全要求极其保守？ → SPHINCS+-128s，但要做好性能预算。
我的经验： 在 90% 的 IoT 场景里，Kyber-512 + Dilithium-2 的组合就足够了。别为了「万一」去选 Falcon 或 SPHINCS+，除非你真的有明确的尺寸或安全需求。