Security 服务器上的密文

是否有任何协议允许两名访问者通过我的网站进行安全通信，而不让我阅读他们的信息？

请谷歌提供类似PGP/GPG的端到端加密。对于基于客户端浏览器的实现，您可能希望签出

我只是在谷歌上搜索了一下，无法判断它是否真的安全（没有将您的私钥发送给任何人）。我只想给你一点开始

---

编辑：看起来它确实将客户端私钥发送到您的服务器以执行基于服务器的加密。这不是你想要的。但是我确信GPG的JavaScript实现是可能的，即使我不知道是否有人已经实现了它；例如，如果您的服务器是受SSL/TLS保护的通信中的链路，则会发生这种情况。
参与者使用公开密钥加密方案来商定秘密对称密钥；然后用于加密他们的通信

参与者也可以简单地用指定接收者的公钥加密他们的消息。这样，只有预期的接收者才能解密消息。这不是一个非常先进的方案，可能容易受到攻击。（除其他外，如果窃听者能够准确猜测发送的内容，他可以使用预期收件人的公钥加密该消息，并查看结果是否与发送的内容匹配）

---

有很多关于密码协议的文献；首先，这里有一篇关于的维基百科文章。

如果我们谈论的是不可能，那么s.L.Barth回答的第二部分将实现这一点，但密钥交换必须通过其他方式完成。这可以是电话、电子邮件，甚至是其他网站，但如果是通过您的网站完成的，那么它将向用户开放。你可以告诉你的用户这样做，但实际上你无法帮助他们这样做

可能有一个javascript库可以实现GPG加密，因此您所要做的就是确保每个消息在发送到web服务器之前都在浏览器中加密。只要你愿意，你可以储存这些信息，它们是加密的。只有拥有正确私钥的用户才能对其进行解密

到处都有网站使用的SSL和TLS容易受到中间人攻击。我们没有听到很多关于这些攻击的原因是大多数中间人都是值得信赖的，所以攻击根本不会发生。最近撤销的CA证书和其他证书正是因为伊朗政府被抓到充当中间人，解密本国公民的SSL流量

如果您对防止好奇的系统管理员随意窥探感到满意，那么也可以通过您的网站进行密钥交换

还有一件事：安全很难

---

即使使用众所周知的加密技术，实现中存在漏洞的可能性也非常接近1。这并不意味着那些好奇的系统管理员将能够意外地读取消息，但它确实意味着一个坚定而熟练的对手将能够找到进入的方法。一旦你负担得起，你应该聘请一位专家重新设计或至少检查你的协议和实现。

一般来说，只有在用户之间有某种方式相互识别（或至少在一个方向上）时，你才能在用户之间建立这样一种安全的链接，而不需要阅读和/或修改他们的消息

这可能是一个共享秘密（如密码短语）或一个已知的公钥（或由一个已知的CA认证），其中另一个拥有相应的私钥

在此基础上，我们可以构建一个安全协议（使用密钥交换，然后在两个方向上使用MAC对称加密），就像TLS一样。（另一种经常用于即时消息传递的方式是OTR协议。）

如果没有办法确定另一个端点，你最终会得到一种允许中间人攻击的方法。没有证书的SSL/TLS，或中间人知道相应私钥的证书的SSL/TLS是不安全的，其他类似的加密方案也是如此

另一个问题是，你说我的网站的访问者。这看起来像是在JavaScript中实现客户端加密，从您的网站交付。不要这样做。。。如果访问者不信任您不读取他们的数据，那么他们也不应该信任您向他们提供非恶意JavaScript，这可能会实现一些您声称不具备的功能，再次允许MITM，甚至直接向您发送数据副本

---

更多细节将在中讨论（从稍微不同的角度）。

使用TLS是否意味着两个用户都需要在线？我想实际存储消息。不，您可以使用相同的算法交换对称密钥，无论参与者何时登录-只要步骤按正确顺序执行。@destructo_gold如果您将消息存储在服务器上，我强烈建议使用PGP。它的设计目的是加密电子邮件，这几乎是相同的用例。但是，用户必须在他们的机器上永久保存一些数据（私钥）。我希望理想情况下使用PGP，以便密钥能够得到认证，但我不知道有任何基于浏览器的实现？您的示例说明了为什么教科书RSA在语义上不安全。实际上，RSA加密与随机填充一起使用，这意味着攻击者不仅要猜测消息，还要猜测（或暴力）用于生成填充的随机数。但是RSA通常不会直接用于加密消息，而是用于加密对称密钥，然后与AES或类似的方法一起用于实际消息。+1，尽管我对cry中的缺陷并不悲观