即时通信 IM 端到端加密真的可以做到吗？

你们必须有直接信息交换或者共同信任的中间人，除此之外没办法。大多数时候的“端到端加密”，是认为 server 就是一个可信任的中间人，然后你和 server 之间的可信任中间人是 CA 。如果这个信任链有问题，你唯一的选项是直接找到对方，然后当面交换公钥。
这归根到底是个哲学问题，B 到底是谁，我又到底是谁？

有专门的密钥协商算法

在两个 NAT 内网的 pc 之间通讯，
外部的 server 可以只作为寻址之用吧？
通信可以直接发生在两个 pc 之间。

然后，
非全圆锥的 NAT ，需要 server 中转的，
两个 pc 之间是不是可以再套一层加密，
以防止 server 篡改内层原本的数据呢。

Signal 是可以当面相互确认公钥的（通过互扫二维码），Telegram 应该也可以

还有你说的公告板系统上大家登记自己的公钥，
这个就是类似于现在的 CA 系统啊。

现在的 CA 系统是逐层认证的，
树状的公告板公钥登记模式而已。

中间人攻击的问题没什么好办法解决，参见 https 的证书体系。

需要第三方渠道来完成证书验证，比如可信 CA

通过 server 无法掌控的第三方服务来交换公钥也行，比如你要防的是越南，那你就在不可能跟越南合作的 APP 上交换公钥，比如在 github 上交换

实际上现有的端到端加密其实是 key 到 key 的加密，只保证是发送端 key 的所有者到接收端 key 的所有者是保密的。至于怎样验证你要通信的对象的确是这个 key 的所有者，有两种普遍的模式：
1. 基于权威机构的证书，也就是 X.509 。
2. 基于面对面建立的信任网络，也就是 PGP 体系。

> 公告板
ISP 也可以劫持你的流量给你看伪造的公告板
> 一方是公网，用 IP 直接连接
同上，ISP 也可以中间人攻击

楼主提出的问题是经典的中间人攻击问题，除非倚靠第三方手段如 CA 、当面确认收到的密钥，否则无法规避

总结：楼主 2015 年注册的，自学能力应该很强才对，这些问题 Google 搜索一下就好了。特别是有人专门讨论过 IM 端到端的设计的情况下。不能理解为什么还要提出这样入门级的问题。

https://bdwms.site/e2ee/

https://iangeli.com/2019/04/25/%E7%AB%AF%E5%AF%B9%E7%AB%AF%E5%8A%A0%E5%AF%86%E9%80%9A%E8%AE%AF%E5%8D%8F%E8%AE%AESignal-protocol-%E5%AD%A6%E4%B9%A0.html

想到 signal 好像就有这个功能，如果你不相信服务端发给你的 B 的公钥信息真假，可以双方发送自己的公钥二维码或者线下扫码确认验证

我赞同 7 楼所说

1.如果是现实中认识地人之间加密通讯,可以考虑当面交换 KEY

2.但是如果和虚拟世界中地网友之间通讯,而且还需要加密,这样地情景其实不多,这种情况下通讯双方只能通过第三方来建立第一次联系,所以必然存在"选择哪一个第三方"/"该第三方是否可信"/"如果该第三方不可信又如何"等等一系列问题

了解一下 signal protocol

我用 matrix 很多年，最开始用了一下 端到端 加密，后来再也不想用，因为太麻烦，特别是群组加密

就不能搞一个对称加密吗？群内成员共享一个密码

想进一步还可以：群组加人的时候，群主负责和所有成员交换 RSA 公匙（成员之间不用），群主把 AES key 用每个组员的 RSA 公匙加密，放置在服务器上（同时加上群主的 RSA 签名），每个组员从服务器获取最新的 AES key 用来加解密群内聊天内容。这样，可以定期修改 AES key 增强安全性。还可以指派几个管理员享有群主同等权利。

无论是直接交换 AES 密码，还是交换 RSA 公匙，都可以使用第三方的阅后即焚服务。

目前，我用的是自己写的通用 IM 开源加密工具，首次交换密码我喜欢用阅后即焚，确保对方收到密码，才使用此密码加密：
t/832302
见连接提到的更多技巧

可以做到。

你的担忧不是端对端加密的漏洞，而是中间人攻击的问题。

一切的安全措施，都有一些前提吧。

