Git 3.0 即将推出的 SHA-256 默认值将是一个代价高昂的错误

从哪里开始？我已经在这件事上坐了几年了，主要是因为有更聪明的人一直专注于这件事，而我不喜欢当后座司机。然而，我认为 Git 3.0 的发布将花费每个人大量的时间和焦虑，但几乎没有什么好处，而且几乎没有人知道会发生什么。因此，请拿点爆米花，让我告诉您一个故事，即将到来的 Git 3.0 重大更改之一将如何成为一场巨大的、成本高昂的、几乎没有实际价值的全球火车残骸。我将保持简短，因为你们中的许多人可能都知道这一点。 Git 是所谓的内容可寻址数据库。这意味着如果你想在其中存储和传输数据，Git 将计算内容的哈希值并将其用作键/值数据库中的键（值就是内容）。在全球范围内，相同的内容始终获得相同的哈希值。 Git 使用 SHA-1 哈希作为其键值对象数据库中的键，这很好，因为这意味着相同的文件内容永远不会存储两次。还有一个很酷的属性，其中提交对之前提交的哈希值进行编码，这意味着这种完整性本质上是传播的 - 如果不更改其之后的所有内容的哈希值，则无法更改任何内容的哈希值。这赋予了它“加密完整性”，这意味着对最新提交进行哈希处理本质上也会对之前的数百万个文件内容、树和提交进行哈希处理。在 Git 中，这个哈希函数一直是 SHA-1。这是 Linus 在 2005 年 Git 启动时所选择的，并且在 20 年来一直运行良好 - 它相对较快，并且在实际意义上两个不同的文件不可能意外地散列到相同的值。事实上，据我所知，在 Git 中创建的每个存储库（数十亿个）中的每个文件、树和提交的历史上从未发生过这种情况。从数学上讲，对于 SHA-1 的 160 位输出，生日限制意味着在单个项目中需要大约 1.4 个七万亿个随机文件（1.4 个万亿个文件 - 1,400,000,000,000,000 亿个 - 无法有效描述），才能使文件哈希意外发生冲突。但存在一个问题，即从数学角度来看，SHA-1 现在被认为是半“损坏”的，因为已经发布了碰撞攻击（2017 年为 SHAttered，SHA-1 在 2020 年为 Shambles）——以任何演示的方式利用都不太实际，但现在理论上是可能的。因此，针对这一点，经过非常聪明的人的大量工作，即将发布的 Git 3.0 版本计划将其默认哈希算法从半“损坏”的 SHA-1 更改为更强的 SHA-256 算法。但首先，让我们暂停一下。在我们深入探讨这个问题之前，我们先来了解一下“破碎”是什么意思？理解这一点很重要，因为这可能不是普通人认为的“破碎”的意思。从加密哈希的角度来看，从这个意义上讲，破解本质上意味着发现冲突并非不可能。换句话说，如果你投入足够的资金和 GPU 来解决这个问题，对于某些内容形状，你可以故意想出两种不同的东西，它们散列到完全相同的值。损坏的 SHA-lor 能做什么？早在明天...这意味着虽然仍然几乎不可能意外地拥有两个具有不同内容的合理文件，但从技术上来说，制造两个散列到同一事物的不同文件并非不可能。这意味着理论上存在攻击向量，某人可以用恶意版本替换一个文件的内容，而 Git 无法区分差异，因为哈希值在数学上是相同的。这些论文表明，SHA-1 具有一种属性，理论上可以被现代 GPU 群利用来产生 SHA-256 所不具备的有目的的碰撞，其金额约为数万美元（如果您超级关心的话，请谷歌“线性消息调度 sha-1 与 sha-256”...）。听起来真的很可怕和令人担忧，对吧？难道就没有人想一下孩子们吗？！嗯，不是真的。但让我们花一分钟时间退一步讨论这些碰撞。当你考虑对哈希函数进行攻击时，哈希函数有两个主要问题（假设我必须大规模地、愚蠢地简化事情）。一种是“碰撞攻击”，另一种是“第二原像攻击”。 “碰撞攻击”是指您知道自己将成为攻击者，但假装是好人，直到获得信任。您故意生成两个具有相同哈希值的文件 - 一个是良性的，另一个是恶意的。你给人们良性的，直到你被信任为止，然后用恶意的哈希交换它，因为哈希值匹配，并且你知道 Git 无法区分。您甚至可以在具有良性文件的树上获取签名标签或提交，并使其看起来像是对坏文件进行了签名。 “第二原像攻击”是指当您看到要替换的文件，然后创建第二个文件时