The*_*can 6 hash identity guid
我正在LAMP堆栈上设计存储云软件.
文件可以有一个内部ID,但是它们有很多优点来存储它们,而不是在服务器文件系统中使用递增id作为文件名,而是使用散列作为文件名.
如果应当对当前集中的数据库进行分片或分散或者应该设置某种主 - 主高可用性环境,那么作为数据库中的标识符的散列将具有很多优点.但我还不确定.
客户端可以在任何字符串下存储文件(通常是某种路径和文件名).
这个字符串保证是唯一的,因为在第一级是类似"桶"的东西,用户可以在Amazon S3和Google存储中注册.
我的计划是将文件存储为客户端定义路径的哈希值.
这样,存储服务器可以直接为文件提供服务,而无需数据库询问它是哪个ID,因为它可以动态计算哈希值,从而计算文件名.
但我害怕碰撞.我目前考虑使用SHA1哈希.
我听说GIT也使用哈希值和修订标识符.
我知道碰撞的可能性非常低,但可能.
我无法判断这一点.您或者您不会为此目的而依赖哈希吗？
我还可以对路径的编码进行一些规范化.也许base64作为文件名,但我真的不希望这样,因为它可能会变得混乱,路径可能会变得太长,可能还有其他并发症.
Guy*_*ton 10
假设你有一个具有"完美"属性的哈希函数,并假设加密哈希函数接近,那么适用的理论与适用于生日攻击的理论相同.这就是说,给定最大数量的文件,您可以通过使用更大的散列摘要大小使碰撞概率尽可能小.SHA有160位,因此对于任何实际数量的文件,冲突概率几乎为零.如果你查看链接中的表,你会看到一个128位散列,10 ^ 10个文件的碰撞概率为10 ^ -18.
只要概率足够低,我认为解决方案是好的.与行星被小行星撞击的概率,磁盘驱动器中无法检测到的错误,在内存中翻转的位等等相比 - 只要这些概率足够低,我们就不会担心它们,因为它们"永远不会"发生.只要采取足够的余量,并确保这不是最薄弱的环节.
需要关注的一件事是哈希函数的选择以及它可能存在的漏洞.是否有任何其他身份验证或用户只是提出路径并检索文件？
如果您考虑攻击者试图暴力破坏上面的场景,他们需要请求2 ^ 18个文件才能获得存储在系统中的其他随机文件(再次假设128位散列和10 ^ 10个文件,您将拥有更少的文件和更长的哈希).2 ^ 18是一个相当大的数字,你可以强制这个速度受到网络和服务器的限制.在x尝试策略之后简单地锁定用户可以完全关闭此漏洞(这就是许多系统实现此类策略的原因).构建安全系统很复杂,需要考虑很多要点,但这种方案可以非常安全.
希望这很有用......
编辑:另一种思考方式是,几乎每个加密或认证系统都依赖于某些事件的安全性很低的事件.例如,我很幸运,可以猜测512位RSA密钥的主要因素,但系统不太可能被认为是非常安全的.