10

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

散列工作完美=我散列一个字符串,它得出的确切散列是我已经验证它与多个其他来源的确切散列。

  1. 在我的 OSX 机器上编译和运行时,散列功能可以完美运行,并且计算出的散列完全符合其应有的状态。

  2. 相同的代码,在基于 Linux 的服务器上上传和编译没有任何更改,它计算不同的(错误的)哈希。

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

可以在以下位置找到散列功能文件:http: //people.csail.mit.edu/rivest/Md5.c

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

4

5 回答 5

22

尝试替换(Md5.c 第 41 行)

typedef unsigned long int UINT4;

经过

typedef uint32_t UINT4;

(如果需要,包括 stdint.h)

在 64 位机器上 long int (通常)是 64 位而不是 32

编辑

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

于 2009-03-30T14:15:02.773 回答
2

似乎没有工作的机器是否与其他机器不同(32 位与 64 位)?如果 MD5 实现依赖于机器字长(我没有检查代码),这可能会导致散列不同。

于 2009-03-30T14:15:42.693 回答
1

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

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

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

于 2009-03-30T14:15:14.957 回答
0

抱歉,没有。如果我编译它并在我的 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 的问题。

于 2009-03-30T14:15:59.107 回答
0

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

于 2009-03-30T14:18:24.497 回答