我相信只有当第三方参与手动过程时才有可能满足这些要求。例如：
我想从流程中消除第三方。但是，我还没有想出一个方法来做到这一点。帐户中的每个人都需要安装相同的公钥/私钥。由 Alice 和私钥签名的文档可以被所有其他用户验证，因为他们也有相同的密钥对。
问题：可以随时添加新用户，因此公钥/私钥需要存储在中央位置，以便这些新用户可以获得密钥。如果该位置被泄露，黑客可以上传新文档并使用泄露的私钥对其进行签名。
简而言之，将私钥存储在中央服务器上似乎类似于存储纯文本密码。
那么，有没有办法在不断变化的用户之间安全地共享集中存储的文档？
正如@AviD 指出的那样，“安全”是一个广泛的术语，因此可以调用几个属性。在这里，我将专注于保密。
因此，您希望某些人共享一些文档，这些文档对于该组之外的人必须保持不可读，这样您就可以在该组中添加或删除一些人。需要注意的一点是，从概念上讲，你不能强迫人们变得失忆。因此，如果小组中的某个成员可以在某个时候阅读一份文件，那么他完全可以在某处保存一份副本。因此，撤销用户的访问权限就是不让该用户读取新文档；对于旧文件，这“为时已晚”。鉴于这一点，一个可能的解决方案如下所示：
每个文档都使用随机密钥K（每个文档的新密钥）对称加密。
每个用户都有自己的公钥和私钥对，适用于非对称加密（例如 RSA 或 El-Gamal 密钥对）。
每个文档都有一个标题，其中包含使用每个被认为有权阅读该文档的用户的公钥对K进行的加密。
要撤销用户，只需停止使用该用户的公钥加密新文档的K。
要追溯添加用户，请使用该用户的公钥计算K的加密，对于必须授予访问权限的每个旧文档；当然，这只能由可以访问所述文档的另一个用户来完成（即获取K）。
上面的系统正是OpenPGP所描述的（有关开源实现，请参阅GnuPG ）。这是为了安全的电子邮件发送，但不管实际的传输介质如何，它都可以工作，这可能是一个共享的存储区域。
上述方案存在缺陷：
生成文档的人必须知道应该能够访问文档的人员列表。这不是绝对要求；我们可以想象一个文档从一个用户传播到另一个用户的设置，每个用户为下一个用户添加加密的K。
每个文档都有一个标题，它随着系统中的用户数量线性增长；对于相当安全的 RSA 加密（2048 位 RSA 密钥），每个用户需要 256 个额外字节。根据具体情况，开销的范围从完全可以忽略不计到可笑的难以忍受。
任何人都可以通过查看加密文档的标题来推断可以访问该文档的用户列表。
用户拥有公钥，这意味着以安全方式分发公钥的常见问题——即同时避免篡夺者。如果有很多用户，则解决方案涉及公钥基础设施 ( PKI )；OpenPGP 使用一种被称为“信任网络”的去中心化 PKI。X.509是另一个 PKI 标准，具有金字塔形的集中式结构。两者都擅长管理简单的案例，不擅长扩大规模。
另一个非常不同的安全文档共享方案是使用蓝光光盘完成的，具有AACS复制保护。安全模型是有一种中央权威，但离线；每个用户（蓝光播放器）都有自己的对称密钥，中央机构也知道。当权威机构发布一个新文档（例如，一部新电影）时，该文档使用自己的对称密钥K进行对称加密，并且该密钥K通过广播加密提供给所有玩家。权威想要将K分配给N 个用户，其中N很大，同时使用相对较少的带宽（N可以达到数亿的数量级，但光盘上没有那么多可用空间），能够追溯添加新用户而无需任何特定于文档的传输（一旦构建和分发光盘，您就无法修补光盘） ，并且仍然有可能撤销特定用户。AACS 中使用的广播加密的数学优点在于它只需要每个磁盘上的大小O(log N)，再加上O(R)，其中R是撤销用户的数量。可以随意添加新用户。这个想法是，只有当玩家密钥似乎已被披露并开始在流氓玩家中被广泛复制时，才会撤销“用户”；希望（也就是说，蓝光联盟希望如此），单个播放器破解成本将保持足够高，以至于必须撤销不超过几十个这样的密钥。
广播加密使用双嵌套树的结构，在这里描述有点太长了。有关详细信息，请参阅本文。
这里显然是对广播的话题现有的一些研究非对称加密，从而避免了为它知道的所有键中央权威的需要。我不知道目前是否已知有这种效果的良好、安全的方案。
是的，有这样的计划。它由ownCloud 实现，它是一个开源的云文档存储产品。这里描述了它的加密安全模型。总结一下：
ownCloud 方案不需要受信任的第三方。它可以完全通过客户端加密来完成。所有需求都是中央商店。我们可以使用 FTP 服务器和命令行GPG工具：
信任是标准的 GPG 模型。然后文档创建者对文档进行加密和签名。读者可以检查公钥的指纹并通过电话确认。
根据托马斯的回答，撤销对文档的访问权限不能将其从读者的脑海中抹去，也不能从他们所拍摄的任何副本中抹去。在上面的简单案例概述中，如果我们想要锁定一些以前被授权访问该文档的人，我们将不得不制作该文件的副本并使用新的文件密钥对其进行加密。如果我们只通过将补丁格式增量上传到我们正在编辑的文档来修改文件，我们实际上可以做得更好。如果我们想减少阅读器的集合，可以使用原始文件密钥对这些增量文件进行加密，以保持与新文件密钥相同的可见性。
我们实际上并不需要每个文档都有一个文件夹。如果我们采用仅通过将补丁格式增量上传到文件来使每个版本不可变的方法，我们可以使用仅附加文件格式写入文件的后面。使用阅读器公钥加密的文件密钥也可以附加到文件中。更重要的是一个能够适应并行编辑文档格式如treedoc双方加密和签名与存储在treedoc格式中的文件密钥的用户编辑。