BC-Java项目中Dilithium签名算法的签名大小分析

摘要

本文分析了Bouncy Castle密码库(BC-Java)中实现的Dilithium后量子签名算法与NIST技术规范中规定的签名大小差异问题。通过深入的技术探讨，解释了这种差异产生的原因，并确认了Bouncy Castle实现的正确性。

背景介绍

Dilithium是一种基于格的后量子密码学签名算法，已被NIST选为后量子密码标准(PQC)的候选算法之一。在密码学实现中，签名大小的精确性对于协议设计和系统集成至关重要。

问题描述

在使用BC-Java 1.77版本测试Dilithium签名时，发现以下签名大小差异：

• dilithium3: BC实现为3309字节，而NIST技术规范中ML-DSA-65的参考值为3293字节
• dilithium5: BC实现为4627字节，而NIST技术规范中ML-DSA-87的参考值为4595字节

这种差异可能会引起开发者的困惑，特别是当需要严格遵循标准规范时。

技术分析

经过深入调查，发现这种差异并非BC-Java实现的错误。实际上，NIST已经在其网站上发布说明，承认技术规范中的表2给出的签名大小和私钥大小值存在偏差。

BC-Java中的实现基于Dilithium算法的原始论文和参考实现，其签名大小计算是正确的。签名大小的差异源于：

1. 算法参数的实际编码需求
2. 签名结构中各组成部分的精确大小计算
3. 必要的填充和格式要求

实现验证

通过分析BC-Java的源代码，可以确认其签名生成过程严格遵循Dilithium算法的数学定义。签名大小的计算考虑了：

• 多项式向量的编码
• 随机数生成器的输出
• 必要的校验信息
• 抗碰撞哈希的输出

结论与建议

对于使用BC-Java中Dilithium实现的开发者，可以放心使用当前的签名大小值。NIST已在后续的文档更新中修正了这一偏差。

在实际应用中，开发者应当：

1. 始终使用密码库提供的API获取实际的密钥和签名大小
2. 避免在代码中硬编码来自标准文档的大小值
3. 关注NIST标准的更新情况
4. 在系统设计时为签名大小留出足够的缓冲区

后量子密码学是一个快速发展的领域，标准和实现都在不断演进中。保持实现的灵活性是应对这种变化的关键。