理想的散列方法可以实现广泛的价值分配？

Question

作为我正在工作的节奏游戏的一部分，我允许用户创建和上传自定义歌曲和记事章。我正在考虑对歌曲和音符表进行哈希处理，以便对它们进行唯一识别。当然，我希望尽可能少的碰撞，但是，密码强度在这里并不是一个很大的均匀范围。另外，由于我很少执行哈希，因此计算效率不是太大的问题。

这是否像选择具有最大摘要大小的经过验证的哈希算法一样简单？或者我应该注意一些错综复杂的问题？我目前正在寻找SHA-256或512.

Answer 1

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

Answer 2

所有加密强度算法都应该完全没有碰撞。当然，冲突必然存在（可能的输入比可能的输出更多）但是使用现有的计算技术实际上找不到冲突是不可能的。

当散列函数的输出为 n 位时，可以找到与 2 ^{n / 2} 相关的工件的碰撞，所以实际上，小于大约140位输出的散列函数不能加密。此外，一些散列函数具有允许攻击者更快地发现碰撞的弱点;这些功能被称为“破碎”。一个主要的例子是MD5。

如果您不在安全设置中，并且只担心随机冲突（即没有人会主动尝试引发冲突，它们可能只是出于纯粹的运气），然后是一个破碎的加密哈希函数会好的。通常的建议是MD4。从密码学的角度来说，它尽可能地破碎，但对于非加密目的，它速度极快，并提供128位输出，避免了随机冲突。

但是，对于SHA-256或SHA-512，您可能不会遇到任何性能问题。在最基本的PC上，它们已经比硬盘提供的数据更快地处理数据：如果您对文件进行散列，则文件读取将成为瓶颈，而不是散列。我的建议是使用SHA-256，可能将其输出截断为128位（如果在非安全情况下使用），并且只有在适当注意和测量某些与性能相关的故障时才考虑切换到另一个功能。

Answer 3

如果不考虑加密安全性，那么您可以查看此link＆amp; this。如果您计划为标题/名称计算哈希并稍后进行查找，则最快和最简单（实现）将是Pearson哈希。或者你可以查看超高速哈希here。它也非常适合非加密使用。

Answer 4

像md5sum之类的东西出了什么问题？或者，如果你想要一个更快的算法，我只需要从文件长度（mod 64K以适合两个字节）和32位校验和创建一个哈希。这将给你一个6字节的哈希，它应该合理分布良好。实施起来并不复杂。

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

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

Answer 5

在这种情况下，加密哈希是不是一种矫枉过正，虽然我知道现代计算机的计算速度非常快？我假设您的用户将拥有唯一的用户ID。上传时，您只需要增加一个数字。因此，您将在内部将它们表示为userid1_song_1，userid1_song_2等。您可以将此信息存储在数据库中，并将其作为唯一键以及用户指定的名称。

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

如果你打算使用加密哈希，那么sha1应该是足够的，你不需要sha256。没有碰撞 - 尽管它们存在 - 已经被发现了。 Git，Mercurial和其他分布式版本控制系统使用sh1。 Git是一个基于内容的系统，使用sha1来查明内容是否已被修改。