非加密哈希值如何检测数据与CRC-32等中的错误？

Question

MurmurHash3和xxHash等非加密哈希几乎专门用于哈希表，但它们似乎与CRC-32，Adler-32和{{的比较相当（甚至有利） 3}}。非加密散列通常比CRC-32快，并产生类似于慢速加密散列（MD5，SHA）的更多“随机”输出。尽管如此，我只看到CRC-32或MD5被推荐用于数据完整性/校验和目的。

在下表中，我测试了32位校验和/ CRC /散列函数，以确定它们检测数据中的小差异的程度：

Fletcher-32

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

查看表格，MurmurHash3和与CRC-32（实际上未通过一次测试）相比具有优势。它们也很好分布。 DJB2和FNV1a通过碰撞测试，但分布不均匀。 Fletcher32和Adler32与NullBytes和8RandBytes测试斗争。

那么我的问题是，与其他校验和相比，检测错误或文件差异的“非加密哈希”有多合适？ CRC-32 / Adler-32有什么原因吗？ / CRC-64可能胜过任何体面的32位/ 64位哈希？

Answer 1

  

是否有任何理由这个功能不如CRC-32或   Adler-32用于检测数据中的错误？

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

对于大量错误，任何填充32位的32位检查以及对数据包的所有位敏感的相当好的工作都将起到与其他任何位相同的作用。所以你的CRC-32和Adler-32都要好得多。 （Adler-32故意不使用所有可能的32位值，因此误报率略高于使用所有可能值的32位检查。）

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