我刚刚在阅读有关 SSL/TLS 的内容，根据这个网站（Qualys SSL Labs 将其评为 A），MD5 完全被破坏，SHA-1 自 2005 年以来在密码学上很弱。然而，我注意到很多程序员甚至微软只给我们 SHA-1/MD5 来检查文件的完整性......
据我所知，如果我更改文件的某个位，他们的 MD5/SHA-1 会改变，那么为什么/如何损坏它们？在哪些情况下我仍然可以信任使用 SHA-1/MD5 生成的校验和？像 google.com 这样仍然使用 SHA-1 的 SSL 证书呢？
我对 MD5 和 SHA-1 用于校验和和证书验证的应用感兴趣。我不是在询问密码散列，这已在这个问题中得到处理。
SHA-1 和 MD5 被破坏是因为它们容易受到碰撞攻击。也就是说，找到两个具有相同散列的字符串已经成为现实（或者，对于 SHA-1，将很快成为现实）。
正如这里所解释的，冲突攻击不会直接影响密码或文件完整性，因为它们分别属于原像和第二原像情况。
但是，MD5 和 SHA-1 的计算成本仍然较低。使用这些算法散列的密码比目前存在的更强大的算法更容易破解。虽然没有特别破坏，但建议使用更强大的算法。
在证书的情况下，签名表明特定证书的哈希对特定网站有效。但是，如果您可以使用该哈希制作第二个证书，您就可以冒充其他网站。在 MD5 的情况下，这已经发生了，浏览器将尽快淘汰 SHA-1 作为预防措施（来源）。
文件完整性检查通常旨在确保正确下载文件。但是，如果它被用于验证文件没有被恶意篡改，您应该考虑一种对冲突更具弹性的算法（另请参见：选择前缀攻击）。
对于 MD5，没有一个有信誉又有能力的人会在抗碰撞性很重要的环境中使用它。对于 SHA-1，它正在被逐步淘汰；SHA-1 中断在发布时并不实用，直到现在才考虑在需要抗碰撞性的地方逐步淘汰它变得很重要。事实上，它正在被淘汰；例如，带有 SHA-1 的长期 TLS 证书不再在 Chrome 中工作，以促使人们更改为 SHA-2。但是，它实际上还没有被破坏，所以现在可以接受。
之所以没有立即放弃所有内容，是因为安全性涉及权衡。您不会因为可能在十年内导致实际攻击的原因而放弃主要标准并使所有内容与庞大的安装基础不兼容。兼容性很重要。
此外，对于许多用途，MD5 和 SHA-1 根本没有破解。它们都有抗碰撞性的弱点，这意味着攻击者可以创建两条散列到同一事物的消息。既不能抵抗原像抵抗（给定哈希，找到产生该哈希的东西），也不能抵抗第二原像抵抗（给定消息，找到具有相同哈希的不同消息），或（它们的压缩函数）作为伪随机职能。这意味着像 HMAC-MD5 这样的结构仍然是安全的，因为它不依赖于被破坏的 MD5 的属性。当然，不太理想，但请参阅上面的“如果它仍然安全，兼容性很重要”。
无论如何，通过散列检查文件完整性几乎总是毫无意义的；除非散列是通过比文件更安全的通道发送的，否则您可以像篡改文件一样容易地篡改散列。但是，如果散列的发送比文件更安全，MD5 和 SHA-1 仍然能够保护文件完整性。因为攻击者对合法文件没有任何影响（并且需要零影响才能真正安全），所以创建具有相同哈希值的新文件需要破坏第二个原像抗性，而没有人对 MD5 或SHA-1。
请注意完整性检查和证书之间的区别。证书由 CA 从用户创建的 CSR 颁发；攻击者可以对实际的证书内容产生巨大的影响，因此碰撞攻击允许攻击者创建一个合法的和一个虚假的证书碰撞，获得合法的证书，并在伪造的证书上使用签名。相比之下，在文件完整性方面，攻击者通常对合法文件的控制为零，因此需要与给定文件发生冲突，这要困难得多（据我们所知，这不能用 MD5 完成）。
MD5 和 SHA-1速度很快，并且可能在硬件中得到支持，与更新、更安全的哈希相比（尽管比特币可能通过使用 SHA-2 改变了这一点，因为它产生了计算部分 SHA-2 冲突的挖矿芯片）。
MD5碰撞是可行的，原像攻击已经取得进展；官方的全轮算法存在一个众所周知 的 SHA-1 冲突，在其他攻击显着降低其有效复杂度之后，这对于临时攻击者可能还不够实用，但在可能性的范围内，这就是为什么它可以叫破。
尽管如此，“弱”或损坏的哈希仍然适用于不需要加密安全算法的用途，但许多最初被认为不重要的用途后来可能会暴露潜在的攻击面。
很好的例子是查找重复文件或在 git 等版本控制系统中使用 - 在大多数情况下，您想要具有高可靠性的良好性能，但不需要严格的安全性 - 授予某人对官方 git 存储库的写访问权限已经需要您信任其他人人们不要乱来，重复检查应该在发现两个文件具有相同的大小和哈希值后额外比较内容。
使用事实（例如逐字节比较）来充分备份不安全的散列可能是一种风险，例如，当像 Dropbox 这样的人在没有适当验证的情况下使用 MD5 进行重复数据删除，并且攻击者潜入具有冲突散列的数据以导致数据丢失时。
正如 Linus 自己所说，git 通过“信任长者”来解决这个问题：
如果您在 git 中已经有一个带有哈希 X 的文件 A，是否存在带有哈希 X（但内容不同）的远程文件会覆盖本地版本的任何情况？
不。如果它具有相同的SHA1，则意味着当我们从另一端接收到对象时，我们不会覆盖我们已经拥有的对象。
所以发生的情况是，如果我们看到冲突，任何特定存储库中的“早期”对象总是会被覆盖。但请注意，“较早”显然是每个存储库的，因为 git 对象网络生成一个未完全排序的 DAG，因此虽然不同的存储库会就直接祖先的情况下的“较早”达成一致，如果对象来自单独且不直接相关的分支，两个不同的存储库显然可能以不同的顺序获得了这两个对象。
但是，从安全的角度来看，“早期将覆盖”是您非常想要的：请记住，git 模型是您应该主要只信任自己的存储库。因此，如果您执行“git pull”，则根据定义，新传入对象的可信度低于您已有的对象，因此允许新对象替换旧对象是错误的。
[原文出处：https://marc.info/?l=git&m=115678778717621&w=2]
正如他们所说，磁盘故障比意外哈希冲突更有可能发生（几个数量级 - SHA-1 冲突 < 10 -40；磁盘不可恢复位错误 ~ 10 -15）。
虽然可能存在冲突，但在 MD5 和 SHA1 都存在时检查文件的完整性不太可能发生冲突。因此，如果这两个简单的检查都验证了同一个文件，那就足够了。无论如何，在大多数情况下，我几乎看不到人们验证其中一个。