BouncyCastle与OpenSSL 3.5的ML-DSA-44密钥交互实践

背景概述

在密码学应用中，ML-DSA-44（Module Lattice-Based Digital Signature Algorithm）是一种基于后量子密码学的数字签名算法。当开发者尝试在Java生态中使用BouncyCastle库处理OpenSSL 3.5生成的ML-DSA-44密钥时，可能会遇到签名验证不一致的问题。本文将深入分析该问题的技术原理和解决方案。

核心问题分析

通过实际案例发现，当使用BouncyCastle 1.80加载OpenSSL生成的ML-DSA-44密钥对时，虽然能成功验证OpenSSL直接生成的签名，但无法验证通过BouncyCastle自身生成的签名。调试过程中发现公钥和私钥的指纹不匹配，这表明密钥加载过程存在异常。

根本原因

问题的根源在于OpenSSL生成的私钥采用了"seed-priv"复合格式，这种格式同时包含种子值和私钥数据。而BouncyCastle的默认实现预期的是"priv-only"格式（仅包含私钥数据）。这种格式差异导致签名生成时使用的密钥材料不一致，从而造成验证失败。

解决方案

1. 密钥格式转换：将OpenSSL生成的私钥从seed-priv格式转换为priv-only格式
2. 配置参数调整：在OpenSSL生成密钥时指定-priv-only参数
3. 版本适配：确保使用BouncyCastle的最新稳定版本（如1.80或更高）

实现建议

对于需要在Java和OpenSSL之间互操作的ML-DSA-44应用，建议：

1. 统一密钥存储格式标准
2. 在跨平台使用时进行充分的兼容性测试
3. 关注密码学库的更新日志，及时获取算法实现变更信息

总结

后量子密码算法的跨平台实现仍处于发展阶段，不同密码学库对密钥格式的处理可能存在差异。开发者需要深入理解底层实现细节，特别是在涉及密钥序列化和反序列化时。通过正确处理密钥格式问题，可以确保BouncyCastle与OpenSSL在ML-DSA-44算法上的无缝协作。

该案例也提醒我们，在后量子密码学过渡时期，保持密码学栈的一致性至关重要，这包括算法实现、密钥管理和数据格式等多个层面的统一。