为什么 Web 加密为 SHA-512 提供 SHA-1 而不是 MD5 或 SHA-3

MD5 在哪里？ ——任何迁移遗留校验和工作流程的人提出的第一个问题

浏览器的 Web Crypto API 恰好提供了四种摘要算法：SHA-1、SHA-256、SHA-384 和 SHA-512。如果您使用 ToolAcre SHA 哈希计算器期待 MD5 或 SHA-3，您将找不到它们。这种特殊性并不是工具的限制；它反映了经过深思熟虑的平台选择。了解为什么包含这四个选项以及为什么省略两个流行的替代方案可以让您充分了解浏览器 API 的设计方式。

每个主要浏览器都在安全来源上公开 crypto.subtle.digest。当您的 JavaScript 调用该方法时，它会传递到平台的加密实现 - 使用安全沙箱和性能优化运行的本机代码。提供的摘要算法由 W3C Web 加密工作组选择，具有特定的优先级：与现有安全标准的兼容性、跨加密库的可用支持、成熟度以及 Web 平台的实际安全需求。

SubtleCrypto.digest 支持四种算法 — SHA-1、SHA-256、SHA-384 和 SHA-512，仅此而已

ToolAcre 接受由digestBytes 强制执行的相同的四个标识符：SHA-1、SHA-256、SHA-384 和SHA-512。在调用 Web Crypto 之前，无法识别的名称会被拒绝，并且测试套件专门通过 MD5 来确认该拒绝。因此，选择器描述了经过测试的产品边界，而不是对每个标准化摘要进行的调查。

该列表中出现的 SHA-1 并未提出所有四个等效建议。其结果对象带有损坏的标志，并且界面重复遗留警告；其他三个是可用的 SHA-2 选择。当兼容性工具重现旧值而不鼓励新的依赖时，可用性和适用性必须保持分离。

MD5；本文没有添加无源标准的理由

MD5 是一种加密哈希函数，可生成 128 位摘要，使其比 SHA-256 更短且计算成本更低。几十年来，它一直是校验和和数字签名的标准选择。然而MD5的抗碰撞能力从根本上被打破了。在 2004 中，密码学家演示了实际的冲突——两个不同的输入具有相同的摘要——并且该算法已被学术工作彻底拆解。数学上的脆弱性是绝对且永久的。

W3C Web 加密规范特意选择不包含 MD5。推理很简单：将损坏的算法交付给数百万浏览器用户将使其在新应用程序中的使用正常化，即使它应该只出现在旧版兼容性场景中。如果应用程序确实需要 MD5 才能与旧系统进行互操作，则该代码属于服务器端运行时，在该运行时可以理解和审核需求，而不是在浏览器中。让损坏的算法可以方便地访问将为新系统带来安全期望。

ToolAcre SHA 哈希计算器也不提供 MD5 实现。就像它使用的平台 API 一样，它拒绝让损坏的算法方便地访问。如果您的应用程序绝对需要 MD5（在遗留 Git 系统之外很少见），则该实现属于您自己的代码库，并明确说明它是一个兼容性填充程序。可访问性创造期望，而损坏的算法不值得期望。

SHA-3 位于浏览器 API 和工具之外；它的采用历史在存储库证据之外

SHA-3 由 NIST 在 2015 中标准化，并且它在密码学上是可靠的。它使用与 SHA-2 完全不同的结构，称为海绵，它提供有趣的理论属性和性能权衡，具体取决于您的硬件。在现代系统上，SHA-3 可能比 SHA-256 更快。然而，浏览器平台今天并没有公开它，这种延迟反映了有关平台成熟度和采用速度的实际决策。

发货延迟 SHA-3 反映了现实：Web Crypto 旨在涵盖在网络和 HTTPS 中最广泛使用的算法/TLS. 在 API 最终确定时，SHA-2（256、384、512）是新系统的压倒性共识，并转向SHA-3 的发生速度比从 MD5 或 SHA-1 移动的速度要慢得多。大多数应用程序还不需要 SHA-3 。扩展 API 并在每个浏览器和平台上进行测试的成本在发布时的需求并不合理。

这不是永久拒绝。 Web Crypto API 可以不断发展。如果 SHA-3 采用加速，工作组可以添加它。当前的集合代表了 Web Crypto 满足平台即时安全需求所需的成熟且广泛标准化的算法。浏览器 API 必须稳定且精心维护；在广泛需求之前急于添加功能会在未来几年造成维护负担和兼容性风险。

