hash - 依靠哈希进行文件识别有多安全？

Question

我正在 LAMP 堆栈之上设计一个存储云软件。

文件可以有一个内部 ID，但是在服务器文件系统中不使用递增的 id 作为文件名，而是使用哈希作为文件名来存储它们会有很多好处。

如果当前的集中式数据库应该被分片或分散，或者应该设置某种主-主高可用性环境，那么哈希作为数据库中的标识符也会有很多优势。但我还不确定。

客户端可以在任何字符串(通常是某种路径和文件名)下存储文件。

这个字符串保证是唯一的，因为在第一层是类似于用户在 Amazon S3 和 Google 存储中注册的“存储桶”。

我的计划是将文件存储为客户端定义路径的哈希值。

通过这种方式，存储服务器可以直接为文件提供服务，而无需数据库询问它是哪个 ID，因为它可以即时计算哈希值，从而计算文件名。

但我害怕碰撞。我目前正在考虑使用 SHA1 哈希。

我听说 GIT 也使用散列和修订标识符。

我知道碰撞的机会真的很低，但有可能。

我只是无法判断这一点。为此，您会还是不会依赖哈希？

我还可以对路径编码进行一些规范化。也许 base64 作为文件名，但我真的不想要它，因为它可能会变得困惑，路径可能会变得太长，并且可能会出现其他并发症。

Answer 1

假设您有一个具有“完美”属性的散列函数，并假设加密散列函数方法适用的理论与适用于 birthday attacks 的理论相同。 .这就是说，给定最大数量的文件，您可以通过使用更大的哈希摘要大小来使碰撞概率尽可能小。 SHA 有 160 位，因此对于任何实际数量的文件，冲突的概率几乎为零。如果您查看链接中的表格，您会看到具有 10^10 个文件的 128 位哈希的冲突概率为 10^-18 。

只要概率足够低，我认为解决方案是好的。与行星被小行星撞击的概率、磁盘驱动器中无法检测到的错误、内存中的位翻转等相比——只要这些概率足够低，我们就不必担心它们，因为它们“永远不会”发生。只需留出足够的余量并确保这不是最薄弱的环节。

需要关注的一件事是散列函数的选择及其可能的漏洞。是否有任何其他身份验证或用户只是提供路径并检索文件？

如果您考虑攻击者试图对上述场景进行暴力破解，他们将需要请求 2^18 个文件，然后才能获取系统中存储的其他一些随机文件(再次假设 128 位哈希和 10^10 个文件，您将有更少的文件和更长的哈希)。 2^18 是一个相当大的数字，您可以暴力破解的速度受网络和服务器的限制。一个简单的在 x 次尝试后将用户锁定的策略可以完全关闭这个漏洞(这就是许多系统实现这种策略的原因)。构建一个安全的系统很复杂，需要考虑的点很多，但这种方案可以是完全安全的。

希望这是有用的...

编辑:另一种思考方式是，实际上每个加密或身份验证系统都依赖于某些安全概率非常低的事件。例如我可以很幸运地猜到 512 位 RSA key 的主要因素，但不太可能认为系统非常安全。