Botan项目中ML-DSA签名验证与FIPS 204标准的兼容性问题分析

背景介绍

在密码学领域，ML-DSA（Module Lattice Digital Signature Algorithm）是基于格密码学的数字签名算法，被纳入FIPS 204标准。近期在Botan密码库（版本3.6.1）的集成测试中发现了一个重要问题：该库无法通过FIPS 204 ACVP（Automated Cryptographic Validation Program）的签名验证测试向量。

问题现象

开发团队在将ML-DSA支持添加到strongSwan的Botan插件时，发现以下异常情况：

1. FIPS 204 ACVP签名验证测试用例（tcId: 1, 20, 31）验证失败
2. 相同的测试向量在使用wolfssl库（版本5.7.4-stable）时却能正常工作
3. Botan库的密钥生成测试用例（tcID: 1, 26, 51）通过验证
4. 自行编写的完整流程测试（密钥生成→签名→验证）也能正常工作

技术分析

经过深入调查，发现问题根源在于ML-DSA标准实现中的上下文字符串（context string）处理机制。根据FIPS 204标准Algorithm 2的规定：

1. ML-DSA引入了上下文字符串概念，默认情况下为空
2. 即使上下文字符串为空，消息代表μ(μ)也必须包含与上下文关联的空长度字段
3. 这是标准中明确要求的格式处理

Botan库严格按照FIPS 204标准实现了这一机制，而ACVP测试数据实际上测试的是"内部接口"而非完整的签名方案，因此缺少了上下文字符串头部的处理。

解决方案验证

为了验证这一结论，开发团队进行了以下测试：

1. 修改Botan的ML-DSA实现，跳过上下文字符串头部处理后，验证成功
2. 使用BoringSSL提供的Wycheproof测试向量进行验证，这些测试用例正确实现了ML-DSA上下文字符串编码
3. 检查PQ-Crystals参考实现，确认其正确处理了上下文头部

最佳实践建议

对于需要在项目中实现ML-DSA的开发者，建议：

1. 完整实现FIPS 204标准，包括上下文字符串处理
2. 使用BoringSSL的Wycheproof测试向量作为参考
3. 注意区分"内部接口"测试和完整方案测试
4. 对于签名操作，使用"Randomized"模式
5. 对于验证操作，使用"Pure"模式

结论

Botan库对ML-DSA的实现实际上是正确的，它严格遵循了FIPS 204标准规范。所谓的"失败"实际上是测试向量本身的问题，它们没有完整反映标准要求。这一案例凸显了密码学实现中严格遵循标准规范的重要性，以及使用权威测试向量的必要性。