不考虑群组聊天的话非常简单，但是如你所说，其实最麻烦的还是这个握手的时候如何验证对方的 authenticity ，于是这里其实就变成了一个身份问题，这也是为什么你用 signal 的时候会推荐你线下 verify 对方的身份（公钥），这样之后在握手的时候，其实做的就是互相签名，来确保不被中间人替换密钥了。当然了，在真的做通讯的时候也有一些需要注意的问题，比如说如何保证 forward secrecy ，这里就要提到一个 ephemeral key 的概念，ie 每一条消息都由一个一次性的密钥进行加密，真实性靠上一个密钥或者不变的那个 public key 对应的私钥签名来提供保障。具体的加密方法可以参考： https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme 。

> 有个公告板，大家都把自己的公钥发布上去，这时候 server 是做不了手脚的。
> 其中之一方在公网，且它的地址被另一方知道，双方直接通信，不借助 server 打洞。

这个可以看看 pgp 的 key server 或者 keybase ，server 是否能动手脚不在于说是不是一个公共的公告板，而在于说每个公钥都是签过名的。

当然了，也可以看看我们在做的 https://docs.next.id

虽然但是，这里有个概念问题。

端到端加密和可信中间人是两个不同的问题。密钥不泄漏 or 不被伪造是端到端加密的“预设条件”，而非其“目标问题”呀。在满足密钥不泄露的前提下，可以做到除了发送端和接收端之外的其他节点无法获取明文信息，就是完备的端到端加密了

举个最极端的例子：即使是使用 Signal 通过当面交换公钥，但是用户在实际使用中使用了不受信任的物理设备，导致密钥直接在物理层面泄露了，这也会导致信息泄露发生。但这并不能说明 Signal 提供的端到端加密是假的或不完备的...

可以用那个协同密钥。 客户端和服务端组合一起才能解密。

“亦或借助 server 进行转发，server 俨然就是一个中间人的角色，在协商阶段把 A 、B 的密钥全都替换成 server 的。”

这个中间人的定义就不太准确，参考中间人攻击方式，server 要换密钥，那 client 就要信赖 server 才行，既然你都信任 server 了，那就相当于自己 hack 自己了。只要你只认可合法 client 的证书，server 没法攻击

@paramagnetic #1 不哲学。如果这个人是你能见面的，那线下验证一下密钥很简单

现在主流聊天软件的端对端问题是，客户端不开源，你不知道它显示给你线下确认的 pk 的是不是真的

什么鬼都在瞎说八道一些什么，明明 2 楼就是正解
都没没听过 Diffie-Hellman 么， 在双方不直接发送密钥的前提下完成密钥交换。

你再仔细想想除了 server, 这条网络线路上所有交换机路由器不全部经手你的数据么，按你这么说加密根本没法做了

了解一下 OMEMO ？

内网的话可以扫描整个内网 ip 端口来连接，不需要电脑这样的 server 。此时交换机就是中间人，因你没法保证这个交换机不是含有两个网口的电脑。这种情况只有一楼的方法能保证互相信任。

至于 DH 什么的，也需要用安全的通道事先知道对方的公钥，或通过信任第三方获取对方公钥，典型应用就是 CA 证书体系的浏览器。我就不信有人能把电脑和浏览器的证书都删掉还能用 DH 交换出安全密钥。

@nomagick 密钥交换只是其中一个逻辑啊，光有交换算法也没法通信，都说远了最简单的 https 通信就是一个非常安全的端端通信，在不自黑的情况下目前没办法破解

可以，思科的 webex 应该是端到端加密的

@nomagick 你不会天真认为 DH 算法能防止中间人攻击吧，中间人可以两端都骗，算出两端的密钥，最终解决方案就是和 TLS 一样，引入 CA 才能解决。

@iX8NEGGn
@mokiki
大哥 DH 自己就这么不堪么，你们是都不用 ssh 登服务器么，ssh 就没 CA ，照这么说没法用了
等下回连新机器人问你相信不相信对方的 key 的时候，回答否然后给机房打电话确认一下？

信任都是有基础假设条件的啊。
在 server 不可信的前提下，AB 之间连身份都无法信任了。

@nomagick 那你仔细想一想，要求你确认的目的是什么？就是为了让你自己负责对方是否可信啊，那么问题来了

如果你没有第三方认证机构，你确认的时候怎么知道对方是否可信呢？如果是假冒的你也无法分别
如果你说你本地存储了一份信任服务器名单，那又有个新问题，信任名单是从哪里来的呢？如果你通过网络传输，那又陷入了中间人攻击的怪圈。如果你是直接提前协商写死的，那么既然都可以提前协商了还用 dh 干什么，直接写死每个服务器通信对应的加密 key 不就完了？所以说光是 dh 是无法解决端端通信的

