新发现的SHA-1碰撞如何影响Git？

Question

最近,一组研究人员使用相同的SHA-1哈希生成了两个文件(https://shattered.it/).

由于Git将此哈希用于其内部存储,这种攻击在多大程度上会影响Git？

Answer 1

编辑,2017年12月下旬:Git 2.16版正在逐步获取内部接口以允许不同的哈希值.还有很长的路要走.

简短(但不令人满意)的答案是,示例文件对于Git来说不是问题 - 但是其他两个(精心计算的)文件可能是.

我下载这两个文件,shattered-1.pdf并shattered-2.pdf,并把它们放入一个新的空库:

macbook$ shasum shattered-*
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf
macbook$ cmp shattered-*
shattered-1.pdf shattered-2.pdf differ: char 193, line 8
macbook$ git init
Initialized empty Git repository in .../tmp/.git/
macbook$ git add shattered-1.pdf 
macbook$ git add shattered-2.pdf 
macbook$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

    new file:   shattered-1.pdf
    new file:   shattered-2.pdf

即使这两个文件具有相同的SHA-1校验和(并且显示大多数相同,但是一个具有红色背景而另一个具有蓝色背景),它们会得到不同的Git哈希值:

macbook$ git ls-files --stage
100644 ba9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0 0   shattered-1.pdf
100644 b621eeccd5c7edac9b7dcba35a8d5afd075e24f2 0   shattered-2.pdf

这些是存储在Git中的文件的两个SHA-1校验和:一个是ba9aa...,另一个是b621e....也不是38762c....但是 - 为什么？

答案是Git存储文件,而不是它们自己,而是作为字符串文字blob,空白,十进制文件的大小,ASCII NUL字节,然后是文件数据.两个文件的大小完全相同:

macbook$ ls -l shattered-?.pdf
...  422435 Feb 24 00:55 shattered-1.pdf
...  422435 Feb 24 00:55 shattered-2.pdf

因此两者都以文字文本为前缀blob 422435\0(其中\0表示单个字节,字符串中的la C或Python八进制转义).

也许令人惊讶 - 或者不是,如果您知道SHA-1的计算方法 - 将相同的前缀添加到两个不同的文件中,但之前生成相同的校验和,导致它们现在产生不同的校验和.

这应该变得不足为奇的原因是,如果最终的校验和结果对每个输入位的位置和值都不是非常敏感,那么通过获取已知的输入文件并且仅仅重新按需产生冲突将是很容易的. - 安排一些比特.这两个输入文件产生相同的总和,尽管有不同的字节,但研究人员通过尝试超过9个quintillion(短程)输入实现了这个结果.为了得到这个结果,他们在他们控制的位置放入精心选择的原始数据块,这将影响总和,直到他们找到导致碰撞的输入对.char 193, line 8

通过添加blob标题,Git 移动了位置,在一次或多或少的意外打击中摧毁了110-GPU年的计算.

现在,知道Git会这样做,他们可以用输入开始重复他们的110-GPU年的计算blob 422435\0(假设他们的牺牲块不会被推得太多;并且需要GPU的实际计算年数可能会有所不同,因为这个过程有点随机).然后他们会提出两个不同的文件,可能会blob删除标题.这两个文件现在彼此具有不同的SHA-1校验和,但是当git add-ed时,两者都会产生相同的 SHA-1校验和.

在该特定情况下,添加的第一个文件将"赢"该插槽.(让我们假设它的名字shattered-3.pdf.)一个足够好的Git - 我完全不确定当前的Git是否合适; 请参阅Ruben基于实验的答案,了解Git如何处理blob上的SHA-1碰撞？- 会注意到git add shattered-4.pdf,尝试添加第二个文件,与第一个但不同的文件发生冲突,shattered-3.pdf并会警告您并使git add步骤失败.在任何情况下,您都无法将这两个文件添加到单个存储库中.

但首先,有人必须花费更多的时间和金钱来计算新的哈希冲突.

Answer 2

也许Linus的回应可能会有所启发:

IIRC有人一直致力于参数化git的SHA1假设,因此存储库最终可以使用更安全的哈希.到底有多远？在git.git HEAD中仍有许多"40"常量.

我认为你不一定要改变哈希的大小.您可以使用不同的哈希,并使用相同的160位.

由于我们现在在有效的PDF文件中发生冲突,因此可能构造有效git提交和树对象中的冲突.

我还没有看到攻击,但是git实际上并不只是对数据进行散列,它会为它添加一个类型/长度字段.这通常会使碰撞攻击变得更加困难,因为您必须使结果大小相同,或者您还必须能够编辑标题中的大小字段.

pdf没有这个问题,他们有一个固定的标题,你可以相当随意地将静默数据添加到中间,但没有显示.

因此,pdf可以提供更好的攻击向量,因为它们是一种相当不透明的数据格式.Git在某些地方有不透明的数据(例如,我们故意隐藏提交对象中的内容,但根据定义,不透明数据是相当次要的.

换句话说:我怀疑git作为源控制管理工具的天空正在下降.我们想要迁移到另一个哈希吗？是.像人们想说的那样,SHA1的游戏结束了吗？可能不是.

我没有看到攻击细节,但我打赌

(a)我们有一个单独的大小编码这一事实使得首先对git对象进行操作变得更加困难

(b)我们可以轻松地对我们所拥有的不透明数据添加一些额外的健全性检查,以使隐藏随机数据变得更加困难,这些攻击几乎总是依赖于这些数据.

莱纳斯

资料来源:https://marc.info/？l = git&m = 148787047422954