为什么 SHA-1 仍然存在 - 遗留验证需求以及提供和推荐之间的区别

SHA-1 尽管已被破坏，但仍包含在 Web Crypto 中。这种违反直觉的选择常常让开发人员感到惊讶。该算法会生成 160 位摘要，并且针对 SHA-1 的冲突攻击现在已经实用 - 可以制作两个不同的文档来共享相同的摘要。选择前缀冲突允许攻击者制作两个在冲突时都有意义的文档，从而破坏签名和证书。但它仍然保留在平台中。

SHA-1 保留在 Web Crypto 中的一个必要原因是：遗留兼容性。 Git 对象标识符基于 SHA-1，虽然 Git 项目正在过渡到 SHA-256，但数百万现有存储库、引用和构建系统仍然会发出 SHA-1 哈希值。来自旧系统的 TLS 证书指纹带有 SHA-1 摘要。几年前发布 HMAC-SHA1 签名的 API 仍然需要验证。这些已部署的系统必须经过验证或迁移。该平台包括 SHA-1 以使必要的工作成为可能。

平台 API 包含 SHA-1，但我们清楚地知道它的存在是为了兼容性，而不是推荐。浏览器的 UI 标签 SHA-1 带有警告。 ToolAcre SHA 哈希计算器在 SHA-1 结果旁边显示“加密已损坏”，确保使用它的任何人都知道他们正在使用遗留材料。透明度至关重要；用户绝不能将 SHA-1 兼容性误认为 SHA-1 认可。

如果兼容性需要 MD5，请使用此工具之外经过审查的实现，并且切勿将兼容性误认为是安全性

Web Crypto 中的四种算法与 TLS 密码套件生态系统以及最重要的安全标准保持一致。 SHA-256 是通用哈希的当前默认值，用于子资源完整性检查、内容寻址和新安全系统。 SHA-512 在 64 位硬件上速度更快，并提供更广泛的摘要。 SHA-384 主要因其在 TLS 密码套件中的使用而闻名。

SHA-1 是为了实现互操作性，而不是因为任何人都应该用它启动新系统。如果您要验证现有的 SHA-1 校验和、匹配旧证书指纹或复制 Git 提交 ID，ToolAcre 中的 SHA-1 可以让您执行此操作。如果您正在设计一个新系统，SHA-256 是显而易见的选择。您选择的算法表明您对安全模型的理解。

这不包括服务器端运行时，它通常会公开更多的摘要算法

如果您的应用程序确实需要 MD5、SHA-3 或任何其他算法，那么选择很明确：将该代码保留在服务器端运行时中，并仅向浏览器公开最终结果。不要发布您自己的加密算法的 JavaScript 实现以供浏览器使用。浏览器的本机 Web Crypto 更快、更安全，并且以手写 JavaScript 函数无法比拟的方式进行审核。当平台提供你需要的东西时，委托给平台永远是正确的选择。

这甚至适用于“简单”算法。自己编写的 MD5 实现可能看起来无害，因为 MD5 无论如何都被破坏了，但被破坏的算法没有等级——它们只是被破坏了。发布一个规范了在应用程序代码中实现加密的实践。浏览器提供平台所需的内容；使用它提供的东西。手工加密是 Web 应用程序中安全漏洞的最大来源，因为开发人员低估了其中的微妙之处和边缘情况。

要点：局限性是产品的一部分 — ToolAcre SHA 哈希计算器提供了浏览器本机实现的四种算法，并记录了边界

ToolAcre SHA 哈希计算器直接显示了此约束：您可以准确地看到 Web Crypto 提供的四种算法，不多也不少。如果您粘贴一个值并认为“我需要 MD5”，则该缺失是故意的。如果您需要它，则表明您的系统有一个需要仔细处理的遗留组件 - 正是专门的服务器端迁移工具而不是浏览器实用程序的用途。该工具对其所做和不提供的内容的诚实性本身就是有价值的信息。

Web 加密设计反映了数十年的加密实践：在广泛部署中经过标准化、审核和验证的算法。 SHA-256 和 SHA-512 是合理的默认值。 SHA-384 具有 TLS 谱系。 SHA-1 之所以存在，是因为网络有 SHA-1 摘要，需要多年的验证。 MD5 和 SHA-3 不存在，因为 MD5 已损坏，并且 SHA-3 对平台还不是至关重要的。