Background

我最近发现md5使用R包在大型digest对象上的哈希值在进行小改动时没有改变。这似乎是由于一些32位计数器变量溢出而算法错过了文件的更改部分。

在Linux上使用当前开发版本的digest，哈希注意到大文件上的这些小变化，而在Windows上，这些小变化会被遗漏。

我对当前的开发版本进行了以下更改，该版本为unsigned long int（unit32）变量交换了几个unsigned long long int（uint64）变量：

现在在Windows上，问题得到解决，哈希注意到了这些变化。

Question

是否将这些32位整数变量换成64位整数变量是否良性？在32位系统上有什么东西会被破坏吗？在晦涩的系统上？什么都出错了？

0
投票

在32位系统上，通常使用两个32位寄存器实现64位整数。对这样的整数的操作导致两个加载和存储指令。对于像添加这样的东西，使用随身携带添加。这是编译器负责的事情。

您应该只确保您使用的编译器支持这种类型。

例如，在C99中引入了有符号和无符号版本的long long int（应该至少为64位）。所以你应该使用编译器支持C99标准的这个功能。

0
投票

字符串的MD5哈希是一个唯一明确定义的值，这是MD5哈希的一个重要特征。它允许它用于验证。（尽管MD5的加密使用已经被弃用了一段时间。）

因此，如果一个特定的库产生错误的哈希值，那就是一个bug，而且是一个非常严重的哈希值，它应该被报告给包作者。 MD5哈希的参考实现可用于获取正确的哈希值，但md5sum命令很可能也是正确的，这可能是一个更简单的检查。

如果您可以验证它是一个错误，那么有问题的错误肯定是由于意外的32位整数溢出造成的。但是修改加密库不是偶然的活动，甚至是不推荐使用的算法。 “它似乎工作”通常不是一个适当的算法验证。我会提醒您不要使用未经验证的修改。但它对图书馆维护者来说是一个有用的提示。