格陷门在模块上的实现及应用与后量子签名验证

### 格陷门在模块上的实现及应用与后量子签名验证 #### 1. 格陷门在模块上的实现及性能 在标准模型签名方案中，为了加速多项式乘法，采用了部分数论变换（NTT），并利用环结构来实现这一目的。同时，使用了与上一节相同的编码方式，该编码方式要求模数 \(q\) 满足 \(q \equiv 2r + 1 \pmod{4r}\) 的条件，以此将 \(M = \mathbb{Z}_q^n/r \setminus \{0\}\) 中的恒等式映射到 \(\mathbb{Z}_q^{d\times d}\) 中的可逆元素。 以下是该标准模型基于身份加密（IBE）方案不同操作的性能表现： | 参数集 | 初始化（Setup） | 提取（Extract） | 加密（Encrypt） | 解密（Decrypt） | | ---- | ---- | ---- | ---- | ---- | | I | 9.82 ms | 16.54 ms | 4.87 ms | 0.99 ms | | II | 44.91 ms | 18.09 ms | 5.48 ms | 1.04 ms | 与其他一些 IBE 方案的操作时间对比情况如下： | 方案 | \((\lambda, n)\) | 初始化（Setup） | 提取（Extract） | 加密（Encrypt） | 解密（Decrypt） | | ---- | ---- | ---- | ---- | ---- | ---- | | BF - 128 [Fou13] | (128, –) | – | 0.55 ms | 7.51 ms | 5.05 ms | | DLP - 14 [MSO17] | (80, 512) | 4.034 ms | 3.8 ms | 0.91 ms | 0.62 ms | 从对比结果来看，虽然该方案的时间表现可能不如 [BFRS18] 中的方案，但由于 [BFRS18] 方案的安全性有限，这种比较并无实际意义。部分时间差异源于构建合适的 FRD 编码所需的算术运算。此外，与 [DLP14] 不同，该方案未使用 NTRU 格，这也是时间差异的原因之一。 #### 2. 后量子签名在 8 kB RAM 中的验证 ##### 2.1 研究背景与挑战 后量子签名方案通常具有较大的密钥和签名，这对资源受限设备上的密码学应用产生了巨大影响。在汽车领域的功能激活等实际应用场景中，签名消息的有效负载往往远小于签名本身，这会带来额外的传输开销。 在汽车行业，通常会使用专用硬件安全模块（HSM）来执行所有加密操作，HSM 类似于 Cortex - M3 处理器，时钟频率为 100 MHz，内存资源有限。一般而言，HSM 用于签名验证的可用内存估计小于 18 kB 的随机存取存储器（RAM）和 10 kB 的闪存，但为了给其他应用和操作系统留出空间，目标是将内存使用降低到 8 kB 的 RAM 和闪存。 在这种受限环境下，HSM 可能无法存储大的公钥或在内存中保留大的签名，甚至主处理器的内存资源也可能不足。此时，公钥或签名必须由车辆网络中的其他设备（如主机单元）提供给 HSM，这就需要通过车载网络将公钥或签名分部分流式传输到目标处理器。例如，车载网络的 CAN 总线典型流式传输速率约为 500 kbit/s（考虑低错误传输率）。 ##### 2.2 解决方案与贡献 为了应对在高度内存受限环境中进行大密钥或大签名的后量子签名验证挑战，提出了流式传输公钥或签名的方法。通过这种方式，签名验证可以仅在受限内存中保留小数据包。当流式传输公钥时，设备需要安全存储公钥的哈希值，以验证流式传输公钥的真实性。在签名验证过程中，公钥会逐步进行哈希计算，以匹配流式传输公钥的数据流。 针对四种不同的签名方案（Dilithium、SPHINCS +、Rainbow 和 GeMSS），实现并测试了公钥和签名流式传输方法。对于 Dilithium 而言，虽然流式传输公钥并非严格必要，但节省的字节可以用于在内存中保留更多中间结果，从而提高验证速度。 为了进行对比，还实现了基于格的 Falcon 方案，在该场景下，由于其整个公钥和签名都能装入