开发者工具 · SHA 哈希计算器
加密哈希与校验和：CRC32 和 xxHash 不能保证什么
· 背景
sha-256 密码学 安全
CRC32、FNV 和 xxHash 也是哈希值，但它们不对对手做出任何承诺。这篇文章解释了加密哈希与校验和的区别以及如何根据用例进行选择。
哪个哈希适合哪个作业？ ——速度和对抗安全之间的选择
哈希函数分为三类：用于检测意外错误的校验和、用于分发和性能的非加密哈希以及用于安全的加密哈希。每个类别在速度和摘要大小方面都有不同的保证和不同的权衡。像 CRC32 这样的校验和快速且短（4 字节，8 十六进制字符），但无法防止故意修改。像 xxHash 或 MurmurHash 这样的非加密哈希也很快，对于哈希表和数据分发很有用，但无法针对想要引起冲突的对手提供保护。像 SHA-256 这样的加密哈希速度较慢，并且会生成更长的摘要（32 字节、64 十六进制字符），但它提供原像抵抗和碰撞抵抗 - 防止对手攻击的安全属性。
为您的用例选择错误的哈希函数是一个常见的安全错误。使用CRC32验证来自不可信来源的文件下载是无效的；攻击者可以轻松修改该文件并重新计算 CRC32。在高频哈希表中使用 SHA-256 作为快速哈希函数是浪费的； CRC32 或快速非加密哈希就足够了，而且更便宜。
意外错误的校验和 — CRC 用于检测传输中位翻转的设计
校验和设计用于传输或存储期间的错误检测，其中错误被假定为随机和偶然的。 CRC（循环冗余校验）最初设计用于检测通信中的位翻转。 CRC32 生成 32 位摘要。如果帧在传输过程中因随机位翻转而损坏，则 CRC32 几乎肯定会发生变化，从而警告接收器请求重传。 CRC最多可以检测一定数量的比特错误，具体取决于多项式；对于最常见的用例，可以可靠地检测单个位翻转或突发的几个位翻转。
CRC 是确定性的，但不是加密的。给定一个文件及其 CRC32，攻击者可以修改该文件并重新计算 CRC32 以匹配预期值。对于了解 CRC 多项式的对手来说，制造冲突很简单。 CRC 从来没有打算抵制故意修改；它纯粹是为了意外错误检测。 ZIP 文件和 JPEG 文件等历史系统使用 CRC 来实现此目的。现代协议使用 CRC 在加密或经过身份验证的通道中进行快速错误检测，而不是作为独立的完整性检查。
用于分发的非加密哈希 — 哈希表和分区中的 FNV、MurmurHash 和 xxHash
FNV-1a、MurmurHash 和 xxHash 等非加密哈希旨在提高哈希表和数据分区的速度和一致性。它们具有非常低的延迟，适用于需要跨服务器或存储桶分区数据而不关心安全属性的情况。如果您正在构建缓存并需要将键映射到存储桶编号，则快速散列是合适的。 MurmurHash 专为哈希表使用而设计，在大多数硬件上比 SHA 更快。 xxHash 较新，针对具有大型缓存和矢量化的现代 CPU 进行了优化。
这些哈希值不是加密的，因为它们不能抵抗原像攻击（查找生成特定摘要的输入）或冲突攻击（查找生成相同摘要的两个不同输入）。攻击者可以计算哈希算法并找到发生冲突或产生目标输出的输入。在受信任的环境（所有节点都在您的控制之下的集群）中，这是可以接受的。如果不受信任的用户可以控制输入，则非加密哈希很容易受到冲突攻击，从而降低性能（哈希表最坏的情况是所有键冲突时的线性搜索）或产生其他副作用。
加密哈希添加了什么 - 针对蓄意攻击者的原像和碰撞抵抗
诸如 SHA-256、SHA-384 和 SHA-512 之类的加密哈希提供原像抵抗：给定一个摘要，在计算上无法找到任何生成该摘要的输入。它们还提供抗碰撞性：在计算上不可能找到产生相同摘要的两个不同输入。这些属性可以防止攻击者伪造下载、创建虚假证书或篡改消息。代价是速度：在大多数硬件上，SHA-256 比 CRC32 慢，比 xxHash 慢。
SHA-1 已被加密破坏（冲突是实际的），不应用于新的安全目的，但仍会计算它以实现旧版兼容性。 SHA-256、SHA-384 和 SHA-512 仍然很强大，并且是加密哈希的标准选择。 SHA-2 中的“2”表示 SHA 算法的第二个系列（第一个是原始的 SHA-1；SHA-3 是较新的系列，但很少用于此目的）。
加密哈希添加对抗性属性；本文避免了不受支持的相对速度声明
将五个场景与正确的哈希族相匹配：首先，通过使用 AES 加密的可靠通道传输网络帧：CRC32 是合适的。加密可防止修改，CRC 可检测意外损坏。其次，用于负载平衡的哈希表或一致性哈希：像 xxHash 这样的非加密哈希是合适的。速度很重要，环境值得信赖。第三，验证来自不受信任来源的下载完整性：需要SHA-256。攻击者可以修改文件和校验和，但不能修改加密哈希而不破坏 SHA-256。
第四，数字签名和证书： SHA-256 是必需的，与 RSA 或 ECDSA 等非对称算法结合。签名证明签名后哈希值没有被修改。第五，对用户上传的文件进行重复数据删除：需要SHA-256，因为用户可能会故意上传旨在与非加密哈希中的现有文件发生冲突的文件。如果基于xxHash的重复数据删除，攻击者可以上传与另一个文件具有相同哈希但内容不同的文件，导致系统错误地丢弃该上传。
工作示例 - 将五个场景（网络框架、哈希映射、下载验证、签名、用户上传的重复数据删除）匹配到正确的系列
为每个用例选择加密哈希的成本是性能开销。 SHA-256 比 CRC 慢，比 xxHash 慢。在热循环（一段每秒执行数百万次的代码）中，开销是显而易见的。在设置阶段或批量操作中，它可以忽略不计。决策框架是：对手是否有动机引起碰撞？如果是，请使用 SHA-256。如果不是，并且速度很重要，请使用更快的哈希值。如果安全性比速度更重要，请无论如何使用 SHA-256。
一个常见的错误是使用 MD5，这是一种较旧的加密哈希，现已被破坏。 MD5 是在 1992 中设计的，冲突在 2004 中进行了演示。将 MD5 用于任何安全目的都是不安全的。有时会在遗留系统和速度优先的情况下看到这种情况，但如今 MD5 并不是正确的选择：如果您需要速度，请使用 xxHash；如果您需要速度，请使用 xxHash；如果您需要安全性，请使用 SHA-256。切勿使用 MD5。
场景映射保持定性，因为吞吐量和冲突行为需要特定于实现的证据
密码散列是第四类，与校验和和通用加密散列不同。不要使用 SHA-256 对密码进行哈希处理。相反，请使用 bcrypt、scrypt 或 Argon2 等密码散列函数，这些函数故意速度较慢并且包含盐。像 SHA-256 这样的快速加密哈希使得密码猜测变得很便宜：攻击者每秒可以尝试数百万次猜测。密码散列函数的设计目的是使每次猜测都消耗大量的 CPU 和内存，因此猜测强密码仍然需要比任何攻击者等待的时间更长的时间。密码散列是一种特殊的用例，有其自己的要求。
ToolAcre SHA 哈希计算器不支持密码哈希，并且故意不提供 MD5、自定义参数和快速哈希。它是计算标准 SHA 摘要以进行验证和完整性检查的工具，而不是用于身份验证或密码存储。
要点：有对手还是没有对手 — 当有人可能篡改数据时，请使用 ToolAcre SHA 哈希计算器
哈希算法的选择是影响整个系统性能和安全性的基本决策。摘要的可信度取决于生成它的算法。如果您选择 CRC32 进行文件验证，则摘要不会提供针对故意修改的保护。如果为哈希表选择 SHA-256，则会浪费资源。了解每个类别的属性和权衡可以让您做出正确的选择。
ToolAcre SHA 哈希计算器提供 SHA-1 到 SHA-512，涵盖了对大多数用例而言重要的加密哈希值。它不提供 CRC32、xxHash 或 MD5，因为它们在特定环境中都是正确的选择（CRC 用于受信任通道中的错误检测，xxHash 用于受控环境中的性能，MD5 不提供任何内容），并且提供它们而不强调何时使用它们会鼓励错误。该计算器用于计算标准加密摘要。如果需要这些哈希值，请使用命令行和 `crc32`、`xxh64` 或等效工具。对于下载验证、证书指纹、git 提交以及对手可能篡改数据的类似用例，请通过 ToolAcre SHA 哈希计算器获取 SHA-256。