真正的点对点聊天通讯隐私实现想法

Telegram 呗

『若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。 』


传输的过程被中间人了怎么办？

这种聊天软件其实有很多...基于 matrix 开发的客户端可以轻松实现端到端加密
官方专门有文档指导开发者如何实现带有端到端加密的客户端

https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide

还有在大陆可以(几乎)无障碍使用的 keybase(已被 zoom 收购)，也是宣称端到端加密的。

我们生活中几乎没见过这种东西的原因，相信你也能想明白。

所有的 E2EE 通信不都是这样，主要问题还是在密钥交换上面

好家伙，https 诞生记

@also24 公钥是可全网公开的，所以被截获是无所谓的

@brader #6
『被中间人』指的是，你怎么知道你收到的是 B 的公钥，而不是中间人 C 的呢？

这不就是 HTTPS 的工作原理？

@brader #6 建议详细了解下中间人攻击

这种东西一直都不是技术问题。

常见通信软件是不是就绿色的那个不支持 e2ee ？

@also24 不使用 B 的公钥加密，B 是无法解密消息的，那么软件就无法提供正常服务，B 也能发觉异常

@brader #12
参考 9 楼，建议详细了解下中间人攻击

@brader
A 发送消息给 B
发现没有公钥， 从 B 请求公钥， 此时中间人生成公私钥，将中间人公钥发送给 A
并请求 B，B 返回正确的 B 公钥，中间人保存 B 公钥。

此时 A 拿到 中间人公钥加密消息，中间人获取密文，用中间人私钥解密，将消息再由 B 公钥加密，发送给 B

@also24 防中间人那不就是证书那一套了

https 也有一段通过对称加密交互公钥的过程吧我记得，它也不全依赖技术，而是利用证书解决陌生人之间的信任问题。好吧，蹲个大佬仔细说说。

PGP, autocrypt，现成的 delta chat 可以看看

建议学学网络安全吧。你说的就是一个小作业而已。

@lakehylia #15
但是楼主设计的这一套里面没有类似机制，或其它能解决这个问题的机制。

@chizuo 小作业都比你的要复杂一点点，因为 RSA 耗费资源多，使用的是 OTP （ one time pad ），每次消息传输都用一次性的 AES 来加密，RSA 仅加密 AES 的密钥就行了。如果感兴趣，还是建议学学网络安全，会有一个基本的认识。

@also24 两个要隐私通讯的人，见一面，交换密钥就好了。真正的防中间人~~

@brader #12 这一样防不住中间人的，中间人可以生成一份自己的公私钥分别拦截并返回给两边客户端，两边客户端的数据中间人也都能解开并重新加密，建议了解一下证书体系的信任机制

@lakehylia 最靠谱的,面对面 交换秘钥 0.0

刚学了《应用密码学》，你说的这个方案是一个仅使用非对称密码的一个很不成熟的方案。
1. 有中间人攻击：请求 B 的公钥的时候存在中间人攻击，解决方案是使用 CA
2. 计算效率低：使用非对称加密的计算代价都太高了，一般非对称加密用来传输对称密钥，对称密钥加密消息
3. 不具有鉴别性：还需要用 A 的私钥对消息进行签名，来供 B 验证确定你的身份

@sakura1 你指的是 服务端用 ca 中心的私钥加密（电子证书+服务器公钥）到浏览器，浏览器用内置的 ca 中心公钥解密并验证电子证书合法性这个过程吧

@Vegetable 请大胆的说出来 ....

跟楼主想法相似的是安全的多用途 Internet 邮件扩展 S/MIME ，而不是 https 、PGP 。

RSA 加密？一般肯定产生会话对称密钥加密啊

nat upd 打洞+定时密钥更新加密通讯 @brader

对于上面所说的中间人攻击，我觉得可以用区块链解决，所有人公开公钥且公钥不和用户绑定。发消息时用公钥加密广播，仅持有此公钥的私钥的人才能看到所发消息。但存在一个消息泛滥问题，所有人都可以发消息给这个公钥，然而数字货币不会存在（因为没人会随便给你转账），这个问题可以用发消息+数字货币的方式解决。

@777777 别什么都扯上区块链啊。去中心化的区块链恰恰就是不能解决身份认证的问题。如果只认公钥，不管现实用户是谁，简直就没有中间人冒充的余地了，哪里还需要区块链出场。

@shansing 只认公钥，如何解决消息泛滥问题？

@shansing 要的就是不需要身份认证，实现身份隐私+通信隐私

A 和 B 在线下通过投骰子选个地儿洗个澡儿，在洗澡过程中双方全身赤裸在淋浴头下时，交换一个 10 位数以上包含字母+数字+符号的密码。

之后双方用任意一个经得住考验的加密算法并加上这个密码（好像叫盐？）就行。

不太懂密码学，似乎这样就 ok 了？

回楼主， 有， 这个软件叫做 GnuPG , 也叫做 GPG

keybase 了解下

@1041412569 PGP 也可以加密邮件呀，和 S/MIME 功能相近

