开发者工具 · SHA 哈希计算器
SHA-1 碰撞解释：什么仍然安全，什么必须迁移
· 为什么它很重要
sha-256 密码学 安全
扫描仪标记 SHA-1，管理层询问其紧急程度。这篇文章解释了碰撞攻击会破坏什么、不会破坏什么、SHA-1 仍然可以容忍的情况，以及如何规划迁移。
扫描仪显示 SHA-1 已损坏 - 但损坏的原因是什么？决定迁移紧迫性的问题
网络安全扫描器在您的基础设施上标记 SHA-1。管理层询问事情有多紧急。答案完全取决于您使用 SHA-1 的目的，该问题揭示了您是否存在合规性问题、活跃的安全问题，或者仅仅是必须编目的遗留工件。 SHA-1 的密码已被破坏——学术演示已证明存在冲突。但“损坏”的含义不同，具体取决于 SHA-1 在系统中扮演的角色。
加密哈希在不同的上下文中具有不同的用途。有时它是防止意外损坏的校验和。有时它是一种承诺，例如发布的下载校验和，让用户验证他们收到了发布者想要的文件。有时它是签名或证书链的一部分，拥有足够控制权的攻击者可以生成两个有意义的文档，它们共享相同的哈希值，从而伪造身份验证。 SHA-1 冲突的严重性主要取决于 SHA-1 在您的系统中所扮演的角色。
碰撞与原像 — 为什么公开演示的攻击目标是碰撞，以及这对现有哈希意味着什么
碰撞攻击会产生两个不同的输入和相同的输出。攻击者找不到散列到预定值的消息，这将是原像攻击，并且对于 SHA-1 来说仍然不可行。相反，冲突攻击意味着攻击者可以创建两个哈希值相同的文档。如果系统依赖哈希来证明两件事是相同的，那么冲突就会破坏该证明。攻击者必须制作两个输入，这需要时间和计算，但结果是在哈希下出现相同的两个不同的东西。
原像攻击意味着攻击者可以获取已发布的 SHA-1 哈希并找到一些与其匹配的输入。这不是 SHA-1 攻击的工作原理。如果您有 SHA-1 摘要存储库并担心文件是否真正匹配它们，则冲突攻击不是威胁。威胁在于有权访问您的存储库的人是否可以将不同的文件伪造为同一摘要。在大多数情况下，如果不控制哈希过程本身，这也是不现实的。具体的攻击模型与算法一样重要。
2017 演示 — 具有相同 SHA-1 的两个不同文件，定性描述，以及随后选择的前缀工作
来自 2017 的 SHattered 攻击演示了实际冲突：两个不同的 PDF 文件具有相同的 SHA-1 摘要。研究人员仔细构建了这两个文件，在碰撞时将它们制作成有效的 PDF。这项工作需要大量的计算工作和专用硬件。重要的是它完全是可能的：证明使用 SHA-1 来保证安全性的抗碰撞性已经消失了。这次攻击证明两个语义不同的文档可以共享一个摘要，这会破坏任何信任摘要作为身份证明的系统。
2020 中的攻击称为“SHA-1 is a Shambles”，它采取了下一步：选择前缀冲突。这种变体意味着攻击者可以获取两个任意文档，将不同的后缀连接到每个文档，并产生冲突。这是针对签名和证书的危险攻击。攻击者不必从头开始；它们可能会碰撞两个有意义的、不同的文档。这破坏了任何签署 SHA-1 摘要的系统的安全模型。攻击者可以生成两个散列相同但含义不同的文档。
其中 SHA-1 是不可接受的 — 签名、证书以及攻击者可以影响双方的任何内容
这种区别很重要，因为 SHA-1 在某些角色中仍然可以容忍，但在其他角色中绝对不可接受。在 Git 中，SHA-1 用作内容地址——特定文件快照的名称。 Git 不使用 SHA-1 进行身份验证；这是一个命名方案。理论上，攻击者可以使用相同的 ID 计算两个不同的存储库状态，但这需要控制整个内容创建过程并在任何人注意到之前推送两个版本。对于大多数团队来说，攻击者控制级别并不是威胁模型。这就是为什么 Git 有意过渡到 SHA-256 而不是将其视为紧急情况。
在网络下载验证场景中，发布者在同一服务器上发布文件及其 SHA-1 校验和。破坏该服务器的攻击者可以控制文件和校验和。他们可以上传文件并发布其 SHA-1，并且不需要冲突。如果校验和发布在其他地方（在安全 VPN 上、打印在签名电子邮件中、发布在不同的基础设施中），那么攻击者必须发生冲突，而这是不可行的。校验和的可信度取决于其通道。这就是为什么下载验证需要的不仅仅是哈希值。
风险较小的地方 - 非对抗性设置中的内容识别以及 Git 分阶段过渡到 SHA-256
对于签名和证书，SHA-1 是站不住脚的。来自受信任根的证书链。如果 CA 使用相同的 SHA-1 摘要签署两个不同的证书，则冲突攻击会让攻击者伪造其中一个证书。这不是理论上的：针对中间 CA 的攻击已被记录。任何依赖 SHA-1 的签名方案都有可能被拥有足够资源的攻击者伪造。每个主要浏览器和操作系统供应商都已弃用证书中的 SHA-1 。新证书必须使用 SHA-256。平台供应商已经明确表态，因为威胁是真实且直接的。
美国标准机构 NIST 已规定了明确的时间表。从 2024 开始，SHA-1 不应用于任何新应用程序。自 2030 起，SHA-1 预计将完全从联邦系统中退出。这并不是一种含糊的反对；而是一种含糊的反对。这是对政府承包商的具体授权，也是向行业发出的信号。遵循 NIST 的时间表可确保您的系统领先于弃用曲线，而不是在截止日期后混乱不堪。
存储库证据支持 SHA-1 弃用，而不是未读的 NIST 出版物或退休日期
存储库源文件将 SHA-1 作为遗留互操作性和名称证明了冲突工作，但它不包含标准体退役计划。因此，本节通过将弃用视为工程库存问题而不是引用未读的发布号或合规日期来更正大纲。
对于策略控制环境，请咨询管理该部署的机构并记录所审查的确切文档。这里的产品证据支持更窄的操作：保持 SHA-1 可用于重现现有值，将其标记为不适合新的安全用途，并在周围协议允许迁移的地方计算 SHA-256 替换。
工作示例 — 应用于旧版下载验证页面的迁移清单
从 SHA-1 的迁移路径通常以清单开始：SHA-1 在哪里使用？证书和签名？立即优先。 Git 存储库和内容寻址？中等优先级，跟随 Git 迁移节奏。已发布下载校验和？取决于信任模型。用于重复数据删除或归档的内部校验和？优先级较低，有更多时间进行规划。库存阶段揭示了真实的表面区域，并帮助您根据实际风险而不是抽象的紧迫性确定优先级。
对于每个角色，迁移看起来都不同。证书立即升级到 SHA-256。 Git 存储库阶段逐渐进入 SHA-256 引用，同时维护 SHA-1 以实现向后兼容性。下载校验和开始在 SHA-1 和 SHA-256 中发布，最终仅在 SHA-256 中发布。校验和数据库中的旧 SHA-1 摘要可以使用 ToolAcre SHA 哈希计算器进行验证，新条目应使用 SHA-256。该工具支持转换的双方，让您验证旧的哈希值并创建新的哈希值。
要点：SHA-1 用于比较，SHA-256 用于新工作 — ToolAcre SHA 哈希计算器包括 SHA-1，因此可以检查遗留摘要，而不是作为认可
对于大多数组织而言，迁移并不是“明天关闭 SHA-1”。它是“了解它的用途，优先考虑安全关键角色，并制定多年计划。”具有多年 SHA-1 提交的 Git 存储库应该逐渐过渡，并使用处理这两种情况的工具。证书基础设施应该已经迁移。在转换窗口期间发布的校验和应该是双算法的。逐步迁移减少了重大变化，并使系统有时间适应新的现实。
ToolAcre SHA 哈希计算器提供了该转换的双方。您可以验证旧系统中现有的 SHA-1 摘要，以确认文件与它们匹配。您可以计算 SHA-256 哈希值来开始发布迁移路径。该工具不会假装 SHA-1 是安全的；它将其标记为已损坏并解释原因。但它可以让您在构建通往 SHA-256 的桥梁并计划弃用时使用仍需要维护的遗留哈希值。