Hash 128位哈希的任何64位部分是否与64位哈希一样具有防冲突性？

我们正试图解决开发团队的内部争论：

我们正在寻找一个64位PHP哈希函数。我们找到了，但是hash3是32位或128位，而不是64位

同事#1认为，要从杂音散列3生成64位散列，我们只需将128位散列的第一个（或最后一个，或任何一个）64位切分，它将与本机64位散列函数一样具有防冲突性

同事#2认为，我们必须找到一个本机64位哈希函数来减少冲突，128位哈希的64位切片不会像本机64位哈希那样防止冲突

谁说得对

---

如果我们采用加密散列的第一个（或最后一个，或任何）64位，比如SHA1而不是3，答案会改变吗？

由于雪崩效应，强散列是源中的一个位的变化导致散列平均一半的位翻转。因此，对于一个好的散列，“散列度”是均匀分布的，因此每个部分或片都受到相等且均匀分布的源比特量的影响，因此与具有相同比特长度的任何其他片一样强

---

我同意同事1的观点，只要散列具有良好的属性且分布均匀。

如果你有真正的随机、均匀分布的值，那么“切片”将产生完全相同的结果，就像你从一开始就使用较小的值一样。要知道为什么，考虑这个非常简单的例子：假设你的随机发生器输出3个随机位，但是你只需要一个随机位来处理。让我们假设输出是

b1 b2 b3

可能的值是

000, 001, 010, 011, 100, 101, 110, 111

所有这些都以1/8的概率发生。现在，无论你从这三个位置中切出多少位，第一位、第二位或第三位，得到“1”的概率总是1/2，不管位置如何，对于“0”也是如此

你可以很容易地将这个实验扩展到128位中的64位：不管你对哪个位进行切片，在某个位置以1或0结尾的概率都是一半。这意味着，如果从均匀分布的随机变量中抽取样本，那么切片不会使碰撞的概率增加或减少

现在一个好问题是随机函数是否真的是我们能做的防止碰撞的最好方法。但事实证明，只要函数偏离随机值，发现碰撞的概率就会增加

加密散列函数：合作者#1获胜 现实生活中的问题是，哈希函数根本不是随机的，相反，它们是无聊的确定性函数。但是加密散列函数的设计目标如下：如果我们不知道它们的初始状态，那么它们的输出在计算上与真实随机函数是无法区分的，也就是说，没有计算效率高的方法来区分散列输出和真实随机值之间的差异。这就是为什么你会认为哈希已经被破解了，如果你能找到一个“区分器”，一个方法来告诉哈希从真正的随机值的概率高于一半。不幸的是，我们无法真正证明现有加密哈希的这些属性，但除非有人破坏它们，否则我们可能会假定这些属性具有一定的可信度。下面是一个关于SHA-3提交文件之一的识别器的示例，说明了该过程

总而言之，除非为给定的加密散列找到了区分符，否则切片是非常好的，不会增加冲突的概率

非加密散列函数：合作者#2可能获胜 非加密散列不必像加密散列那样满足相同的要求。它们通常被定义为“在正常/善意的条件下”非常快并满足某些属性，但如果有人试图恶意操纵它们，它们可能很容易达不到要求。这在实践中意味着什么的一个很好的例子是今年早些时候提出的对哈希表实现（）的计算复杂性攻击。在正常情况下，非加密散列可以很好地工作，但一些巧妙的输入可能会严重破坏它们的抗冲突性。加密散列函数不能做到这一点，因为它们的定义要求它们不受各种智能输入的影响

因为有可能，有时甚至很容易，为非加密散列的输出找到如上所述的区分符，我们可以立即说它们不符合加密散列函数的条件。能够辨别差异意味着输出中存在某种模式或偏差

这一事实本身就意味着它们或多或少偏离了一个随机函数，因此（在我们上面所说的之后）碰撞的可能性可能比随机函数更大。最后，由于冲突已经以较高的概率发生，对于完整的128位，这不会随着较短的输出而变得更好，在这种情况下，冲突的可能性可能更大

---

tl；dr截断加密哈希函数时，使用它是安全的。但是，与将输出更大的非加密哈希函数截断为64位相比，使用“本机”64位加密哈希函数更好。

如果不提及这一点，这个问题似乎是不完整的：

一些散列是可证明的特定输入类的散列（例如，对于长度

n

的输入，对于

n

的一些合理值）。如果您截断该散列，那么您很可能会破坏该属性，在这种情况下，根据定义，您将冲突率从零增加到非零，并且您在该用例中削弱了散列

这不是一般情况，但这是一个exa