可以将 SHA256 哈希截断为 128 位吗？答案

【问题标题】：Is it okay to truncate a SHA256 hash to 128 bits?可以将 SHA256 哈希截断为 128 位吗？
【发布时间】：2011-03-02 21:21:34
【问题描述】：

MD5 和 SHA-1 哈希在碰撞攻击方面存在弱点。 SHA256 没有，但它输出 256 位。我可以安全地获取前 128 位或后 128 位并将其用作散列吗？我知道它会更弱（因为它的位数更少）但否则它会起作用吗？

基本上，我想用它来唯一标识文件系统中的文件，这些文件可能有一天会包含一万亿个文件。我知道生日问题，一个 128 位的哈希应该在万亿文件中产生大约万亿分之一的机会，即会有两个具有相同哈希的不同文件。我可以忍受这些可能性。

我不能忍受的是，如果有人可以轻松地、故意地插入一个具有相同哈希值和文件开头字符的新文件。我相信 MD5 和 SHA1 是可能的。

【问题讨论】：

我原以为生日悖论的几率会比这低，但维基百科同意你的观点：en.wikipedia.org/wiki/Birthday_paradox#Probability_table
相关问题：stackoverflow.com/questions/2256423/…
另见：security.stackexchange.com/questions/18385/…
所以...没有对生日悖论维基百科文章的另一个模糊参考，有人可以用相对非技术性的简短语言总结为什么可以截断哈希算法的输出？如果这是一个好主意，为什么哈希算法不只是为您省去麻烦并截断自己呢？换句话说，哈希算法产生的输出在算法的参数范围内总体上保证对于每个输入都是唯一的。实际算法本身是否保证前 128 个字符是唯一的？
你真的能从一篇关于生日悖论的文章中推断出截断 SHA-256 的输出是有效的，该文章讨论了一般的散列，但没有提到截断散列算法的输出的影响，让仅截断任何特定散列算法的输出的影响？ SHA-256 产生 256 位结果，是吗？它确实 not 输出 128 位结果。该算法的作者在哪里声明，如果你任意丢弃 128 位结果，你是安全的？就此而言，截断的 SHA-256 比完整的 160 位 SHA-1 更安全吗？

标签： hash md5 sha256 sha

【解决方案1】：

是的，这会起作用。

据记录，有已知的针对 MD5 的冲突攻击正在使用中，但 SHA-1 攻击目前完全是理论上的（尚未发现 SHA-1 冲突...）。

【讨论】：

SHA-256（OP 正在谈论的哈希）是 SHA-2，而不是 SHA-1 - 我认为？到目前为止，还没有发现 SHA-2 的冲突……甚至在理论上也没有。
@mrl33t：不； SHA-1 存在理论上的漏洞，但 SHA-256（它是 SHA-2 套件的一部分）甚至没有这些漏洞。考虑到 SHA-256 散列的大小是 SHA-1 的 2^128 倍，并且 SHA-2 被认为在理论上更安全，短期内不太可能发生任何 SHA-256 冲突。
2^128 倍？哇！ ;) 我想你可能想检查你的数学，或者你的措辞......
@Dan：哎呀，我的意思是 搜索空间 是 2^96 倍，抱歉 (2^96 * 2^160 = 2 ^256)
今年早些时候发现了SHA-1冲突：shattered.io

【解决方案2】：

但这值得吗？如果每个文件都有一个哈希，那么每个文件基本上都有开销。假设每个文件必须占用至少 512 字节（一个典型的磁盘扇区），并且您将这些哈希存储得足够紧凑，以免每个哈希占用的空间超过哈希大小.

因此，即使您的所有文件都是 512 字节（最小的），您所说的也是 16 / 512 = 3.1% 或 32 / 512 = 6.3%。实际上，我敢打赌您的平均文件大小更大（除非您的所有文件都是 1 个扇区...），因此开销会更少。

现在，散列所需的空间量与您拥有的文件数量成线性关系。额外的空间值得那么吗？即使您有提到的万亿文件 - 那是 1 000 000 000 000 * 16 = ~29 TiB，这是一个很大的空间，但请记住：您的数据将是 1 000 000 000 000 * 512 = 465 TiB。这些数字真的毫无价值，因为它仍然是3% 或6% 开销。但在这个级别，你有半 PB 的存储空间，15 TB 重要吗？在任何层面上，3% 的节省是否意味着什么？请记住，如果它们更大，您可以节省更少。（其中，它们可能是：祝你在该硬盘大小下获得 512 字节的扇区大小。）

那么，这3% 或更少的磁盘节省是否值得潜在的安全风险。（我不会回答，因为这不是我的一杯茶。）

或者，您能否以某种合乎逻辑的方式将文件组合在一起，从而减少文件数量？（我的意思是，如果你有数万亿个 512 字节的文件，你真的要散列磁盘上的每个字节吗？）

【讨论】：

并没有真正回答这个问题。是吗？
@ALOToverflow：不，它没有。但这并不意味着它不相关：有时质疑问题的前提可能会为发帖者、稍后通过 Google 阅读问题的普通观众或两者提供更好的解决方案：所以在这里是有帮助的，所以我认为这样的帖子是值得的。我也许应该更加强调安全方面：根据我的经验，在处理密码学的大多数事情中，如果你偏离常规，就会发生奇怪（通常是坏事）的事情。这值得在磁盘上节省一点点吗？（可能是，但这取决于用例。）

【解决方案3】：

是的，这会起作用。从理论上讲，最好将两半异或在一起，但即使是截断的 SHA256 也比 MD5 强。不过，您仍应将结果视为 128 位散列而不是 256 位散列。

在这种特殊情况下，我的特别建议是使用 HASH + uniquifier 存储和引用，其中 uniquifier 是您之前使用此哈希看到的不同文件的数量。这样，如果有人试图为 SHA256 存储未来发现的碰撞向量，您就不会完全崩溃。

【讨论】：

我找不到任何参考资料说理论上将两半异或在一起更好，我对此表示怀疑。 uniquifier 的有趣想法。
GregS：对 MD5 的一些早期攻击导致大部分哈希值与一两个不同的单元格发生冲突。
@Joshua 这听起来像是经验上（而不是理论上）更好。我也对为什么 XOR 会更好的参考感兴趣。
你不需要对两半进行异或，官方标准说你可以只取最左边的 128 位（见this answer）。

【解决方案4】：

Crypto 做类似的事情，例如以太坊地址是 Keccak（SHA-3 的前身）哈希的低 160 位。

【讨论】：