MD5 哈希在服务器上的计算方式不同答案

【问题标题】：MD5 hash calculates differently on serverMD5 哈希在服务器上的计算方式不同
【发布时间】：2010-10-16 09:22:29
【问题描述】：

我正在运行一些我用 C 编写的代码，它从其他人编写的散列库（md5.c 和 md5.h）中调用 md5 散列功能。我看到的奇怪行为是：

散列工作完美 = 我对一个字符串进行散列，结果得到我已验证它与多个其他来源的确切散列。

有没有人知道这到底是怎么可能的？过去一周一直在疯狂，我不明白为什么这是可能的。我还在另一台机器上对其进行了测试，编译并执行，它运行良好。只是当我将它上传到服务器时，哈希不再正确。

哈希函数文件可以在以下位置找到： http://people.csail.mit.edu/rivest/Md5.c

已解决：谢谢大家这是 64 位架构问题。调试时突然想到这一点，真是太烦人了.......

【问题讨论】：

澄清一下，您的意思是应该对 MD5 散列函数进行库调用的编译代码返回错误的结果？如果是这样，您是否确认在服务器和本地都提供了相同的 input？你可以在发送之前调试打印吗？
是的，我没有更改的编译代码，我只是上传到服务器给我一个不同的哈希结果。我什至放入了一个永远不会改变的静态变量，并在函数调用之前验证了输入，它给了我两个不同的哈希值。很奇怪。
请您澄清一下 - 您上传二进制文件还是上传源代码并编译？
对已接受答案的一点更新。要更改的行现在位于 global.h，line 22。

【解决方案1】：

尝试替换（Md5.c 第 41 行）

typedef unsigned long int UINT4;

通过

typedef uint32_t UINT4;

（如果需要，包括 stdint.h）

在 64 位机器上，long int（通常）是 64 位而不是 32 位

编辑：

我尝试了一个 64 位的 opteron，这解决了这个问题。

【讨论】：

【解决方案2】：

似乎没有工作的机器与其他机器（32 位与 64 位）的架构不同吗？如果 MD5 实现依赖于机器字长（我没有检查代码），这可能会导致哈希值不同。

【讨论】：

【解决方案3】：

不同的编译器可以有不同级别的标准合规性。如果您遇到不符合标准的编译器，您可能很难看到经过良好测试的代码已被编译为完全不同的工作方式。

也可能发生目标系统是 64 位且代码存在 64 位可移植性问题的情况。

解决问题的唯一方法是调试代码的两个版本的行为不同之处。

【讨论】：

【解决方案4】：

你确定你是在二进制模式下阅读吗？否则，换行符将在不同的操作系统中以不同的方式转换。

【讨论】：

【解决方案5】：

对不起，没有。如果我编译它并在我的 linux x86 机器上运行它，它会产生与 md5sum 实用程序相同的结果：

peregrino:$ md5sum csrc/Md5.c d27fd5f04426a3ccb2390d7517f21b9c csrc/Md5.c peregrino:$ bin/Md5 csrc/Md5.c d27fd5f04426a3ccb2390d7517f21b9c csrc/Md5.c

在我的 x64 盒子上：

圣地亚哥：$ bin/Md5 src/Md5.c 09679964608e3335c5c3e14572373eef src/Md5.c

所以看起来确实是 64 位问题，而不是 linux 问题。

【讨论】：