Open Quantum Safe liboqs项目中ML-KEM测试向量顺序问题分析

在密码学实现中，随机数的生成和使用顺序对算法的正确性至关重要。本文分析了Open Quantum Safe的liboqs项目中ML-KEM(Module-Lattice Key Encapsulation Mechanism)实现中一个关于随机数顺序的潜在问题。

问题背景

ML-KEM是后量子密码学中的一种密钥封装机制，其算法规范(FIPS-203)明确规定了随机数的使用顺序。在密钥生成和封装过程中，需要使用三个随机数分量：

• z：用于密钥生成
• d：用于确定性密钥生成
• m：用于消息封装

根据规范要求，随机数流应按[z || d || m]的顺序构造，即第一个随机字节应为z，接着是d，最后是m。

实现中的顺序问题

在liboqs的当前实现中，存在以下不一致：

1. 代码首先生成64字节的随机数，其中前32字节用于密钥生成(对应d)，后32字节附加到私钥末尾(对应z)
2. 这种实现方式实际上构造了[d || z || m]的顺序
3. 目前测试通过是因为NIST中间测试向量中z和d的值恰好相同

技术影响

这种顺序不一致会导致以下潜在问题：

1. 当z和d取值不同时，测试将失败
2. 与FIPS-203规范不符，可能影响互操作性
3. 在正式部署环境下可能产生错误结果

解决方案

解决此问题的方法相对简单：只需在测试向量生成时交换z和d的顺序即可。具体来说，应将测试脚本中随机数的提取顺序调整为d在前，z在后，以匹配实际代码中的使用顺序。

总结

密码学实现中的细节问题往往容易被忽视，但可能带来严重后果。这个案例提醒我们：

1. 必须严格遵循算法规范
2. 测试向量应覆盖各种边界情况
3. 随机数的生成和使用顺序需要特别关注

对于liboqs项目而言，及时修正这个问题可以确保ML-KEM实现的正确性和与标准的兼容性，为后量子密码学的实际部署奠定坚实基础。