章节摘要:SOURCE 4.x 覆盖 PQClean、liboqs、OpenSSL 3 集成、FPGA/ASIC 加速与侧信道防护。本章对比软件参考实现与生产硬ening 要求。
第四章把第 3 章选定的算法落地为可运行的实现。建议按「软件正确性—性能—安全」三层阅读:第一层是软件栈,理解 PQClean 提供可移植参考实现、liboqs 提供统一 API、oqs-provider 把 PQC 接入 OpenSSL 3,正确性以 NIST KAT 向量为金标准;第二层是性能,理解 NTT 如何加速多项式乘法、FPGA 验证与 ASIC 量产的区别,以及什么场景才值得做硬件卸载;第三层是安全,理解计时、功耗、电磁三条侧信道,掌握恒定时间编程的纪律。
三节内容恰好回答三个问题:我要用现成库还是要自己实现?什么时候该从软件走向硬件?如何证明我的实现没有泄漏密钥?第四章结尾的自检清单可以作为团队验收实现的模板。
| 组件 | 定位 | 使用场景 |
|---|---|---|
| PQClean | 干净可移植 C 参考实现 | 审计与移植参考 |
| liboqs | 统一 KEM/SIG API | 应用直接集成 |
| oqs-provider | OpenSSL 3 插件 | TLS/应用无缝启用 |
| BoringSSL 分支 | 实验性 PQC TLS | 前瞻验证 |
| FPGA/ASIC | NTT 硬件加速 | 高并发、极低功耗 |
对照这张表,结合各节深入讨论,可以快速判断团队当前处于「评估集成」还是「硬件化」阶段。
| 疑问 | 解答 |
|---|---|
| 直接用 liboqs 还是自己实现? | 默认用 liboqs/PQClean,自研格运算除非有独立安全审计支撑。 |
| KAT 通过就代表实现安全吗? | 不,KAT 只验证正确性;侧信道泄漏要另做恒定时间与时序测试。 |
| 硬件加速是不是标配? | 不是,多数场景软件 AVX2 已够用;硬件化出现在超高并发或极低功耗场景。 |
| 为什么强调随机源质量? | PQC 封装与签名都依赖随机数,可预测的随机源会让密钥与签名直接泄露。 |
实现层的每一项选择,最终都会在第 5 章的迁移演练中接受检验——提前想清楚这几个问题,能少走不少弯路。