在SHA-1附近具有冲突可能性的快速哈希函数

Question

我正在使用SHA-1来检测程序处理文件中的重复项。它不需要加密强大并且可以是可逆的。我找到了这个快速哈希函数列表https://code.google.com/p/xxhash/

如果我希望在靠近SHA-1的随机数据上有更快的功能和碰撞，我该选择什么？

对于文件重复数据删除，128位哈希是否足够好？ （vs 160 bit sha-1）

在我的程序中，哈希是在0 - 512 KB的块中计算的。

Answer 1

也许这会对你有所帮助： https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

  

罕见的碰撞：FNV-1，FNV-1a，DJB2，DJB2a，SDBM＆amp; murmur哈希

我不了解xxHash，但看起来也很有希望。

MurmurHash非常快，版本3支持128位长度，我会选择这个。 （在Java和Scala中实现。）

Answer 2

由于在您的情况下哈希算法的唯一相关属性是冲突概率，您应该估计它并选择满足您要求的最快算法。

如果我们假设您的算法具有绝对一致性，则使用具有 d 可能值的哈希值的 n 文件之间的哈希冲突概率将为：

例如，如果您需要的碰撞概率低于百万个文件中的百万分之一，则需要具有超过5 * 10 ^ 17个不同的哈希值，这意味着您的哈希需要至少为59位。让我们四舍五入到64，以说明可能的差异。

所以我会说任何体面的64位哈希都应该足够了。较长的哈希值将进一步降低冲突概率，代价是计算量较大且哈希存储量增加。像CRC32这样的较短缓存将要求您编写一些显式的冲突处理代码。

Answer 3

Google开发并使用（我认为）FarmHash进行性能关键哈希。来自project page：

  

FarmHash是CityHash的继承者，包括许多相同的技巧和技巧，其中一些来自Austin Appleby的MurmurHash。

     

...

     

在具有所有必要机器指令的CPU上，大约六种不同的哈希函数可以为FarmHash的阵容做出贡献。在某些情况下，我们通过使用现在通常可用的更新指令，在CityHash上取得了显着的性能提升。但是，我们还在其他方面挤出了更多的速度，因此使用CityHash的绝大多数程序在切换到FarmHash时应该至少获得一点。

（CityHash已经是谷歌的性能优化哈希函数系列。）

它是在一年前发布的，此时它几乎肯定是最先进的，至少在已发布的算法中。 （否则谷歌会用更好的东西。）它很有可能它仍然是最好的选择。

Answer 4

事实：

1. 良好的哈希函数，特别是加密函数（如SHA-1）， 需要相当多的CPU时间，因为他们必须尊重一些 在这种情况下对你不是很有用的属性;
2. 任何哈希函数都只能给你一个确定性：如果两个文件的哈希值不同，那么文件肯定是不同的。但是，如果它们的哈希值相等，那么文件也可能是相同的，但唯一可以确定这种“相等”是否不只是哈希冲突的方法是回归到二者的二进制比较文件。

结论：
在你的情况下，我会尝试更快的算法，如CRC32，它具有你需要的几乎所有属性，并且能够处理超过99.9％的情况，并且只采用较慢的比较方法（如二进制比较）排除误报。在大多数比较中快得多，可能会弥补没有“令人敬畏”的一致性（可能会产生更多的碰撞）。

Answer 5

128位确实足以检测不同的文件或块。碰撞的风险是无穷小的，至少只要没有尝试故意碰撞就会发生。

如果要跟踪的文件或块的数量保持“足够小”（即不超过几百万个），那么64位也可以证明是足够好的。

一旦确定了散列的大小，您需要一个具有一些非常好的分布属性的散列，例如链接中列出的Q.Score = 10的散列。

Answer 6

这取决于在迭代中要计算多少哈希值。 例如，64位散列在1000000中达到1的碰撞概率，计算出600万个散列。

请参阅：Hash collision probabilities

Answer 7

结帐MurmurHash2_160。它是对MurmurHash2的修改，它产生160位输出。

它并行计算MurmurHash2的5个独特结果并彻底混合它们。根据摘要大小，冲突概率等于SHA-1。

它仍然很快，但是MurmurHash3_128，SpookyHash128和MetroHash128可能更快，尽管碰撞概率更高（但仍然非常不可能）。还有CityHash256，它产生256位输出，也应该比SHA-1快。