你都 https 了，还要你这个方案干啥，毫无卵用

@777777 你这方案第一句话就不可行： [所有人公开公钥] 。请问怎么做到这一点？

@kera0a https 的话，服务器还是拿到了聊天内容啊，加了这个，服务器就也拿不到聊天内容

端到端加密通讯早就有成熟技术并落地了...

搜下 tg 的实现.

线下提前交换公钥吧，Email + GnuPG 勉强能用。

难道不是只有某一个聊天软件不是点对点加密么？
所以这哪是技术问题。
人家 WhatsApp 必须手机在线才能在电脑上使用，就是因为点对点加密，你电脑 /Web 端看到的消息是手机端解密后再加密传递过去的，服务器端是获取不到明文消息的。
某个聊天软件也一直无法单独使用电脑端，仅仅就是为了让你不方便。
上周 WhatsApp 开始内测多设备同时登陆并可以手机离线了，某软件这两天立刻抢先推出同时多设备的功能。

题主的问题，是在于没有学习信息安全。

比如题主说，HTTPS 能解决中间人攻击问题，问题是，有了 HTTPS，还要你这套东西干嘛？ HTTPS 已经具备了你自己发明的这一套东西的所有功能。

@brader
服务器做中间人攻击不就能拿到了

a 和 b 应该直接做 https 通信才行

好，你说了一大堆，很牛逼，很 fancy 。
你还问了会有软件去实现吗。
那请问如果是你你会去实现吗？你是慈善家？

看了你的补充想法，我再补充一点。。。
RSA 单次加密能力，密文一定得小于密钥，那么 1024 位的密钥，一次也只能加密 128 个字节，而你遇到稍微长点的消息，就要分很多组进行加密。
其次， 你所有消息都使用了同一组密钥进行加密，那么一旦密钥被窃（也可能是被破解），那么以前所有的记录都再无秘密可言。哪怕，你使用 DH 协议交换一个密钥都比这个来的强的多。
最后，要真正实现隐私，要不要考虑引入 OTP ?

signal，直接去看代码吧，还有端到端加密的群聊

这跟 HTTPS 原理不一样，这是"两军问题"，无解

@Vegetable 你孤陋寡闻了,最常见的 imessage 就是 P2P 加密

@FS1P7dJz 之前也有帖子讨论过类似问题。iMessage 说到底不是一个在国内诞生的产品，作为一个面向其他地区设计的产品，做成这样自然是非常合理的。它引入中国究竟没有做出牺牲我们都不知道，但是诞生在国内，并面向国内用户，宣称端到端加密的聊天软件，貌似不会有什么好下场。

双方线下交换公钥，随后在使用聊天软件时，每次都把要发送的消息用对面的公钥进行 gpg 加密再发送。稳得一批，微信也可以很安全。

政治上不允许

我手工用 gpg 加密内容，然后通过微信发送也可以啊，解密也是手工。也许可以把加密解密做到输入法？通过现成的 im 工具传输加密后的内容？

小飞机不就是么

就是因为你这想法会被中间人攻击，所以才出现 CA 机构来颁发 CA 证书解决中间人攻击的啊。
有了 CA 证书，就有了 SSL，就有了 HTTPS 。SSL 还通过密钥交换确保前向安全性。
基于 SSL 的话就只有发信方和收信方能解读加密密文了，中间人劫持封包就得面对大数分解或者离散对数的数学难题。
我没看懂你觉得哪里还有问题，可能你没把 SSL/TLS 的原理学通透。

有这样的软件了，而且还是国内的，使用者很少罢了，个人觉得存在运营风险。

至于市面上的 IM 软件为何不用这套方案，一方面是出于多端信息同步的需求，一方面就是上面提及的非技术因素了。
实际 IM 卖的是一个社交服务，真正的隐私 IM 应该只是卖一个通讯录，类似一个 DNS 让双方能互相找到彼此建立 SSL 会话即可。

我最近在做一个手动加密的聊天工具，就是 app 本地维护一个公钥列表和消息列表，然后可以复制加密后的内容发送给朋友
暂时没考虑做服务端

在国内别想了

@treblex 楼主的想法应该跟我这个差不多，就是客户端加密消息，服务端制作标准实现

但是运营不了，国内似乎要求必须有审查的能力，存密文的话没啥用，除非你把用户私钥存了
t/745797

现在手上这个 app 只打算做到这个程度了
后端如果做的话，最好是能做一个标准或者开源实现给用户自己部署和开发，在 app 上设置服务器地址（实力不足

@treblex 你这个已经有现成的了,win 上叫 gpg,安卓有一个叫 openkeychain 的实现

这个我最近做过 https://www.npmjs.com/package/cwg-abc

啊，还以为会看到量子纠缠

1. 你说的就是 rsa 公钥密码体系的雏形
2. ca 是为了解决中间人攻击的。
3.如果外层套一层 tls 。那么底层不需要 rsa，对称加密就行，效率还高。
4.此贴终结

