问git中的散列冲突

EN

如果两个文件在git中有相同的散列和，它会将这两个文件视为相同。在这种绝对不可能发生的情况下，你总是可以返回一次提交，并在文件中更改一些东西，这样它们就不会再发生冲突了……

参见Linus Torvalds' post in the thread “Starting to think about sha-256?” in the git mailing list。

在不解释为什么它不是问题的情况下，用正确的“但是”来回答这个问题是不可能的。如果不能很好地掌握哈希的真正含义，就不可能做到这一点。它比您可能在CS程序中接触到的简单情况要复杂得多。

这里有一个对信息论的基本误解。如果您通过丢弃一些量(即，散列)将存在与数据长度直接相关的冲突的机会。数据越短，发生这种情况的可能性越小。现在，绝大多数冲突将是胡言乱语，使得它们更有可能实际发生(您永远不会在gibberish...even中检入二进制映像是某种结构化的)。最终，这种可能性微乎其微。为了回答你的问题，是的，git会将它们视为相同的，改变散列算法不会有什么帮助，它将采取某种形式的“第二次检查”，但最终，你将需要与数据长度一样多的“额外检查”数据以100% sure...keep记住你将99.99999....to一个非常长的位数……当然，就像你描述的那样，只需简单的检查即可。SHA-x是加密的强散列，这意味着通常不难故意创建两个彼此非常相似的源数据集，并且具有相同的散列。数据中的一个比特变化应该在哈希输出中产生不止一个比特的变化(最好是尽可能多的)，这也意味着从哈希到整个冲突集的恢复非常困难(但也不是完全不可能)，从而从这组冲突中提取出原始消息-除了少数几个之外，所有这些都是胡言乱语，而在那些没有胡言乱语的情况下，如果消息长度是任何重要长度，仍然有大量的数据需要筛选。加密散列的缺点是它们对一般的compute...in很慢。

那么，这一切对Git意味着什么呢？不是很多。哈希很少被完成(相对于其他任何东西)，以至于它们的计算代价总体上对操作来说很低。命中一对碰撞的机会是如此之低，这不是一个现实的机会发生而不是立即被检测到(即。您的代码很可能会突然停止构建)，允许用户修复问题(备份修订，并再次进行更改，您几乎肯定会得到一个不同的哈希，因为时间更改，这也提供了git中的哈希)。如果你在git中存储任意二进制文件，这对你来说更有可能是一个真正的问题，这并不是它的主要使用模型。如果你想这样做……你最好使用传统的数据库。

思考这一点并没有错--这是一个很好的问题，很多人只是冒充“不太可能，所以不值得考虑”--但它实际上要比这复杂一点。如果它真的发生了，它应该很容易被检测到，它不会是正常工作流程中的无声损坏。

谷歌现在声称，在某些前提条件下，SHA-1碰撞是可能的：https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

由于git使用SHA-1来检查文件完整性，这意味着git中的文件完整性受到了损害。

当然，git应该使用更好的散列算法，因为现在有可能发生故意的冲突。