Hash 对于小字符串哈希，我应该使用不推荐的算法（如MD5）还是使用算法（如SHA256）的前缀？

我有16个字节来保存字符串散列。我知道，当您将任意长度的字符串缩减为固定长度的字节序列时，冲突是一个事实，但我希望尽可能避免它们。我最好使用不推荐的算法，如MD5，它的输出为16字节，还是使用尚待解决的算法（如SHA-256）的前16字节？

鉴于NIST将SHA-224定义为截断的SHA-256，这是您将要讨论的正式“批准印章”“截断SHA-256以满足尺寸要求是个好主意吗？”

由于MD5已被彻底拆除，并且很快将加入MD4的“内部测试都不要使用”框架中，因此答案非常明确——使用截断的SHA-256

也就是说，当你减少它的时候，冲突的数量自然会增加。SHA-256在统计上分布得很好，所以缩短不会比你用128位不可避免地增加冲突更多（好吧，多一点，因为没有哈希是完美的）。缩短甚至还可以增加已经稳固的SHA-256对长度扩展攻击的抵抗力

我知道业界有很多系统使用减半的SHA-512来提高对LAE的抵抗力（目前是理论上的），而不是SHA-256-当计算SHA-512与SHA-256时，额外的好处是64位系统的性能提升

我遇到过的最常见的截断形式是将前半部分与后半部分进行异或运算。我不确定它是否提供了任何额外的好处，但当人们看到“截断器”的“无法识别”输出时，他们会感到更轻松，所以他们就这样做了

更新

根据deceze的建议——当哈希被限定为“甚至不用于内部测试”时，这意味着它在设计上做得不好，对于特定的应用程序，应该不惜一切代价避免它，但对于其他应用程序，则不必如此

MD4和MD5都可以在非加密设置中用作固体散列算法，我已经看到系统专门为此重新设计了MD4——它非常快，具有固体分布，并且如果您对冲突不太挑剔的话（例如，您正在构建一个备份程序，需要知道自上次备份以来更改了哪些文件）它可以与一些为这些特定目的而设计的非加密散列进行正面的比较

然而，通常情况下，最好使用合适的工具来完成这项工作。非加密散列的设计首先是为了速度，同时也是为了扩展和低冲突率，其中一些散列在其配置文件方面甚至比加密散列更为出色，只是其缺点是或多或少具有可预测性

---

如果您需要一个非加密散列，而不是求助于破坏的加密散列，我建议您考虑一些总体上更好的用于非加密目的的散列，例如，甚至是普通的CRC32（有点慢，但比大多数加密散列更快）。有一个问题，所以一定要检查它。

在基本上没有攻击面的情况下，使用MD5可能会有什么问题，例如，作为计算哈希表中的键的函数来处理冲突？除了“让我们完全忘记MD5”之外，还有什么问题吗“？@deceze-对于FNV-1、SDBM、Murruse2或甚至好的ol'CRC32等计算成本的一小部分，有一些非加密哈希比MD5具有更好的扩展/低冲突率配置文件。当然，当我们谈论“甚至不用于测试”时，我们指的是在应用程序中使用它——作为加密散列——在这方面它失败得很惨。用于替代用途的散列列表将是答案本身的一个很好的补充。下一次，继续问它