为什么Git不使用更现代化的SHA?

我读过关于Git使用SHA-1摘要作为修订的ID。 为什么不使用更现代版本的SHA?

更新 :上面的问题和这个答案是从2015年。从那时起,谷歌已经宣布了第一个SHA-1碰撞: https : //security.googleblog.com/2017/02/announcing-first-sha1-collision.html


显然,我只能从外部推测Git继续使用SHA-1的原因,但这可能是以下原因之一:

  1. Git是Linus Torvald的创作,Linus显然不想用另一个散列algorithm替代SHA-1。
  2. 他给出了合理的说法:成功的基于SHA-1碰撞的Git攻击要比实现碰撞要困难得多,并且考虑到SHA-1比它应该是脆弱的,没有完全破坏,这使得它远离至less今天是可行的攻击。 此外,他还指出,如果碰撞物体比现有物体晚到达,那么“成功”的攻击就会达到很less,因为稍后的碰撞会被假定为与有效碰撞相同并被忽略(尽pipe其他人指出相反可能会发生)。
  3. 更改软件非常耗时且容易出错,特别是当现有基础架构和基于现有协议的数据需要迁移时。 即使那些生产以密码安全为系统唯一点的软硬件产品的厂商,仍然处于从SHA-1等弱点algorithm转移的过程中。 试想一下,所有那些硬编码的unsigned char[20]缓冲区遍布整个地方;对于一开始就对密码敏捷性进行编程,而不是稍后对其进行改进就容易多了。
  4. SHA-1的性能要好于各种SHA-2散列(现在可能不是那么简单,但可能是十年前的一个难题),SHA-2的存储容量更大。

一些链接:

  • Stackoverflow的问题,如果在Git发生碰撞,会发生什么
  • 新闻组的post在2005年主要的SHA-1弱点出现之后的几个月里显示了Linus对这个问题的简短评论
  • 一个讨论2006年Sha-256(来自Linus的回复)的弱点和可能的举措
  • NIST关于SHA-1弃用声明,并build议“快速转换到更强大的SHA-2哈希函数族”

我个人的观点是,虽然实际的攻击可能是暂时的,甚至当它们发生的时候,人们可能会首先通过除了改变哈希algorithm本身之外的手段来减轻攻击,如果你关心安全性,你应该犯错误在谨慎selectalgorithm的同时,不断修正你的安全优势,因为攻击者的能力也只朝着一个方向发展,所以以Git为榜样是不明智的。使用SHA-1并不意味着encryption安全性。

这是讨论从Mercurial迁移到SHA1的紧迫性,但它也适用于Git: https : //www.mercurial-scm.org/wiki/mpm/SHA1

简而言之:如果你今天不是非常吝啬的话,那么你的漏洞比sha1要糟糕得多。 但是,尽pipe如此,十多年前Mercurial已经开始准备从sha1迁移出去。

多年来一直在努力改进Mercurial公司SHA1接class人的数据结构和协议。 在Mercurial 0.9中引入了RevlogNG,在10年前我们的revlog结构中为存储空间分配了更大的哈希值。 最近推出的bundle2格式支持在networking上交换不同的散列types。 唯一剩下的部分是selectreplacefunction并select向后兼容性策略。

如果在Mercurial之前git没有从sha1迁移出来,那么通过使用hg-git保留一个本地的Mercurial镜像,你总是可以增加另一个级别的安全性。