2 回答
TA贡献1827条经验 获得超9个赞
简短(但不令人满意)的答案是,示例文件对于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步骤失败。在任何情况下,您都无法将这两个文件添加到单个存储库中。
但首先,有人必须花费更多的时间和金钱来计算新的哈希冲突。
- 2 回答
- 0 关注
- 443 浏览
添加回答
举报