强大的加密哈希使冲突不太可能发生。许多加密协议都建立在这一事实之上。但是 Git 使用SHA-1哈希作为对象标识符。因此，在 Web 的公共 Git 存储库中有很多已经计算好的哈希值，以及如何重现它们的详细信息。
是否有一些已知的攻击可能会被利用的某些协议？类似“好吧，如果我将这个未知的纯文本替换为具有相同 SHA-1 哈希值的其他纯文本，我会做一些邪恶的事情，所以我不会计算冲突，而是用谷歌搜索它。” 当然，Git 提交还远远没有覆盖所有哈希的空间，但是，我猜所有的 Git 提交可能相当于计算 SHA-1 哈希的相当多的 CPU 小时。不过，我不确定这种猜测是否合理。
据我所知，这种攻击只有在散列可见的情况下才有效，生成它的纯文本不可见，但生成的一些密码文本是可见的，并且也可以加密不同的文本。所以这看起来可能适用于一些基于公钥的协议，您可以在其中加密但不能解密。此外，您无法控制冲突的纯文本，因此将您自己的名字作为某些金融交易的受益人之类的显而易见的事情是行不通的。在任何情况下，这样的众包哈希冲突可能会以不可忽略的概率造成严重问题吗？
Git 是否众包 SHA-1 原像的生产？没有任何有意义的程度。
Github 没有说明它跟踪了多少次提交，但可能不会超过几十亿。作为比较，有 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976 个可能的 SHA-1 哈希，因此找到与任意感兴趣的哈希匹配的明文的可能性实际上是不存在的。
您可以从小的任意文本中计算自己的 SHA1 哈希值，而不是收集其他人计算的哈希值。但是有很多可能的 SHA1 摘要，大约和世界上的原子一样多。如果您想保留所有已知摘要的列表并搜索该列表，这说明了挑战。
计算 Git 中发现的每个 SHA-1 哈希值所付出的人力是巨大的。这意味着以这种方式计算的哈希数量是相当有限的。
如果你想找到冲突，你需要每个散列零人力，并且在每个散列上花费很少的计算机时间。
比特币可能是唯一具有足够计算能力来执行通过蛮力找到 SHA-1 冲突所需的 2^80 次加密操作的系统。尽管大部分计算能力是专用硬件，只能执行SHA-2，并且不能重新用于计算 SHA-1 哈希。
它仍然提供了这种蛮力攻击所需的部署规模的概念。比特币已经证明 2^80 次加密操作是可行的。仅出于这个原因，我们应该尽快转向比 SHA-1 更强的哈希。
如果比特币是基于 SHA-1 的，那么冲突就已经发生了。这将是通过蛮力甚至没有利用 SHA-1 的任何弱点。那是因为比特币几乎什么都不做，只是一直在计算哈希，而且它有专门的硬件来做这件事。
比特币中使用的实际哈希函数具有比 SHA-1 更大的输出，因此很可能没有发生冲突。此外，它需要不同的设计才能确定是否发生了冲突，因为今天存在的比特币会立即丢弃大部分哈希值，因此即使发生了冲突，我们也不会知道它。