您发现了另一个平衡安全性与可用性的示例。如果您想要真正的 E2E 加密，最终用户需要对他们的密钥和可能的消息备份负责。句号。

如果您偏离了这条路，您将落入灰色地带，所有内容都经过 E2E 加密，但某些功能允许恢复消息。换一种说法：即使流量被加密，软件仍然可以访问旧消息——这违背了 E2E 的观点。例如，WhatsApp 选择实现用户要求重新发送所有已通过（已接收）消息的功能，而发送者并不知道这一点。如果用户真正更换了他们的智能手机，他们会“自动”恢复所有旧消息。太好了……但这意味着该应用程序包含系统要求将所有内容发送到流氓地址所需的所有内容。吞咽...

话虽如此，您将不得不在这里做出一些行政决策。如果您和您的用户知道任何恢复选项确实会降低整体安全性，那就没问题了。不要太担心——虽然大多数用户坚持对他们发送或接收的所有内容进行 E2E 强加密，但对于大多数用户来说，能够恢复他们的消息比完全阻止攻击者访问它们更重要......无论好坏，大多数用户都不了解E2E 加密和强密码学的完整定义，并且通常对它们的声称感到满意

如果用户更换设备，重新安装应用程序，存储在客户端的私钥将丢失。我知道我可以为未来的消息创建新的密钥对，但我怎样才能恢复旧的？

为什么需要恢复旧的？生成新密钥并分发。他们的私钥不应离开生成它的设备。如果您需要消息历史记录，请将其本地存储在用户设备上，而不是在您的服务器上 - 并为用户提供备份选项。这大致就是 Signal 所做的。

我认为将私钥存储在服务器中，但它根本不安全。我想在用用户密码加密后存储私钥，因为我不知道用户密码，所以它会很安全，但是如果用户丢失他/她的密码并使用“丢失我的密码电子邮件”重新创建它也会失败。

不要为用户存储密钥。时期。这使得 E2E 有点毫无意义。

另一个问题是，如果发生一些法律问题，我无法将聊天日志交给警方，因为我没有解密的消息，或者我不知道如何解密它们，因为我没有私钥。

你不能交出你没有的东西。如果消息是 E2E 的，并且您不存储它们，那么您将无能为力。这就是 E2E 的重点——提供商没有消息，也无法将它们透露给任何人。

我建议您也看看其他平台（如Matrix和Keybase）的实现。在服务器上存储私钥完全破坏了使用 e2ee 的意义，因为服务器现在基本上可以查看所有聊天记录。

我建议使用某种纸密钥/种子短语（检查BIP39），可以打印/写在纸上，甚至可以记住，并清楚地表明丢失此密钥可能会导致无法访问旧聊天。对于那些不希望从 e2ee 获益的人，您可以选择允许用户对密钥进行云备份（我强烈反对这样做）。如果是这种情况，我鼓励通知其他用户。

此外，我建议检查 Matrix.org 的Multi device cross signing实现，以获取有关如何允许多设备支持的指南。

我还建议阅读 keybase.io 的博客文章 [ 1 ][ 2 ][ 3 ][ 4 ][ 5 ]，了解他们的系统是如何工作的。

就我个人而言，我并没有真正看到重新发明轮子的意义，matrix.org 的实现完全符合您的要求，您可以使用自己的功能/webapp（将 matrix.org 视为电子邮件，将您的应用视为 Gmail）。

前面的答案已经涵盖了大多数好的选项。还有一个值得一提的选项：允许用户导出私钥，并将其存储在他们认为安全的地方，也许在他们的密码管理器中。这种方法有几个缺点，但也有一些优点：它实现了可恢复性，而不会完全失去 e2ee 的意义，因为您的服务器将永远无法访问私钥。另一方面，它确实将私钥的安全性留在了用户手中，甚至比以前更多，并使他们容易受到网络钓鱼攻击，有人可能会试图诱骗他们将私钥发送给敌对方。您必须考虑预期用户群的专业知识水平。如果您针对的是来自该社区的人，这种方法可能会很好，