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

[brader]

实现想法：

A 发送消息给 B

检测是否持有 B 的公钥  

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

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

B 发送消息给 A
同理

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

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

[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 本地维护一个公钥列表和消息列表，然后可以复制加密后的内容发送给朋友
暂时没考虑做服务端