为什么Git使用密码散列函数？
为什么Git使用encryption散列函数SHA-1而不是更快的非encryption散列函数？
相关问题：
堆栈溢出问题为什么Git使用SHA-1作为版本号？ 问为什么Git使用SHA-1而不是序列号进行提交。
你可以从Linus Torvalds自己那里得知，当他在2007年向Git提交Git的时候 ：
（重点是我的）
我们检查被认为是密码安全的校验和。 没有人能够打破SHA-1，但重要的是， 就git而言，SHA-1甚至不是安全function。 这纯粹是一致性检查 。
安全部分在别处。 很多人都认为git使用SHA-1和SHA-1是用于encryption安全的东西，他们认为这是一个巨大的安全function。 它与安全没有任何关系，只是你能得到的最好的哈希值。拥有一个好的散列对于能够信任你的数据是有好处的 ，它恰巧也有其他一些好的特性，这意味着当我们散列对象的时候，我们知道散列分布很好，我们不必担心某些分布问题。
从内部来说，从实现的angular度来看，我们可以相信散列非常好，我们可以使用散列algorithm，并且知道没有坏的情况。
所以也有一些理由喜欢密码方面的，但是它确实是关于信任你的数据的能力。
我保证，如果你把你的数据放在git中，你可以相信五年之后，在它从硬盘转换到DVD到任何新的技术被转换之后， 五年后你可以validation你的数据退出是与您input的数据完全相同。这是您在源代码pipe理系统中真正应该查找的内容 。
我在“ 如何处理blob上的SHA-1冲突？ ”中提到，您可以使用特定的SHA1 前缀 （仍然是一个非常昂贵的努力）devise提交。
但是问题仍然存在，正如Eric Sink在“ Git：Cryptographic Hashes ”中提到的（ 版本控制示例（2011）） ：
DVCS从来不会遇到具有相同摘要的两个不同的数据段是相当重要的。 幸运的是，好的encryption散列函数被devise成使这种冲突极不可能。
除非你考虑诸如“ 用遗传规划发现最先进的非密码哈希 ”这样的研究，否则很难find低冲突率的非密码散列 。
您也可以阅读“ 考虑使用非encryption哈希algorithm来加速哈希 ”，其中提到了例如“ xxhash ”，一种非常快速的非encryption哈希algorithm，其工作速度接近RAM限制。
有关在Git中更改散列的讨论并不新鲜：
- 要么优化它（2009年8月） ，但你必须采取许可证问题：
（Linus Torvalds）
mozilla代码没有任何其他的东西，但是，嘿，我从它开始。 回想起来，我可能应该已经从PPC asm代码开始，已经做到了这一点，但这是一个“20/20事后”的东西。
另外，嘿，mozilla代码是一堆可怕的东西，这就是为什么我确信我可以改进的地方。 所以这就是它的一个来源，即使它比任何实际剩余的代码更关心动机方面;）
而且您需要小心如何衡量实际的优化增益
（Linus Torvalds）
我几乎可以保证，它只是因为它使gcc生成废话代码，然后隐藏一些P4问题，它改善了事情。
- 或者完全改变它（2010年1月）
（例如到SHA-3，但这将适用于其他散列）：
（John Tapsell – johnflux ）
将git从SHA-1升级到新algorithm的工程成本要高得多 。 我不确定如何做得好。
首先，我们可能需要部署一个版本的git（让我们称之为版本2的这个对话），它允许有一个新的哈希值插槽，即使它不读取或使用该空间 – 它只是使用另一个时隙中的SHA-1哈希值。
这样，一旦我们最终部署了一个更新版本的git，让我们称之为版本3，除了SHA-1散列之外，它还产生SHA-3散列，使用git版本2的人们将能够继续互操作。
（虽然根据这个讨论，他们可能是脆弱的，而依赖SHA-1补丁的人可能会受到攻击。）
总之，切换到任何哈希是不容易的。
2017年2月更新：是的，理论上可以计算一个冲突SHA1： shattered.io
GIT如何影响？
GIT强烈依靠SHA-1来识别和完整性检查所有文件对象和提交。
实际上有可能创build两个具有相同头提交散列和不同内容的GIT存储库，比如一个良性的源代码和一个后端的代码。
攻击者可能有select性地向目标用户提供存储库。 这将要求攻击者计算他们自己的碰撞。
但：
这次攻击需要9,223,372,036,854,775,808 SHA1计算。 这个处理能力相当于6,500年的单CPU计算和110年的单GPU计算。
所以，让我们不要恐慌。
请参阅“ Git如何处理blob上的SHA-1冲突？ ”。
