3.2 入选算法特性
3.2 入选算法特性
本节摘要：SOURCE 3.3 对比 CRYSTALS-Kyber、Dilithium、Falcon、SPHINCS+ 的参数集与安全级别。本节用一张总表支撑 TLS/代码签名选型。
本节导航
- 对照 Level 1/3/5 与 AES-128/192/256 对应关系
- 为 TLS 选 Kyber-768 的理由
- 为固件签名在 Dilithium vs Falcon 间取舍
一、标准算法对照（SOURCE 3.3）
| 算法 | 功能 | 推荐参数 | 安全级别 |
|---|---|---|---|
| Kyber | KEM | Kyber-768 | ≈ AES-192 |
| Dilithium | 签名 | Dilithium3 | NIST Level 3 |
| Falcon | 签名 | Falcon-512 | 紧凑签名 |
| SPHINCS+ | 签名 | SPHINCS+-SHA256 | 保守哈希假设 |
标准算法尺寸对比
二、尺寸与性能权衡
| 算法 | 公钥 | 签名/密文 | 速度 |
|---|---|---|---|
| Kyber-768 | 1184 B | 1088 B | 快 |
| Dilithium3 | 1952 B | 3293 B | 快 |
| Falcon-512 | 897 B | 690 B | 中 |
| SPHINCS+-128s | 32 B | ~7856 B | 慢 |
# 概念：liboqs 算法选择 # OQS_KEM_alg_is_enabled(OQS_KEM_alg_kyber_768) # OQS_SIG_alg_is_enabled(OQS_SIG_alg_dilithium_3)
⚠️ 常见坑：混用不同安全级别的 Kyber 与 Dilithium——应统一 Level 3 套件。
💡 关键直觉：入选算法表是部署的「菜单」，不是自由组合 buffet。
一节小结
- Kyber-768 + Dilithium3 是 Level 3 默认搭配
- Falcon 适合带宽敏感签名
- SPHINCS+ 作哈希保守备份
- 参数名与 FIPS 编号需查最新标准
深入讨论：安全级别与参数集如何映射到实际选型
NIST 的安全级别定义方式很有工程价值：它不直接说「这套参数抗多少量子比特的攻击」，而是把困难等价到「破解一个经典对称算法所需的工作量」。Level 1 对应破解 AES-128 的难度，Level 3 对应 AES-192，Level 5 对应 AES-256。这套翻译让密码团队可以用「我们默认 AES-192 级的长期保密强度」这样的语言，直接映射到「选 Kyber-768 与 Dilithium3」，新旧系统的安全强度因此可以统一度量。
参数集命名也有讲究。Kyber 系列有 Kyber-512（Level 1）、Kyber-768（Level 3）、Kyber-1024（Level 5）三档，Dilithium 有 Dilithium2/3/5。选型时一个常见陷阱是混用不同级别：例如密钥交换用 Kyber-512，签名用 Dilithium5，名义上都算 PQC，但整体安全强度被最低的一档拉低，这种不一致在合规审计里很难解释。
# 参数集选型决策清单 场景目标 推荐组合 理由 Web 公网 TLS 通用 X25519MLKEM768 兼容主流客户端，Level 3 高保密长期归档 ML-KEM-1024 对应 AES-256 级长期强度 固件签名（带宽敏感） ML-DSA-44 + Falcon 小签名，适合 OTA 更新 根信任锚 / 归档签名 SLH-DSA（SPHINCS+） 仅依赖哈希假设，最保守 高安全敏感终端 ML-KEM-768 + ML-DSA-65 统一 Level 3，便于审计
另一个容易忽略的点是算法的标准化文件名。FIPS 203 官方名为 ML-KEM，FIPS 204 官方名为 ML-DSA，FIPS 205 官方名为 SLH-DSA，行业习惯上仍用 Kyber、Dilithium、SPHINCS+ 称呼。阅读标准文档、厂商白皮书与供应链物料清单时，两套名称都要能对应上，否则在合规与采购环节容易出现误会。
工程实践扩展：性能数字在不同平台上的真实差异
标准算法表里的性能数字只是参考值，真实差异来自三方面：一是 CPU 指令集，现代 CPU 上的 AVX2 与 BMI2 指令能大幅加速 NTT，ARM 平台则依赖 NEON 指令，不同架构的实现差距可达数倍；二是编译器优化，编译选项与优化等级会影响向量化程度与内存布局；三是运行环境，容器化部署中的 CPU 配额、虚拟化层的指令集透传，都会让同一份二进制在不同环境跑出不同结果。
这意味着选型评审不能只对照文档表格，还应在目标硬件上做基准测试。特别是当业务场景对延迟敏感（如高并发 TLS 网关）或对功耗敏感（如 IoT 设备）时，实测数据比任何规格表都更能指导决策。基准测试的样本要覆盖冷启动与满负载两种状态，因为 PQC 的密钥生成在首次初始化时的开销，与后续会话建立时的开销并不相同。
# 性能基准测试设计要点 1. 选定目标平台：x86-64 AVX2 / ARM64 NEON 各至少一台 2. 固定编译选项与依赖库版本，记录哈希值便于复现 3. 测密钥生成、封装/签名、解封装/验证三段的 P50/P99 4. 覆盖冷启动（首次初始化）与稳态（并发会话）两种场景 5. 与基线算法（RSA-2048 / ECDSA P-256）同条件对比 6. 输出数字回填到选型表，作为与文档值的对照差异
把实测数据回填进参数对照表，是文档与实际之间的一次校准。它能帮你回答「这个算法到底比我现在的慢多少」「硬件卸载有没有必要」这类预算问题，为 4.2 硬件加速与 5.1 迁移排期提供事实依据。
最后提醒一点：安全级别不是越高越好。Level 5 的密钥与密文都更大，加解密也更慢，对多数业务而言 Level 3 已经提供了足够长的保密窗口，Level 5 通常只用于长期归档或高敏感场景。选型评审时把「目标安全级别」与「数据实际保密期」绑定，可以避免为用不上的强度付出带宽与延迟成本。
选择参数时还要看清一个细节：同一算法的不同参数集之间，安全级别、尺寸与速度呈连锁关系，不能只按名册挑其中一个数字。建议把选定的组合（如 Kyber-768 配 Dilithium3）作为一个整体写进配置模板，避免人为拆分造成前后不一致。