如何安全地对客户端加密的文件进行重复数据删除？答案

【问题标题】：How to safely de-duplicate files encrypted at the client's side?如何安全地对客户端加密的文件进行重复数据删除？
【发布时间】：2011-09-19 18:27:13
【问题描述】：

Bitcasa 声称它以固定费用提供无限存储。

根据TechCrunch interview，Bitcasa 使用客户端聚合加密。因此，未加密的数据永远不会到达服务器。使用收敛加密，加密密钥来源于被加密的源数据。

基本上，Bitcasa 使用哈希函数来识别不同用户上传的相同文件，以便在他们的服务器上只存储一次。

我想知道，提供者如何确保不会将两个不同的文件映射到同一个加密文件或同一个加密数据流，因为 hash functions 不是 bijective。

技术问题：我必须实施什么，才能避免发生这样的冲突。

【问题讨论】：

【解决方案1】：

大多数重复数据删除方案都假设哈希冲突不太可能发生，以至于可以忽略它们。这允许客户端跳过重新上传已经存在的数据。当您有两个具有相同哈希的文件时，它确实会崩溃，但这不太可能偶然发生（而且您确实选择了一个安全的哈希函数来防止人们故意这样做，对吧？）

如果您坚持绝对确定，则所有客户端都必须重新上传他们的数据（即使它已经在服务器上），并且一旦重新上传这些数据，您必须检查它是否与当前存在的数据相同。如果不是，您需要选择一个新 ID 而不是使用哈希（并发出在 SHA1 中发现冲突的警报！）

【讨论】：

使用多个散列函数也大大减少了冲突的机会。现在很容易找到 MD5 冲突，但要找到同时在 md5 和 sha1 中发生冲突的两个文件要困难得多，更不用说 md5+sha1+sha256+etc....
@Marc，与其混合临时的哈希函数，不如从一开始就选择一个更安全的函数，比如 SHA512（或者，一旦标准化，SHA-3）
广度防御 - 假设即使 SHA-3（如果/当它被标准化）也可以被完全破坏并不是不合理的。通过使用多个哈希，如果您将所有鸡蛋都放入一个破碎的哈希篮中，您仍然可以获得完全消失的安全边际。但是，是的，从一个好的（迄今为止）完整的哈希开始仍然是一个好主意。
谢谢，@bdonlan。只是想确认一下，没有发明任何神奇的功能，在这里可以提供帮助......
@SteAp 要击败pigeonhole principle，它必须是一个扭曲现实的魔法函数：如果函数输出的位数少于输入，则必须存在潜在的冲突。