为什么Git使用加密哈希函数？

为什么Git使用SHA-1（加密哈希函数）而不是更快的非加密哈希函数？

相关问题：

堆栈溢出问题为什么Git会使用SHA-1作为版本号？询问为什么Git使用SHA-1而不是顺序号进行提交。

TLDR；

• 从2005年到2018年/ Git 2.18：SHA-1（如下所示）
• 2019年，将在某些时候切换到SHA-256

您可以从Linus Torvalds本人那里检查到这一点，当他在2007年向Google展示Git时：（
重点是我的）

我们检查被认为是加密安全的校验和。没有人能够破解SHA-1，但要点是，就git而言，SHA-1甚至不是安全功能。纯粹是一致性检查。
安全部件在其他地方。许多人认为，因为git使用SHA-1，并且SHA-1用于加密安全的东西，所以他们认为这是一个巨大的安全功能。它与安全性完全无关，它只是您可以获得的最佳哈希。

拥有一个良好的哈希表可以信任您的数据，它也具有其他一些良好的功能，这意味着当我们哈希对象时，我们知道哈希表是分布良好的，我们不必担心某些分布问题。

从内部的角度来看，这意味着从实现的角度来看，我们可以相信哈希表是如此的好，以至于我们可以使用哈希算法，并且知道没有不良情况。

因此，也有一些理由也喜欢加密方面，但这实际上与信任数据的能力有关。
我向您保证，如果将数据放入git中，您可以相信，五年后，将其从硬盘转换为DVD并转换为新技术并复制后，五年后您可以验证数据取出的数据与您输入的数据完全相同。这是您真正应该在源代码管理系统中寻找的东西。

2017年12月使用Git 2.16更新（2018年第一季度）：支持替代SHA的工作正在进行中：请参阅“ 为什么Git不使用更现代的SHA？ ”。

我在“ git如何处理blob上的SHA-1冲突？ ”中提到，您可以设计具有特定SHA1 前缀的提交（仍然是一项非常昂贵的工作）。
但是问题仍然存在，正如Eric Sink在“ Git：加密散列 ” （2011年示例控制版本）中所提到的：

DVCS永远不会遇到具有相同摘要的两个不同数据段，这一点非常重要。幸运的是，良好的加密哈希函数旨在使这种冲突极不可能发生。

除非您考虑进行“ 使用遗传编程来查找最新的非密码哈希 ”之类的研究，否则很难找到具有低冲突率的良好非密码哈希。

您还可以阅读“ 考虑使用非加密哈希算法来提高哈希速度 ”，例如，提到了“ xxhash ”，这是一种非常快的非加密哈希算法，其工作速度接近RAM限制。

关于在Git中更改哈希的讨论并不新鲜：

• 要么对其进行优化（2009年8月），但您必须考虑许可证问题：

（Linus Torvalds）

Mozilla代码实际上并没有剩余，但是，嘿，我从它开始。回想起来，我可能应该从已经疯狂地进行了阻止的PPC asm代码开始-但这是“ 20/20后见之明”的事情。

另外，mozilla代码令人毛骨悚然，这就是为什么我如此坚信可以改进的地方。所以这是它的一种来源，即使它更多是关于动机方面而不是任何实际剩余的代码;）

您需要注意如何衡量实际的优化增益

（Linus Torvalds）

我几乎可以向您保证，它会有所改善，仅是因为它使gcc生成废话代码，然后隐藏了一些P4问题。

• 或将其完全更改（2010年1月）
  （例如更改为SHA-3，但这将适用于任何其他哈希）：

（约翰·塔普塞尔- johnflux）

将git从SHA-1升级到新算法的工程成本要高得多。我不确定该如何做好。

首先，我们可能需要部署一个版本的git（在本次对话中，我们将其称为版本2），即使它没有读取或使用该空间，也允许有一个用于存储新哈希值的插槽。另一个插槽中的SHA-1哈希值。

这样，一旦我们最终部署了git的较新版本，我们将其称为版本3，除了SHA-1哈希生成SHA-3哈希之外，使用git版本2的人们将能够继续进行互操作。
（尽管，根据此讨论，它们可能很脆弱，并且仅依赖其SHA-1补丁的人可能很脆弱。）

简而言之，切换到任何哈希都不容易。

2017年2月更新：是的，理论上可以计算出冲突的SHA1：shattered.io

GIT如何受到影响？

GIT强烈依赖SHA-1进行所有文件对象和提交的标识和完整性检查。
基本上可以创建两个GIT存储库，它们具有相同的head commit哈希和不同的内容，例如良性的源代码和后门的。
攻击者可能有选择地将任一存储库提供给目标用户。这将要求攻击者计算自己的碰撞。

但：

此攻击需要超过9,223,372,036,854,775,808个SHA1计算。这相当于6500年的单CPU计算能力和110年的单GPU计算能力。

因此，我们暂时不要惊慌。
请参阅“ Git如何处理Blob上的SHA-1冲突？ ”。