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

[brader]

实现想法：

A 发送消息给 B

检测是否持有 B 的公钥  

    若有，使用 B 的公钥对消息进行 RSA 加密并发送。  
    若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。  

B 收到消息后，使用自己的私钥进行消息解密。  

B 发送消息给 A
同理

我想，这样应该才是能实现真正隐私通讯的，连服务提供方都无法窃取消息的，而不是市面上一些聊天软件慌称的“隐私”。

这种通讯隐私方案可实现吗？会有软件愿意为了用户隐私而实现吗？

看了大伙回答，补充几点我的想法：
这里我说的是解决聊天内容隐私问题。
我看到大家说中间人攻击，我想法是这不需要我去处理吧，上一层网络通讯的时候是 HTTPS 呢，这一层可以解决。

第二个，大家说 RSA 效率问题，这怎么会有问题呢，AB 客户端，只解自己的消息，CPU 这点能力都没有吗？这根本不在考虑问题内。
服务端才要考虑这个问题，因为服务端 RSA 解密的话，是要面对 N 多个客户端的。

[learningman]

Telegram 呗

[also24]

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


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

[Vegetable]

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

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

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

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

[SingeeKing]

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

[lzxz1234]

好家伙，https 诞生记

[brader]

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

[also24]

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

[jousca]

这不就是 HTTPS 的工作原理？

[dingwen07]

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

[yfugibr]

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

[masterclock]

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

[brader]

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

[also24]

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

[finab]

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

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

[lakehylia]

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

[sakura1]

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

[hiplon]

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

[chizuo]

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

[also24]

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

[chizuo]

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

[lakehylia]

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

[Mitt]

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

[bruce0]

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

[UnknoownUser]

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

[securityCoding]

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

[LessonOne]

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

[1041412569]

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

[gps949]

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

[luvroot]

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

[777777]

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

[shansing]

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

[777777]

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

[777777]

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

[NeezerGu]

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

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

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

[qrobot]

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

[tangds99]

keybase 了解下

[dallaslu]

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

[dqzcwxb]

[kera0a]

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

[gBurnX]

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

[brader]

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

[Jooooooooo]

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

搜下 tg 的实现.

[expy]

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

[DeutschXP]

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

[gBurnX]

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

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

[kera0a]

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

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

[harwck]

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

[earneet]

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

[catror]

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

[chairuosen]

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

[FS1P7dJz]

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

[Vegetable]

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

[JamesMackerel]

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

[jiayong2793]

政治上不允许

[huangmingyou]

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

[adsltsee94]

小飞机不就是么

[RainyH2O]

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

[clf]

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

[RainyH2O]

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

[treblex]

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

[Dogtler]

在国内别想了

[treblex]

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

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

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

[delpo]

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

[treemonster]

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

[nullcoder]

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

[ck19920702]

https://github.com/signalapp

[v2clay]

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

[v2clay]

建议多读书，把 rsa 吃透。

[sholmesian]

推荐楼主看看 XMPP 的

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

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

[railgun]

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

[agee]

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

[kirch]

首先，不能有中心服务器

[Hardrain]

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

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

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

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

[Hardrain]

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

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

[iseki]

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

[bs10081]

Rocket.Chat?

[parametrix]

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

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

[vagranth]

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

[fan123199]

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

[MarkLeeyun]

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

[love2020]

没有绝对安全的网络

[yiqiao]

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

[wy315700]

iMessage 好像就是这么设计的

[lonnyzhang]

去看 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 的值难度很大，包括服务端。

[Rcnaec]

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

[lingxi27]

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

[newmlp]

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

[pkoukk]

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

[ilaipi]

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

[misaka19000]

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

[Kareless]

这不就是 telegram 吗

[Joshua999]

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

[NilChan]

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

[villivateur]

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

[Rheinmetal]

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

[DBT]

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

[LLaMA2]

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

[wlbyg888]

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

[doveyoung]

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

[GeruzoniAnsasu]

@lzxz1234

好家伙，超时空网速