Algorithm 适用于广泛分布值的理想哈希方法？

作为我正在开发的节奏游戏的一部分，我允许用户创建和上传自定义歌曲和记事本。我正在考虑对歌曲和记事本进行散列，以唯一地识别它们。当然，我希望碰撞尽可能少，但是，加密强度在这里并不像在一个大的统一范围内那么重要。此外，由于我很少执行散列运算，因此计算效率不是什么大问题

---

这和选择一个经过验证的、具有最大摘要大小的哈希算法一样简单吗？还是有些复杂的事情我应该注意？目前我正在查看SHA-256或512。

md5sum之类的东西有什么问题？或者，如果您想要一个更快的算法，我只需要根据文件长度（mod 64K，适合两个字节）和32位校验和创建一个哈希。这将为您提供一个6字节的散列，该散列应该分布合理。实现起来并不太复杂

当然，与所有哈希解决方案一样，如果基数太低，您应该监视冲突并更改算法。无论选择何种算法，这都是正确的（因为您的用户可能会开始上传退化数据）

---

您可能最终发现您试图解决一个不存在的问题（换句话说，可能是YAGNI）。

如果您使用它来唯一标识曲目，您确实需要加密哈希：否则，用户可能会故意创建与现有曲目哈希相同的曲目，并使用它来覆盖它们。除非另有令人信服的理由，否则SHA-1应该是完全令人满意的。

所有加密强度算法都应该完全没有冲突。当然，冲突必然存在（可能的输入多于可能的输出），但使用现有的计算技术，不可能真正找到冲突

当散列函数的输出为n位时，可能会发现与功的冲突约为2n/2，因此在实践中，输出小于约140位的散列函数在加密上不可能是强的。此外，一些散列函数存在弱点，使得攻击者能够更快地发现冲突；这些功能被称为“被破坏”。MD5就是一个很好的例子

如果您不在安全设置中，并且只担心随机冲突（即，没有人会主动尝试引发冲突，这可能只是因为运气不好），那么破坏的加密哈希函数就可以了。通常的建议是。从密码学的角度讲，它尽可能地被破坏，但对于非密码学目的来说，它的速度非常快，并提供128位的输出，从而避免了随机冲突

---

但是，SHA-256或SHA-512很可能不会有任何性能问题。在最基本的PC上，它们处理数据的速度已经超过了硬盘所能提供的速度：如果对文件进行散列，文件读取将是瓶颈，而不是散列。我的建议是使用SH-256，可能将其输出截断为128位（如果在非安全情况下使用），并且考虑到一些与性能相关的问题得到适当的注意和测量时考虑切换到另一个函数。

< P>如果不涉及密码安全性，那么您可以查看这个和。如果您计划计算标题/名称的哈希值，然后再进行查找，那么最快和最简单的（实现）将是Pearson哈希。或者你可以看看超快散列。它也非常适合非加密使用。

在这种情况下，加密散列不是一种过度杀伤力吗，尽管我知道现代计算机的计算速度相当快？我假设您的用户将具有唯一的userid。当他们上传时，你只需要增加一个数字。因此，您将在内部将它们表示为userid1_song_1、userid1_song_2等。您可以将此信息存储在数据库中，并将其作为唯一键以及用户指定的名称

你也没有提到这些歌曲的大小。如果是midi，那么文件大小将很小。如果文件大小很大（比如3MB），那么sha计算将不会是即时的。在我的Core2Duo笔记本电脑上，3.8MB文件的sha256sum需要0.25秒；对于sha1sum，它是0.2秒

---

如果您打算使用加密散列，那么sha1应该足够了，您不需要sha256。尽管存在碰撞，但尚未发现碰撞。Git、Mercurial和其他分布式版本控制系统使用sh1。Git是一个基于内容的系统，使用sha1查找内容是否被修改。

是的，这完美地回答了我的问题。事实上，我只关心随机碰撞，所以我将研究SHA-256和MD4。谢谢