14

在一个新系统上，我们需要一个单向哈希来计算二进制输入的数字签名（例如，一千字节的文本，或更大的文本和二进制文件）。需求类似于 Scons（构建系统）如何散列命令行和源文件，以及 Git（版本控制系统）如何散列文件以计算存储/同步的签名。

回想一下，Scons 使用 MD5，而 Git 使用 SHA-1。

虽然 MD5 和 SHA-1 已被“破坏”，但 Scons 和 Git 都没有专门使用它们的哈希值来确保安全（例如，它不用于存储密码），因此一般实践仍然认为这些算法可以用于该用途。（当然，由于采用传统，这部分是合理化的。）

问题：您会在新系统中使用 SHA256（不是 MD5 或 SHA-1）作为（非加密/安全）单向哈希吗？

担忧是：

  1. MD5 和 SHA-1 的采用历史悠久
  2. SHA256 相对较新（没有太多历史），但目前似乎推荐用于新工作（但我的应用程序并不特别需要“更强”的算法强度）
  3. SHA256 计算起来更耗时
  4. SHA256 生成一个更长的密钥（这些将用作目录/文件名，并存储在索引文件中），但我想我可以截断生成的密钥（哈希不太强，但应该足够了），或者只是假设存储很便宜并且文件系统可以处理它。

我会对与 Scons 或 Git 社区一致的答案特别感兴趣，“我们将永远保留我们的！” 或“我们希望尽快转移到新的哈希！” （我不确定他们的计划是什么？）

4

4 回答 4

27

是的，我会使用 SHA-256。SHA-256 考虑的不仅仅是安全目的；实际上，需要替换 SHA1 的原因之一就是您需要哈希函数。哈希算法产生有限的站点输出；在输入量不确定的情况下。最终会发生碰撞。输出越大；发生冲突的可能性越小（使用适当的哈希算法时）。

Git 选择了 SHA1，因为他们使用它作为文件名；他们希望它小巧紧凑。SHA256 产生更大的摘要；消耗更多的磁盘空间和更多的数据来通过网络传输。这个问题专门解决了如果 git 遇到冲突会发生什么。

看看你的观点：

  1. SHA256 已经存在很长时间了，如果有问题的话；我们现在应该已经看到了。
  2. 它本身并不是“更强大”，它不太可能产生碰撞（如果这是你更强的标准；那么是的，它更强大）。
  3. SHA-256 较慢；是的。慢很多？取决于你的需求是什么。95%的人；假设您使用正确的实现，它的性能是可以接受的。
  4. 一般来说，截断 SHA2 的哈希是一件好事。
于 2011-06-26T15:24:37.077 回答
7

即使使用 MD5，非恶意碰撞的可能性也非常小。这是一个思想实验：

一个塞得满满的硬盘驱动器可能有 1M 文件。对于实验，假设有 10M 个文件。假设世界人口是 10.000 万人，每个人都有一台计算机，每个文件都是不同的。

我们将处理许多不同的文件 10E6 * 10E9 = 1E17, < 2^57

在这种牵强附会的情况下，MD5 冲突的概率将小于 2^71 中的 1，或者大约 2E21 中小于 1！从这个角度来看，对于 1 千万分之一的碰撞概率，我们将不得不重复实验大约 2E14 次，也就是说，自大爆炸以来每小时更换每个文件，然后继续进行数十亿年.

2E14 / 24 / 365 / 13500E6 = 1.69

当然，使用 SHA1 或 SHA256，概率会更小，并且还会抵抗恶意攻击——与 MD5 不同，（现在）不可能有人故意构建文件以获得相同的哈希值。

于 2012-05-17T09:10:37.050 回答
1

取决于你在做什么。计算 SHA-256 哈希需要更长的时间。对于许多应用程序来说没什么大不了的，但是如果您的应用程序试图每分钟计算数百或数千呢？您可能会发现额外的时间太多了。

但另一方面，SHA-1 发生冲突的可能性比 SHA-256 高得多。请理解，尽管这样的机会微乎其微（我认为 SHA-1 为 2^160/2 中的 1 个），并且可能永远不会受到大多数应用程序的影响。然而，你散列的东西越多，机会就越高。如果你要散列数百万或数十亿的东西，这可能是一个问题。

于 2011-06-26T18:13:50.507 回答
1

为了提高安全性（但可以定义）并减少攻击者或事故的机会，您可能需要考虑加盐或使用键控 (HMAC) 变体。此外，像 Git 的前缀（包括消息长度或 CRC）这样的小技巧可以使攻击者更难设备不仅具有相同的散列而且具有有效格式的消息。

您还可以考虑更大的哈希值，例如 Glacier (Amazon) 或 Branch Cache Hash (Microsoft) 使用的树，或一些点对点网络，例如 BitTorrent 或其他基于 Merkle 或 Tiger Tree 的结构。

于 2013-08-10T05:10:17.040 回答