JohnTheRipper项目中MSSQL05格式在AVX512BW构建下的哈希分析异常研究

问题背景

在密码安全审计工具JohnTheRipper的最新开发版本中，测试人员发现了一个与MSSQL05哈希格式相关的兼容性问题。该问题表现为：当使用支持AVX512BW指令集的处理器进行编译构建时，程序会遗漏部分特定密码的分析，而这些密码在使用AVX2指令集构建的版本中能够被正常处理。

问题现象

测试人员通过对比测试发现，以下三个特定哈希值在AVX512BW构建中无法被处理：

• 空字符串密码（''）
• 单空格字符密码（' '）
• 特定Unicode字符密码（'�'）

值得注意的是，当这些哈希被单独测试时，AVX512BW构建又能够成功处理。这表明问题与并行处理机制相关，而非算法本身的实现错误。

技术分析

经过深入调查，开发团队发现了几个关键点：

1. 编译器相关性：该问题在使用Clang编译器时出现，而使用GCC编译时则表现正常。这表明问题可能与不同编译器对AVX512BW指令集的优化实现差异有关。

2. SIMD并行度设置：在x86-64.h头文件中，Clang编译器默认将SHA1算法的SIMD并行度(SIMD_PARA_SHA1)设置为2，这导致了问题的出现。将其改为1后，问题得到解决。

3. 内存清理机制：在set_key函数实现中，存在一个关键的内存清理循环。在AVX512BW构建中，由于并行处理的方式，这个清理循环可能过早终止，导致部分内存区域未被正确初始化。

4. 字节序处理：代码中存在多处直接操作内存位置的硬编码实现，缺乏统一的字节序处理机制，这在不同架构和指令集下可能导致不一致的行为。

解决方案

开发团队提出了多层次的解决方案：

1. 立即解决方案：

   • 对于Clang编译器，将SIMD_PARA_SHA1的值从2降为1
   • 修改内存清理循环的逻辑，确保所有相关内存区域都被正确初始化

2. 长期改进方案：

   • 统一使用标准的字节序处理宏（如GETPOSW32）
   • 重构内存访问代码，消除硬编码的内存位置计算
   • 增强测试覆盖，特别是针对边界情况（如空密码、单字符密码等）

性能影响

调整SIMD并行度后，性能表现有所变化：

• 多盐值场景：性能从88379K c/s提升至92715K c/s
• 单盐值场景：性能从61457K c/s降至56539K c/s

这种性能变化表明，降低并行度在某些场景下反而可能带来性能提升，这为未来的优化方向提供了重要参考。

经验总结

这个案例为密码安全工具开发提供了几个重要启示：

1. 编译器差异：不同编译器对SIMD指令集的优化可能存在显著差异，需要进行全面测试。

2. 边界条件测试：特殊密码（如空密码、单字符密码）的测试不可或缺，它们往往能暴露底层实现的缺陷。

3. 代码可移植性：避免硬编码的内存操作，使用统一的抽象接口可以提高代码在不同平台和架构下的可靠性。

4. 性能与正确性的平衡：在追求极致性能的同时，必须确保算法的正确性，有时适度的性能妥协是必要的。

这个问题也凸显了密码安全工具开发中的复杂性，特别是在利用现代处理器特性时，需要更加谨慎地处理底层细节，确保在各种环境下都能获得一致且可靠的结果。