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

[cxytz01]

想象这么一个场景 client A 、B 都在 NAT 内部，它们需要通信，那么就需要经过 server 进行协商握手。不论后续是否成功进行 p2p ，亦或借助 server 进行转发，server 俨然就是一个中间人的角色，在协商阶段把 A 、B 的密钥全都替换成 server 的。

只有两种种场景是可以端到端加密的：

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

不知道描述得是否正确，请指正。

[paramagnetic]

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

[FengMubai]

有专门的密钥协商算法

[icegaze]

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

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

[agagega]

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

[icegaze]

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

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

[ysc3839]

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

[eason1874]

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

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

[tavimori]

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

[CEBBCAT]

> 公告板
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

[gkirito]

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

[7RTDKSAK]

我赞同 7 楼所说

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

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

[zhengxiaowai]

了解一下 signal protocol

[duke807]

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

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

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

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

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

[Roanapur]

可以做到。

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

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

[yisiliu]

不考虑群组聊天的话非常简单，但是如你所说，其实最麻烦的还是这个握手的时候如何验证对方的 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

[sy20030260]

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

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

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

[ren2881971]

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

[rekulas]

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

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

[dingwen07]

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

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

[nomagick]

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

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