我没有仔细考虑细节，但是如果使用文件内容的安全哈希作为密钥，那么任何（并且只有）“知道哈希”的客户端都可以访问该内容。

本质上，云存储将充当散列函数的集体部分（实际上非​​常稀疏）彩虹表，允许它“反转”。

来自文章：“即使 RIAA 和 MPAA 敲开 Bitcasa 的大门，传票在手，Bitcasa 所拥有的只是一组加密位，无法解密它们。” -- true 因为 bitcasa 不保存 objectid/filename-to-hash/key 映射；只有他们的客户做（客户端）。如果 RIAA/MPAA 知道相关文件的哈希值（众所周知，例如特定歌曲 MP3），他们将能够解密并证明您有副本，但首先他们需要知道哪个云存储对象/文件保存了哪首歌。

当然，客户需要保留每个云存储对象的哈希值及其本地名称，以便能够访问和解密它。

关于文章中声称的其他一些功能：

• “压缩”——不能在服务器端工作（加密的内容不能很好地压缩），但可以在加密之前应用到客户端
• “可在任何地方访问”——如果 objid-to-filename-and-hash/key 映射仅在客户端上，则文件在其他设备上无用，这限制了云存储的实用性。可以通过例如存储 objid-to-filename-and-hash/key 元组的集合来解决，客户端用密码加密。
• “获得专利的重复数据删除算法”——为了证明专利的合理性，必须进行比上述更多的事情——可能是在一个块而不是文件级别进行重复数据删除？
• RIAA/MPAA 将能够附带传票和他们怀疑人们拥有的任何歌曲/电影的加密副本。然后，Bitcasa 将能够确认该文件是否已存储。他们将无法解密它（没有 RIAA/MPAA 给他们哈希/密钥），并且（特别是如果他们没有执行每用户配额，因为他们提供“无限存储”）他们可能没有保留日志哪些用户上传/下载了它。但是，我怀疑他们可能被要求删除文件（根据 DMCA 安全港规则）或可能保留内容，但随后记录任何将来上传/下载它的帐户。

您链接到的商业广告和公司网站都非常缺乏信息；并且挥舞“20 项专利”作为能力证明是很奇怪的：专利并不能证明技术好不好，只是有些人把几千美元押在了技术会卖得好的想法上。

让我们看看是否有办法实现这些承诺。

如果数据是在客户端加密的，那么该文件必须有一个密钥K _f。关键是 Bitcasa 不知道K _f。为了实现重复数据删除和缓存，更重要的是共享，每个加密给定文件f的用户最终都必须使用相同的K _f。有一个绝妙的技巧是使用文件本身的散列，以及适当的散列函数（例如 SHA-256），如K _f。使用这个技巧，相同的文件将始终以相同的加密格式结束，然后可以随意上传和重复数据删除。

然后，用户将拥有所有文件的所有K _f的本地存储（在他的计算机上），以及文件 ID。当用户 A 想与用户 B 共享文件时，用户 A“右键获取共享 URL”并将其发送给 B。推测该 URL 包含文件 ID 和K _f。文中说用户 A 和 B 都必须是注册用户才能进行共享，因此“URL”可能在 B 的机器上被某些软件截获，该软件从该“URL”中提取 ID 和K _f，下载来自服务器的文件，并使用其新获得的K _f知识在本地对其进行解密。

为了获得额外的弹性和可用性，某些用户的一组已知密钥K _f也可以存储在服务器上——因此您只需要“记住”一个K _f密钥，您可以将其从一台计算机传输到另一台计算机.

所以我说 Bitcasa 承诺的事情是可能的——因为我知道如何去做，而且这里没有什么真正新的或技术先进的东西。我不能声称这就是 Bitcasa所做的，只是我会这样做。“硬”部分是将其集成到现有操作系统中（以便“保存文件”触发加密/上传过程）：有些工作，但几乎不值得专利，更不用说 20 项专利了。

请注意，使用K _f = h(f)意味着您可以尝试对文件内容进行详尽搜索。无论如何，这在具有重复数据删除的服务中是不可避免的：通过“上传”一个新文件并仅计时操作，您可以知道该文件是否在服务器端已知。

Bruce Schneier 在 5 月谈到了这个主题http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html与那一周的 Dropbox 问题有关。TechRepublic 提供了一份很棒的 7 页白皮书，以电子邮件注册的价格在http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the-case-of-云存储中的重复数据删除/3333347。

本文重点介绍云重复数据删除中可用的侧信道和隐蔽信道攻击。这些攻击利用了跨用户重复数据删除。例如，如果您知道 Bob 正在使用该服务并且他的模板构建的工资合同在那里，您可以制作相同的版本，直到您达到他的工资。文件上传所用时间表示成功。

当然，您的保护是在使用服务之前进行加密。然而，这将阻止服务的成本节约，使其在经济上可行，因为它将消除几乎所有重复数据删除机会。因此，该服务不会鼓励选择。

除了这里的其他好的答案，我想向您指出以下两篇最近发表的学术论文：

• Martin Mulazzani、Sebastian Schrittwieser、Manuel Leithner、Markus Huber 和 Edgar Weippl，地平线上的乌云：使用云存储作为攻击向量和在线 Slack Space，Usenix Security 2011。

  本文介绍了 Dropbox 如何进行重复数据删除并识别对该机制的攻击。他们提出了一种新的方法来防御其中的一些（但不是全部）攻击，基于要求客户端在被允许访问文件之前证明他们知道文件的内容（而不仅仅是它的哈希）。

• 丹尼·哈尼克、本尼·平卡斯、亚历山德拉·舒尔曼-佩莱格。 云服务中的侧通道，云存储中的重复数据删除案例，IEEE 安全与隐私杂志。

  本文分析了执行重复数据删除的三种云存储服务（Dropbox、Mozy 和 Memopal），并指出了随之而来的安全和隐私风险。他们提出了一种针对这些风险的新防御方法，基于确保仅在文件有许多副本时才对文件进行重复数据删除，从而减少信息泄漏。

这些论文似乎与您的问题直接相关。他们还表明，对于简单的重复数据删除风险，在重要的缓解措施方面存在创新空间。