@nomagick ssh 第一次连接是会被攻击的，所以第一次连接会问你是否信任

@dbolo123 安全一点的做法可能是，都选否，然后通过其他方式获取对方公钥，配在自己服务器上，再去连

@nomagick SSH 推荐的安全登录方式是证书登录，怎么就没 CA 了，密码模式确实没 CA ，但它就是这么的不堪，随时被中间人工具，你能用不代表它安全，只是没人攻击你罢了。

@iX8NEGGn 你把密钥和证书搞混了，ssh 出现得早，没有 CA

@rekulas 我寻思 CA 就是你那个本地信任服务器名单啊，而且这里面核心就是事先已知，而不是你说的第三方，
CA 证书的后续分发也是通过网络

@dbolo123 我不信 ssh 问你的时候你答了否

而且我发现本帖对 CA 的认知也不够深，CA 和证书不是只管密钥的，它是将密钥和其他信息进行关联，否则毫无意义，而这个关联的过程是需要 CA 自己单独去进行的，比如一般网站的证书是将密钥和域名关联起来，CA 需要单独验证你是不是持有这个域名。

那么在本帖的场景下如果使用 PKI 那 CA 需要签署什么呢？ 基本上是 UserID 或者 Email 之类的东西吧，那 CA 又从何验证密钥的持有者同时是 UserID 或者 Email 的所有者呢？

明白了吧，根本不现实。

这个帖子讨论的是端到端通信，而不是端到端连接，好比完成密钥交换之后使用 Email 收发密文，所以不要把思维局限在 TLS 上。

所以说关键点就是密钥交换，场景和 ssh 非常相似

@nomagick ca 并不是信任服务器名单，它只是一个授信机构，也就是初始化的时候可能没有任何证书，唯一的共识就是-所有人都信任 ca ，然后进入通信环节，ca 通过各种认证向客户端办法证书，大家都信任，通信才能继续。

ca+密钥交换，可以实现在不可信网络中的可信通信，这正好是 op 的需求，也是 https 的基础原理
回到你的疑问-ssh 就没 CA ，照这么说没法用了
可以用，但是你的通信时在不可信网络中的不可信通信，通信中的任何一个中间设备都可以对你发起攻击

要说主要的漏洞，可能就是 ca 认证环节了，如果认证不够严格可能会被伪造证书，但鉴于其超低概率和高难度基本可以认为是足够安全的，毕竟我们的互联网就运行在这套理论上而且稳定几十年了

@rekulas 补充一句，其实普通的 ssh 证书登录也是用了 ca 的，只不过 ca 是自己并不被系统信任，所以开始的时候会询问你是否信任。

完全不依赖 ca 呢？也是可以通信的，但是如上仍然是不可信通信

@nomagick SSH 三种登录模式：密码，公钥密钥，证书，我没有搞混，是你不了解技术进步了。

ssh 直接回答 yes 是基于对服务器提供商的信任吧，如果提供商在第一次连接就进行中间人攻击，这时候直接回答 yes 不就中招了？

关于 ssh 说几句。
使用公钥通信，只要公钥传到了远端服务器上。
即使有中间人应答，中间人也无法解密通信内容。
也就是第一次回答 yes 也无所谓。

@BloodBlade

如果区块链可信的话是可行的。
只要登登记 id 和公钥就行。
比如说张三李四登记了。
那么张三一定能发出一条只有李四才能解密的信息。
不过：
李四能不能收到要看网络上让不让传（某墙），或者信息也上链。

@yhvictor 确实，你说的对，如果提前拷贝了 ssh 公钥，这种情况无法进行中间攻击。但是这又回到了最早的情形-既然都可以通过某种方式将公钥可信的传递到服务器，那么有没有密钥交换都无所谓，端端通信跟 dh 没关系了。这个我是针对 nomagick 的回复说的。

我也是做区块开发的，至于区块链我跟你看法也一样，区块链本身协议无法提供可信保障，现有的区块链其实都存在这个漏洞的，只不过区块链中间人攻击几乎没有什么收益，而且节点多攻击成本也高-有那能力还不如 51 攻击。
公钥加密-解决不可信网络的可信通信(如 https)
私钥加密-解决不可信网络的身份认证(如区块链)

@yhvictor 我的意思是，公钥一般是在购买服务器前先传到云服务提供商，购买服务器后再由提供商写入到服务器上，这个过程中公钥会在提供商中经过一次。如果先开服后上传公钥的话，也要通过密码连接或者提供商的后台来传上去，同样也存在被提供商利用的可能性。

搜一下 E2EE ,DH 秘钥交换算法就知道了