在新系统上，我们需要单向散列来计算来自二进制输入的数字签名（例如，一千字节的文本，或更大的文本和二进制文件） . 需求类似于Scons（构建系统）散列命令行和源文件，以及Git（版本控制系统）如何散列文件以计算存储/同步签名 .
回想一下，Scons使用MD5，Git使用SHA-1 .
虽然MD5和SHA-1已被“破坏”，但Scons和Git都没有专门为安全性使用它们的哈希值（例如，它不存储密码），因此一般做法仍然认为这些算法可以接受这种算法 . （当然，由于传统的采用，这部分是合理化的 . ）
QUESTION: Would you use SHA256 (not MD5 nor SHA-1) for a (non-crypto/security) one-way hash in a new system?
关注的是：
-
MD5和SHA-1有很长的采用历史
-
SHA256相对较新（没有多少历史记录），但似乎目前推荐用于新工作（但我的应用程序并不特别需要"stronger"算法强度）
-
SHA256的计算时间更加昂贵
-
SHA256生成一个更长的密钥（这些密钥将用作目录/文件名，并存储在索引文件中），但我想我可以截断生成的密钥（哈希不太强，但应该足够），或者只是假设存储是便宜的文件系统可以处理它 .
我对与Scons或Git社区一致的答案特别感兴趣，"We'll keep ours forever!"或"We want to move to a new hash as soon as practical!"（我不确定他们的计划是什么？）
4 回答
是的，我会使用SHA-256 . SHA-256的安全性远远超过安全性;事实上，需要更换SHA1的原因之一就是你需要一个哈希函数 . 哈希算法产生有限的站点输出;虽然输入量不确定 . 最终会发生碰撞 . 输出越大;碰撞的可能性较小（使用适当的哈希算法时） .
Git使用SHA1，因为他们使用它作为文件名;他们希望它小而紧凑 . SHA256产生更大的摘要;消耗更多磁盘空间和更多数据通过线路传输 . This question具体解决了如果git遇到冲突会发生什么 .
看看你的观点：
SHA256已经在野外足够长，如果有问题;我们现在应该看到他们了 .
不太可能产生碰撞（如果这是你更强的标准;那么是更强） .
SHA-256比较慢;是 . 慢得多？取决于您的需求 . 95％的人;它's performance is acceptable assuming you'重新使用正确的实现 .
通常，截断SHA2的散列是okay thing to do .
即使使用MD5，非恶意冲突的概率也很小 . 这是一个思想实验：
填充良好的硬盘驱动器可能包含1M文件 . 对于实验，假设有10M文件 . 假设世界人口为10,000人，每人有一台计算机，每个文件都不同 .
我们将与10E6 * 10E9 = 1E17，<2 ^ 57的许多不同文件竞争
在这样一个遥远的案例中MD5碰撞的概率在2 ^ 71中小于1，或者在大约2E21中小于1！从正确的角度来看，对于10M中1的碰撞概率，我们将不得不重复实验大约2E14次，也就是说，自大爆炸以来每小时更换一次文件，然后再继续使用几十亿年 . .
2E14 / 24/365 / 13500E6 = 1.69
当然，使用SHA1或SHA256时，概率会更小，并且还会抵抗恶意攻击 - 与MD5不同，现在不可能有人为了拥有相同的哈希来构造文件 .
取决于你在做什么 . 计算SHA-256哈希需要更长的时间 . 对于许多应用程序来说并不是什么大问题，但如果您的应用程序试图每分钟计算数百或数千，该怎么办？你可能会发现额外的时间太多了 .
但另一方面，SHA-1的碰撞机率比SHA-256高得多 . 虽然理解这样的机会微乎其微（我认为SHA-1中的1 ^ 2 ^ 160/2）并且可能永远不会被大多数应用程序击中 . 但是，你散列的东西越多，机会就越大 . 如果你要数百万或数十亿的东西，这可能是一个问题 .
为了提高安全性（但这可能是定义的），减少了攻击者或机会的机会您可能想要考虑腌制或使用键控（HMAC）变体的事故 . Git的前缀（包括消息长度或CRC）这样的小技巧也会让攻击者更难设置一条消息，不仅具有相同的散列，而且还有一个有效的格式 .
您还可以考虑更大的哈希值，如Glacier（亚马逊）或Branch Cache Hash（Microsoft）使用的树或某些点对点网络（如BitTorrent或其他基于Merkle或Tiger Tree的构造） .