关于 FIBEMATE:FIBEMATE 是一个开源的后量子密码(PQC)工程验证平台,覆盖算法元数据注册表、CBOM 盘点、CI 策略门禁、KAT 自测与硬件加速基准五条流水线。本文的全部数据来自其独立子项目 pqc-hw-bench(github.com/Lennonhaha/pqc-hw-bench),一个以统一方法论测量 ML-KEM / ML-DSA 在 FPGA 与 CPU 上延迟、吞吐、资源与能效的基准框架,构建脚本与原始数据全部开源。官网:fibemate.net
本系列前三篇分别讨论了迁移动因(国密 PQC 标准真空期)、混合 HTTPS 落地,以及工具链建设。本文转向更底层的问题:当 PQC 需要部署到边缘设备、IoT 网关、专用服务器时,软件实现是否够用;若不够用,硬件加速应如何评估。
云厂商的 PQC 方案目前集中在软件层:KMS、TLS 端点、API 网关。这并非能力问题,而是激励方向不同,其客户需要的是“启用混合密钥交换”这一能力开关,而非“某一器件上 NTT 核的资源占用”这类基准报告。
学术界产出了大量硬件数据,但通常以论文表格形式呈现:给出器件型号、频率、资源占用,不提供构建脚本。读者若要核对,需按论文描述自行重建工程,而重建过程存在大量自由裁量空间;一旦结果对不上,无法区分是论文本身的问题还是重建过程的问题。
因此在二者之间存在一个空档:可被一条命令复现的硬件基准。本文给出的是这一形态的样本,Artix-7 35T 上的一个 ML-KEM NTT 核,WNS +9.733 ns、235 LUT / 191 FF,以及产生这两组数字的完整命令。
需要说明的是,本文不给出 FPGA 相对 CPU 的加速倍数。原因见第 7 节。
讨论 NTT 硬件加速时,常见做法是先给出一个占比论断,即 NTT 是 ML-KEM 的性能瓶颈,占 decaps 全部周期的百分之多少。本文不采用这一写法,原因有二。
其一,本项目的基准记录中未包含 cycle-level 剖析数据,因此没有可供引用的自有测量结果。
其二,公开的 Kyber 剖析数据(CEUR Vol-4055)给出的 Kyber-512 中位 cycle 分布如下:
操作 | 中位 cycle |
|---|---|
NTT | 13,520 |
Inverse NTT | 22,998 |
多项式乘法 | 9,014 |
矩阵生成 | 74,202 |
其中矩阵生成的开销超过 NTT、INTT 与多项式乘法三者之和。在这组数据下,“NTT 占六成”这一常见印象并不成立。
更需注意的是,该组数据来自单平台实测,即特定的 CPU、编译选项、参考实现版本与统计口径(中位数而非均值)。更换实现、优化等级或指令集环境(如是否启用 AVX2),该表的排序完全可能改变。因此它只能支撑定性结论,不能作为任何定量百分比的依据。
综上,本节给出两条可引用的结论:
将这一数据缺口写入正文而非省略,是因为它体现了本文对基准的一贯立场:基准的可信度不取决于给出了多少数字,而取决于是否明确交代未测量的部分。
项 | 值 |
|---|---|
器件 | xc7a35tfgg484-2(Artix-7 35T) |
工具 | Vivado 2021.1(WebPACK,免费版本) |
时钟约束 | 50 MHz(20 ns) |
目标核 | u_ntt_core(v5_2) |
RTL 规模 | hardware/rtl/ntt/ 下 21 个 Verilog 文件 |
选择 35T 的依据不是性能,而是可及性。该器件可由百元级开发板承载,且 Vivado WebPACK(免费许可)对 Artix-7 35T 提供完整支持,任何希望核对本文数字的读者,其成本门槛接近于零。
若改用 Virtex UltraScale+ 等高端器件,可以获得更优的绝对数字,但能够复现该结果的读者比例会大幅下降,基准的验证价值随之削弱。可复现性是一项设计决策,而非事后补充说明。
指标 | 值 |
|---|---|
WNS(Setup) | +9.733 ns,0 failing |
Hold / Pulse Width | 0 failing,全 MET |
可运行上限 | ~97 MHz |
NTT 核资源 | 235 LUT / 191 FF / 96 Slice |
顶层资源(含 UART 等外围) | 1754 LUT / 2422 FF |
WNS 为 +9.733 ns,表明在 50 MHz 约束下仍余约 10 ns,对应运行上限约 97 MHz。该结果并非临界收敛,余量意味着同一套 RTL 迁移到性能较低的器件或增加外围逻辑时仍有调整空间。
此处需明确区分两个数字:235 LUT 为核级资源,1754 LUT 为顶层资源。后者包含 UART 调试通道、LED 及 SoC 粘合逻辑,与 NTT 算法本身无关。混淆二者是硬件基准中最常见的引用错误,第 5 节将专门讨论。
本项目的历史 release(v5_3)中,同一个 NTT 核标注为 858 LUT;当前报告为 235 LUT,相差 3.6 倍。这并非实现被优化缩小,而是综合报告口径不同:858 为包含中间层次、按默认层次汇总的结果;235 则是通过 report_utilization -cells u_ntt_core 精确剥离到核级后的结果。
同一设计在三个层次上对应三个均合法的数字:
引用时应依据所要回答的问题选择对应数字:
需要回答的问题 | 应引用的数字 |
|---|---|
NTT 核(含监控)总资源 | 235 LUT |
其中算法部分(u_core) | 131 LUT |
其中监控部分(u_hw) | 101 LUT |
整板资源占用 | 1754 LUT |
算法部分 131 LUT 与监控部分 101 LUT 相加为 232,加上粘合逻辑约为 235。
其中 u_hw(运行期硬件监控)单独占用 101 LUT,接近算法核的一半。这是侧信道加固的成本:在数据通路上部署监控逻辑必然付出资源代价。将加固前后的资源数字放在同一报告中比较而不加说明,同样属于口径误导。
由此建议:发布硬件资源数字时,同时给出核级与顶层两个数值,并注明剥离命令。缺少剥离命令的数字无法被他人核对,因而也不具备基准意义。
可复现性可以量化。本项目执行了两次独立构建:
构建 | WNS |
|---|---|
本次复现(2026-09-06) | 9.733 ns |
历史 release(v5_3) | 9.752 ns |
差异 | 0.019 ns |
run-to-run 差异不足 0.02 ns,表明该设计的时序结果对工具噪声不敏感,这是结果可被第三方验证的前提。若两次构建相差 2 ns,他人复现不一致时将无法判定根源是环境差异还是设计本身。
复现命令(前置条件:Vivado 2021.1,WebPACK 版本即可):
原始 CSV 与 JSON 数据均存放于仓库 results/raw/ 目录,未经二次加工。
先给出 CPU 侧基线(liboqs 0.16.0,AVX2,覆盖 95 个算法,均值 μs/op):
算法 | keygen | encaps | decaps |
|---|---|---|---|
ML-KEM-512 | 278.91 | 327.55 | 34.81 |
ML-KEM-768 | 345.35 | 379.74 | 47.12 |
ML-KEM-1024 | 406.77 | 461.85 | 76.53 |
(同批次 ML-DSA-65:keypair 489.86 / sign 1048.22 / verify 158.35 μs。)
上述 LUT 数与微秒数之间不存在换算关系,原因有三:
实现公平对比尚缺三步:(a) 在 FPGA 上完成完整 ML-KEM 实现(而非仅有 NTT 核);(b) 将数据搬运与 BRAM 带宽计入端到端延迟;(c) 统一测量口径(相同安全等级、相同测试向量、相同统计方法)。上述三步完成之前,本文不给出加速倍数。
为避免误读,以下明确列出本文数字不适用的范围:
$/Mops 与 W/Mops 需依赖真实芯片单价与实测功耗,两项数据均待补充,目前仅有接入点而无计算结果。硬件基准中最主要的偏差来源,往往不是测量误差,而是选择性披露,即只公开对结论有利的那部分数字。858 还是 235,取决于所回答的问题;FPGA 是否更快,取决于比较对象是核还是整机。绝对数值偏小并不削弱结论的效力,缺失口径说明才会使结论失去可验证性。
可被推翻,是基准成立的前提。
results/raw/summary-2026-09-07.csvdocs/tvla-methodology.mdFIBEMATE · 开源后量子密码(PQC)工程验证平台 · fibemate.net · github.com/Lennonhaha/fibemate
本文数据均来自开源仓库 pqc-hw-bench,构建脚本与原始数据可自由获取与核对。转载请注明出处。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。