建议多读书，把 rsa 吃透。

推荐楼主看看 XMPP 的

XEP-0384: OMEMO https://xmpp.org/extensions/xep-0384.html

XEP-0364: OTR https://xmpp.org/extensions/xep-0364.html

通信加密已经不是一个技术问题了……

防中间人又不用根证书的话，只有上 ecdh 算法，可自行谷歌，真正实现不用见面的情况安全交换密钥，防中间人攻击腾讯就是用的 ecdh

首先，不能有中心服务器

"若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。"

这就像一个没有 CA 的 TLS, 或者一个不校验证书有效性的糟糕 TLS 实现, 对中间人攻击没有任何免疫力.

跟你的想法类似的是 GPG, 但 GPG 的开发者认为, 交换密钥应该以"线下碰面"的形式完成.

以上是技术问题, 至于政治 /法律问题我不做讨论. 你认为微信如果想实现类似的技术, 不会受到阻力吗?

@agee ECDH 是椭圆曲线域上的 Diffie-Hellman, 照样需要签名.

例如 TLS 的加密套件, ECDHE_RSA_* 和 ECDHE_ECDSA_* 中的 RSA 和 ECDSA 就是签名算法.

恕我孤陋寡闻，中间人攻击基本上只能通过证书或者类似的其他“预共享的信息”来实现，你这里好像根本没提到对这个问题的解决方案。如果不想引入证书也可以参考下 Telegram 的 secret chat，两边用户可以通过对比一个颜色点阵来确保没有被中间人攻击。

Rocket.Chat?

1. 只用 RSA 效率低，也没必要，而且不是所有设备都有个人电脑的算力，就算有也不应该挥霍。
2. 只用 RSA 缺乏一些关键的安全特征，比如完全向前安全性。TLS 标准算法里头一长串又不是为了炫技。
3. 解决中间人问题要不然由第三方担保，要不然就是预共享密钥做 HMAC 。然而有预共享密钥的前提下，可以直接 HMAC 配合密钥交换算法进行端对端加密通信，RSA 反而不是必要的，徒增消耗。
4. 市面上端对端加密解决方案不是有没有，而是太多了，商业的、社区的应有尽有。

PS：好奇楼主认为 https 是怎么实现的？

https://github.com/evilcorpltd/aTox
tox 协议可以看看

lz 写的方案太初级，就像有个人说，我发现了用 break 可以退出 for 循环一样。 不过想要隐私通讯的想法是很 ok 的，可以多了解下评论里提及的开源软件。不说了，我也学习去

大陆应该不存在能商用的这玩意。

没有绝对安全的网络

@dingwen07 最近的吴亦凡和都美竹事件就是中间人攻击。两头骗

iMessage 好像就是这么设计的

去看 Telegram 的端对端加密算法:
https://core.telegram.org/api/end-to-end

是基于下面这个算法：
https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

总结下就是：
1.服务端给客户端提供两个数(x,y)
2.客户端 A：
生成随机数 r1，计算 m=pow(x, r1) % y
3.客户端 B：
生成随机数 r2，计算 n=pow(x, r2) % y
4.A 、B 互相发送结果 m 、n
A 计算 key=pow(n, r1) % y
B 计算 key=pow(m, r2) % y
这时，两个 key 是相同的，后面用这个 key 做对称加密即可

注：y 要足够大，x 、y 、m 、n 都是公开的，但是只要 r1 、r2 不泄露，别人想要计算出 key 的值难度很大，包括服务端。

歪个楼，目前对于端对端加密的聊天软件监控的通杀方式，是监控顶部通知栏

密码学很有趣的，建议多学点

这不就是 tls 的原理吗，直接拿 tls 来用不就行了

建议了解一下 telegram 的实现，加密不仅要考虑前向安全，还得考虑后项安全。
如果秘钥泄露，那么你的所有信息都会泄露。
tg 用了双棘轮算法保证每条消息的秘钥都是不一样的

曾经做过一个利用邮箱实现类似聊天方式的。完全不需要服务器，没做完流产了

楼主多去读点书吧，别做民科

这不就是 telegram 吗

A 怎么知道收到的公钥是 B 发来的

思而不学则殆。看一下 HTTPS 工作原理就知道了。另外 RSA 一般用来加密对称密钥，而不是消息本身。

楼主可能刚刚了解非对称加密原理，然后就想了这一出。
但是还是要多读书啊

读这个之前没人教你 don't make your own crypto 么
真密谈应该明文配 one time pad

@earneet 说的很对，有个细节需要更正，RSA 算法由于 PKCS#1 补丁的关系，单次加密最大数据长度为 117 字节，嘿嘿。

想要 End to End 的加密，首要解决的是两端交换的密钥确实是他们自己说的密钥，而不是由中间人篡改后的密钥。上面网友说的面对面交换密钥就能保证到。

技术早就有了！落地应用，环境不现实

怎么说呢，楼主能来 v2，竟然不知道 telegram 吗

@lzxz1234

好家伙，超时空网速