Hash 依靠散列来识别文件有多安全？

我正在设计一个基于LAMP堆栈的存储云软件

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

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

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

这个字符串保证是唯一的，因为在第一个级别上类似于用户在AmazonS3和Google存储中注册的“bucket”

我的计划是将文件存储为客户端定义路径的散列

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

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

我听说GIT也使用哈希和修订标识符

我知道碰撞的几率很低，但也有可能

我无法判断这一点。你会不会依赖散列来达到这个目的

---

我还可以给我们一些路径编码的规范化。可能是base64作为文件名，但我真的不希望这样，因为它可能会变得混乱，路径可能会变得太长，并且可能会有其他复杂情况。

假设您有一个具有“完美”属性的哈希函数，并假设加密哈希函数的方法与适用的理论相同。这意味着，给定最大数量的文件，您可以通过使用更大的哈希摘要大小使冲突概率尽可能小。SHA有160位，所以对于任何实际数量的文件，冲突的概率都将是零。如果查看链接中的表，您将看到包含10^10个文件的128位哈希的冲突概率为10^-18

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

需要关注的一件事是哈希函数的选择及其可能存在的漏洞。是否有其他身份验证，或者用户只是提供路径并检索文件

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

---

编辑：考虑这一点的另一种方式是，实际上每个加密或身份验证系统都依赖于某些安全概率非常低的事件。e、 g.我可以幸运地猜测512位RSA密钥的主要因素，但系统不太可能被认为是非常安全的。

虽然冲突的概率可能非常小，但想象一下，仅仅因为发生哈希冲突，就将一个客户的高度机密文件提供给其竞争对手

=营业结束

我宁愿对发生冲突时不太重要的事情使用哈希；-）

如果您有一个数据库，请将文件存储在guid下——因此不是递增索引，而是一个适当的全局唯一标识符。在分布式碎片/高可用性等方面，它们工作得很好

---

想象一下最坏的情况，并假设它会发生在你被《连线》杂志评为一家了不起的初创公司后的一周。。。这是一个很好的算法压力测试。

对我来说，这听起来像FUD。