对于这个应用程序我是我的，我觉得我可以逃脱40位哈希键，这看起来非常低，但看看你是否可以确认我的推理（我想要一个小键，因为我想要一个小文件名和密钥将转换为文件名）：
（注意：只有意外碰撞是一个问题 - 没有安全问题。）
这里的一个关键点是所讨论的人口被分成几组，只有当碰撞发生在同一组内时，碰撞才是相关的。 “组”是用户系统上的目录（文件内容经过哈希处理，只有当同一目录中的文件出现冲突时才会发生冲突）。因此，推测大约100,000个潜在用户，比如2 ^ 17，这对应于2 ^ 18个“组”，假设每个用户平均有2个目录。所以使用40位密钥，我可以期待在某个用户某处发生冲突之前创建2 ^（20 + 9）个文件（在所有用户中）。 （或IOW 2 ^（（40 + 18）/ 2），由于“生日效应”。）这是为每个用户创建的平均4096个唯一文件，对于2 ^ 17个用户，在某个用户某处发生单个冲突之前。然后在某个地方发生另一次碰撞之前那么久（对吧？）
答案 0 :(得分：0)
你的数学看起来很合理，但我想知道为什么你会为此烦恼。如果要创建唯一的文件名，为什么不为每个用户分配一个编号，并为该用户保留序列号。当您需要文件名时，基本上只需将用户编号与序列号连接起来（两者都填充到正确的位数）。如果您觉得需要对这些数字进行模糊处理，请通过40位加密运行该结果（这将保证唯一输入产生唯一输出）。
例如，如果为每个分配20位，则可以让2个 20 用户分别创建2个 20 文档，然后才有可能发生冲突。
如果您不介意对其进行序列化访问，则可以使用单个40位计数器。这样做的好处是单个用户不会立即使用2个 20 序列号，即使普通用户不太可能创建几乎那么多文档。
同样，如果您认为由于某种原因需要对此数字进行模糊处理，则可以在计数器模式下使用40位加密算法（即使用序列号，但对其进行加密），这会再次保证每个输入映射一个独特的输出。除非您的用户创建2个 40 文档（即最多可能只有40位），否则这将保证不会发生冲突。或者，您可以创建一个40位全量程线性反馈移位寄存器来创建伪随机40位数。这可能稍微不那么安全，但具有更快，更简单的优势。