Bouncy Castle项目中Kyber-768算法的实现差异分析

背景介绍

Bouncy Castle是一个广泛使用的Java加密库，提供了丰富的加密算法实现。近期在Kyber-768算法的实现上，Bouncy Castle与其他实现(如liboqs)之间存在共享密钥不匹配的问题。本文将深入分析这一差异的技术原因。

Kyber算法的发展历程

Kyber是一种基于格的密钥封装机制(KEM)，最初由PQ-Crystals团队开发并提交给NIST后量子密码标准化项目。在标准化过程中，NIST对算法进行了修改，形成了现在的ML-KEM标准方案(FIPS 203)。

实现差异的技术分析

Bouncy Castle实现了NIST FIPS 203方案中的ML-KEM规范，而liboqs等库仍基于Kyber第三轮提交版本。两者在算法流程上存在关键差异：

1. 哈希处理差异：

   • 原始Kyber在封装过程中会额外对系统随机数生成器的输出进行哈希处理
   • ML-KEM移除了这一步骤

2. KDF调用差异：

   • 原始Kyber在生成共享密钥时会额外调用一次KDF函数
   • ML-KEM简化了这一流程

这些修改虽然不影响算法的安全性，但导致了不同实现间无法直接互操作。

解决方案

对于需要与旧版本Kyber实现互操作的场景，可以采用以下方法：

1. 后处理技术： 在ML-KEM生成的共享密钥基础上，可以按照原始Kyber的规范额外应用两次哈希：

   • 首先对密文单独哈希
   • 然后将共享密钥与密文连接后应用SHAKE-256哈希
   • 最后截取前32字节作为最终共享密钥

2. 等待标准最终化： 随着FIPS 203方案的确定，各实现库预计会逐步统一到最新规范。

总结

Bouncy Castle选择紧跟NIST标准方案的做法体现了其对标准合规性的重视。开发者在使用后量子密码算法时，应当注意不同实现间的版本差异，并根据实际需求选择合适的兼容方案。随着后量子密码标准的逐步完善，这类互操作性问题有望得到解决。

对于需要立即解决互操作性问题的项目，建议采用上述后处理技术作为临时解决方案，同时密切关注相关标准的进展和实现库的更新。