您需要每个文档的密钥，而不是每个用户的密钥。好吧，您还需要每个用户的密钥，但这是另一回事。

即，每个文档D都用密钥K _D加密。该密钥是在文档第一次导入系统时随机生成的。每个文档都有自己的密钥。不能从任何其他文档的密钥中推断出文档的密钥。

每个用户U也有一个密钥K _U。因此，如果您需要用户U、V和W可以访问文档D，那么您将存储E _{K D} (D)（使用文档密钥对D进行加密）以及E _{K U} (K _D )、E _{K V} (K _D )和E _{K W} (K _D ) （用用户U的密钥加密密钥K _D, V和W )。这些“加密密钥”的大小很小（几十个字节，与文档大小无关），因此可以按比例放大。

为了使事情更实用，您可能需要对用户密钥使用非对称加密： D的加密使用方便的对称系统（例如 AES），但“用户密钥”将是 RSA 类型（或其他类似的算法，如 ElGamal） . 这样，如果用户U想与用户V共享文档D，那么他：

1. 从服务器检索E _{K U} (K _D )；
2. 使用他自己的私钥解密并恢复K _D；
3. 用V的公钥加密K _D，得到E _{K V} (K _D )。

这个方案的美妙之处在于V不需要出现在这个过程中，因为只使用了V的公钥。

那时，您真正拥有的是OpenPGP，一种主要用于安全电子邮件的格式。电子邮件具有这种“共享属性”（一封电子邮件可能会发送给多个收件人）并且是异步的（当您发送电子邮件时，收件人不一定立即可用）。建议您重用 OpenPGP，这是一种已被许多密码学家审查过的格式，并且已经存在实现。

当您拥有共享机制时，您可以简单地将自己作为每个文档的隐式收件人，并且您可以阅读所有内容。无论法律要求如何，请务必通过“使用条件”通知用户，您可以在技术上阅读所有内容；否则他们可能会因缺乏警告而起诉您。

但是，我们有两个新的要求要实现：

根据法律，应政府要求，我们必须能够解密磁盘上的任何文件；

哇。我真的希望您计划通知您的用户，您将为执法部门提供后门服务，以便他们有足够的时间在此之前从您的服务中删除他们的数据。那将是道德和光荣的事情。

如果您被迫这样做，例如通过国家安全信函，并且由于禁言令而不允许您说出它，那么您的选择将受到限制：

1. 让公司中的某个人匿名将此信息泄露给自由媒体（将来您的服务将被后门）。
2. 因不明原因关闭服务。给您的用户几周的时间来下载他们的数据，然后这些数据将被永久删除。
3. 将您的公司、在线服务和员工迁移到没有严厉监控法律的国家。

听起来您已经获得了安全服务，并吸引了一些注重隐私的用户。任何事情都比为执法而故意安装后门并欺骗用户要好。据您所知，一旦您提议的系统用于执法，他们就会向您发送所有用户数据的搜查令。

你最好关闭公司，拿走你的钱并开始新的冒险，但这次做得正确。以下是我的建议：

• 在没有这些法律的国家/地区创办您的公司。在那里也托管您的服务器和用户数据。
• 使用开源客户端，以便用户信任在其计算机/设备上运行的软件。如果因为有人会注意到而被当局强迫，将来隐藏后门将非常困难。
• 所有私有数据加密密钥都存储在客户端，从不在服务器上。只有加密的数据存储在服务器上。所有的加密和解密都是在客户端完成的。服务器只保存加密数据。用户有责任备份自己的私钥。然后，您的公司实际上无法响应未来的 NSL 请求，因为您没有密钥。
• 为了与服务器进行身份验证并让用户从他们的帐户存储和下载加密数据，请设置某种每用户公钥身份验证协议。也许服务器持有每个用户的公钥。用户持有私钥，然后对每个数据上传和对服务器的请求进行签名。每个客户端都可以将服务器的公钥嵌入（固定）到其中，以验证从服务器下载的响应和加密数据。
• 为了与其他用户共享文件，用户可以使用新的对称密钥重新加密他们的文件，并使用公钥交换与系统上的其他用户共享该密钥。您的服务可以为他们处理公共密钥的共享。但是，如果用户不能完全信任服务器并且服务器位于具有敌对监视法律的国家/地区，则这是危险的。用户不知道服务器是否为其他用户提供了假的或真实的公钥，因此他们很容易受到 MITM 攻击。这将是执法部门用来访问其他用户共享文件的未加密数据的一种方式。在这种情况下，如果用户知道他们自己的公钥并且可以在他们希望与其他用户共享数据时私下与其他用户共享，那将更加安全。
• 使用不易受量子计算机攻击的较新的公钥算法。没有 RSA、DSA 或椭圆曲线。
• 使用关心隐私且不喜欢大规模监视的作者提供的更新的对称密钥和哈希算法。例如，Bruce Schneier 和 Daniel J. Bernstein。

上面 Tom Leek 概述的解决方案已由开源云文档存储ownCloud实现。此处概述了加密模型。

正如在其他答案中所指出的，您可以使用OpenPGP/GPG执行相同的操作，我在相关问题的答案中对此进行了概述。简要重复标准方法：

1. 每个用户都有一个公钥/私钥对
2. 每个文档都有一个唯一的对称密钥，使用该密钥对文档进行加密并上传到后备存储容器中。这称为文件密钥
3. 每当授予用户访问文件的权限时，文件密钥都会使用用户公钥加密

具体来说，您希望能够在法律强制要求时提供文件密钥。这是 ownCloud 的一个可选功能，其中每个文件密钥也使用系统管理员的公钥加密。使用 ownCloud，该功能的目的是用户可能忘记了其私钥的密码，并且可以要求管理人员再次授予他们对文件的访问权限。

需要注意的一点是，ownCloud 使用常规数据库存储用户/组数据和文件元数据。实际的文件 blob 可以存储在本地，也可以存储在 Amazon S3 或 Google Drive 等外部提供商上。你可以采取同样的方法；让客户端首先加密并写入使用自己的密钥加密的管辖范围外的外部 blob 存储，然后仅将 url（通常是 128 位 GUID）写入您的系统。虽然这在系统复杂性方面远非理想，但它很可能使您不必遵守危险和压迫性的法律；因为您只能移交指向数据的指针。

我认为至少有一个正在实施这种极权主义法律的国家正在迫使所有离岸云提供商将其服务器移至该国，以供在该国居住的用户使用。在这种情况下，您最后的手段是让系统用户加密并写入他们自己的本地网络驱动器，并在您的系统中存储文件路径。然后由客户对此类数据进行异地备份。

作为对您问题的直接回答，Tom Leek 的回答是正确的。

但是，我建议您采用不同的方法：放弃按用户加密。

您仍将使用网络加密 (HTTPS)、密码散列，如果需要，还可以在服务器上使用全盘加密。但是，不要使用除此之外的任何加密。您的应用程序仍然决定谁可以查看特定文档：首先上传的用户、出于法律目的的管理员以及与他们共享文档的任何用户。在这种安排下，很容易满足您的所有要求。

那么为什么我建议放弃每用户加密呢？因为它复杂且难以实现，而且它实际上并没有增加太多的安全性。您还没有真正解释您想要为每用户加密带来什么好处，但我认为这是为了确保文档安全，以防服务器受到电子或物理损害。这两个都应该是极端事件：你应该采取标准的预防措施，比如防火墙来防止这些事情发生。但是，如果确实发生了这样的极端事件，实际上高级攻击者无论如何都可以获取您用户的文档。他们静静地等待，等待您的用户登录，然后获取密码并解密文件。