单向散列（不是加密/安全），使用SHA256（不是MD5，SHA-1）？

Question

在新系统上，我们需要单向散列来计算来自二进制输入的数字签名（例如，一千字节的文本或更大的文本和二进制文件）。需求类似于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社区一致的答案特别感兴趣，“我们会永远保留我们的！”或“我们希望转移到新的哈希一旦实际可行！“（我不确定他们的计划是什么？）

Answer 1

是的，我会使用SHA-256。 SHA-256的安全性远远超过安全性;事实上，需要更换SHA1的原因之一就是你需要一个哈希函数。哈希算法产生有限的站点输出;虽然输入量不确定。最终会发生碰撞。输出越大;碰撞的可能性较小（使用适当的哈希算法时）。

Git使用SHA1，因为他们将它用作文件名;他们希望它小而紧凑。 SHA256产生更大的摘要;消耗更多磁盘空间和更多数据通过线路传输。 This question专门解决了如果git遇到冲突会发生什么。

看看你的观点：

1. SHA256已经在野外足够长，如果有问题;我们现在应该看到它们。
2. 它不是“更强”本身，它不太可能产生碰撞（如果这是你更强的标准;那么是更强）。
3. SHA-256比较慢;是。慢得多？取决于您的需求。 95％的人;假设您正在使用正确的实现，那么它的性能是可以接受的。
4. 通常，截断SHA2的哈希是okay thing to do。

Answer 2

即使使用MD5，非恶意冲突的概率也很小。这是一个思想实验：

填充良好的硬盘驱动器可能包含1M文件。对于实验，假设有10M文件。假设世界人口是10000万人，每人有一台计算机，每个文件都不同。

我们将与10E6 * 10E9 = 1E17的许多不同文件竞争，＆lt; 2 ^ 57

在这样一个遥远的案例中MD5碰撞的概率小于1 ^ 2 ^ 71，或者小于1大约2E21！从正确的角度来看，对于10M中1的碰撞概率，我们将不得不重复实验大约2E14次，也就是说，自大爆炸以来每小时更换一次文件，然后再继续使用几十亿年。

2E14 / 24/365/13500 E6 = 1.69

当然，使用SHA1或SHA256时，概率会更小，并且还会抵抗恶意攻击 - 与MD5不同，（现在）某人有意构造文件是不可能的散列。

Answer 3

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

另一方面，SHA-1的碰撞机率比SHA-256高得多。虽然理解这样的机会微乎其微（我认为SHA-1中的1 ^ 2 ^ 160/2）并且可能永远不会被大多数应用程序击中。但是，你散列的东西越多，机会就越大。如果你要渲染数百万或数十亿的东西，这可能是一个问题。

Answer 4

为了提高安全性（但这可能是定义的），减少了攻击者或事故的机会，您可能需要考虑腌制或使用键控（HMAC）变体。 Git的前缀（包括消息长度或CRC）这样的小技巧也可以使攻击者更难设置一条消息，不仅具有相同的散列，而且还有一个有效的格式。

您还可以考虑更大的哈希值，例如Glacier（亚马逊）或Branch Cache Hash（Microsoft）使用的树或某些点对点网络（如BitTorrent或其他基于Merkle或Tiger Tree的构造）。