7

诸如MurmurHash3和 xxHash 之类的非加密哈希几乎是专门为哈希表设计的，但它们的功能似乎与CRC-32、Adler-32和Fletcher-32相当（甚至更好） 。非加密散列通常比 CRC-32 更快，并产生更多“随机”输出，类似于慢速加密散列（MD5、SHA）。尽管如此，我只看到推荐用于数据完整性/校验和目的的 CRC-32 或 MD5。

在下表中，我测试了 32 位校验和/CRC/哈希函数，以确定它们检测数据细微差异的能力：

桌子

每个单元格中的结果意味着：A) 发现的冲突数，以及 B) 32 个输出位中的任何一个设置为 1 的最小和最大概率。要通过测试 B，最大值和最小值应尽可能接近 50 . 任何低于 45 或高于 55 的值都表示有偏见。

查看表格，MurmurHash3 和Jenkins lookup2与 CRC-32 相比（实际上未通过一项测试）。它们也分布均匀。DJB2 和 FNV1a 通过了碰撞测试，但分布不均。Fletcher32 和 Adler32 难以应对 NullBytes 和 8RandBytes 测试。

那么我的问题是，与其他校验和相比，“非加密哈希”对于检测文件中的错误或差异有多合适？CRC-32/Adler-32/CRC-64 是否有任何理由可能优于任何体面的 32 位/64 位哈希？

4

1 回答 1

4

这个函数在检测数据错误方面是否有任何理由不如 CRC-32 或 Adler-32？

是的，对于某些类型的错误特征。CRC 可以设计为非常有效地检测数据包中的少量比特错误，正如您在实际通信或存储通道上所期望的那样。这就是它的设计目的。

对于大量错误，填充 32 位并在对数据包的所有位敏感方面做得相当好的任何 32 位检查都可以正常工作。所以你的会和 CRC-32 一样好，比 Adler-32 好一点。（Adler-32 故意不使用所有可能的 32 位值，因此误报率略高于使用所有可能值的 32 位检查。）

顺便说一下，多看一下你的算法，它不会分布在所有 32 位值上，直到你有很多字节的输入。因此，在您涵盖检查的可能 32 位值之前，您的检查不会像任何其他 32 位检查那样对大量错误进行检查。

于 2018-02-09T20:58:03.527 回答