允许多个人解密文档而不共享加密密钥的模式？

#1 楼

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

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

每个用户U都有一个密钥KU。因此，如果您需要用户D，U和V可以访问文档D，则可以存储EKD（D）（使用文档密钥对D进行加密）以及EKU（KD），EKV（KD）和EKW（KD） ）（用用户U，V和W的密钥对密钥KD进行加密）。这些“加密密钥”的大小很小（无论文档大小如何，只有几十个字节），因此可以扩展。

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


从服务器检索EKU（KD）；
使用他自己的私钥来解密并恢复KD；
用V的公钥加密KD，得到EKV（KD）。

该方案的优点在于，此过程不需要V，因为只有V使用公钥。

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


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

#2 楼

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

根据法律，我们应政府的要求能够解密磁盘上的所有文档；


哇。我真的希望您打算通知您的用户，您将为执法部门提供服务的后门，以便他们有足够的时间从服务中删除其数据。这将是符合道德和光荣的事情。

如果您被迫这样做，例如收到国家安全信（National Security Letter）的通知，并且由于堵销令而被禁止发言，那么您的选择就受到限制：


让公司中的某人匿名将此信息泄漏给免费新闻（以后您的服务将被后门使用）。
出于未指明的原因关闭该服务。给您的用户几周的时间来下载他们的数据，然后再将其永久删除。
将您的公司，在线服务和员工转移到没有严厉的监视法律的国家。

听起来就像您已经有了一项安全的服务，并吸引了一些注重隐私的用户一样。任何事情都比故意安装后门进行执法并拧紧用户更好。据您所知，一旦您提议的用于执法的系统就绪，他们就会向您发送所有用户数据的保证书。

您最好关闭公司，关闭您的系统钱并开始新的创业，但这一次做得很好。这是我的建议：


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

#3 楼

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

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


每个用户都有一个公钥/私钥对
每个文档都被赋予一个唯一的对称密钥，该文档使用该对称密钥进行加密并上传到支持存储容器。这称为文件密钥
每当授予用户访问文件的权限时，文件密钥就会使用用户的公共密钥进行加密

特别是您希望能够提供文件-依法必须遵守的关键。这是ownCloud的选择功能，其中每个文件密钥还使用系统管理员的公共密钥加密。使用ownCloud时，该功能的目的是使用户可能忘记了其私钥的密码短语，并且可以要求管理员再次授予他们对文件的访问权限。

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

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

#4 楼

作为对您问题的直接答案，汤姆·里克（Tom Leek）的答案就在现场。

但是，我建议您采用其他方法：放弃按用户加密。

您仍然会使用网络加密（HTTPS），密码散列以及（如果需要）服务器上的全盘加密。但是，请勿使用任何其他加密方法。您的应用程序仍将决定哪些人可以查看特定文档：首先上传的用户，出于法律目的的管理员以及与他们共享文档的所有用户。通过这种安排，很容易满足您的所有需求。

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

#5 楼

我知道已经解决了这个问题，但是...

我必须在我的网站上做一些非常相似的事情。

文档是加密的，但可以与其他用户共享。

在英国，我必须与安全服务共享安全细节（如果有此要求），但前提是我拥有​​这些细节。我没有访问权限，所以这不是问题。
（我也不允许通知用户已请求详细信息-自由的代价！）

每个用户具有用于保护其文档的非对称密钥对。公钥以纯文本存储，而私钥则使用河豚加密，并从用户密码中获得128位密钥。

当用户想要共享文档时，它将被解密并复制使用目标用户的公共密钥进行制作和加密，该操作很容易以纯文本格式进行。
目标用户登录后，便可以使用其安全私钥对文档进行解密。

很明显，如果与多个用户共享，则每个用户都必须有一个副本。

#6 楼

由于上述要求迫使加密本质上是用于“演出”（安全区？）和基本的盗窃保护，而不是安全的文档级保护，因此，我建议使用LUKS或类似方法进行基本的全磁盘加密。这样，您就拥有了整个存档的主密钥，并且可以使用基于非加密的方案来控制每个用户对各种文档的访问。按文档加密确实不会给您带来任何好处，只是要满足＃1的麻烦。

此外，我想在上面列举第二个反间谍的答案。至少，提议的服务是高度不道德的，在某些辖区中，根据服务条款/您向用户披露的内容，甚至会被视为欺诈。