这是一个创建于 1243 天前的主题，其中的信息可能已经有所发展或是发生改变。
实现想法：
A 发送消息给 B
检测是否持有 B 的公钥
若有，使用 B 的公钥对消息进行 RSA 加密并发送。
若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。
B 收到消息后，使用自己的私钥进行消息解密。
B 发送消息给 A
同理
我想，这样应该才是能实现真正隐私通讯的，连服务提供方都无法窃取消息的，而不是市面上一些聊天软件慌称的“隐私”。
这种通讯隐私方案可实现吗？会有软件愿意为了用户隐私而实现吗？
第 1 条附言 · 2021-07-28 17:07:08 +08:00
看了大伙回答，补充几点我的想法：
这里我说的是解决聊天内容隐私问题。
我看到大家说中间人攻击，我想法是这不需要我去处理吧，上一层网络通讯的时候是 HTTPS 呢，这一层可以解决。
第二个，大家说 RSA 效率问题，这怎么会有问题呢，AB 客户端，只解自己的消息，CPU 这点能力都没有吗？这根本不在考虑问题内。
服务端才要考虑这个问题，因为服务端 RSA 解密的话，是要面对 N 多个客户端的。
这里我说的是解决聊天内容隐私问题。
我看到大家说中间人攻击，我想法是这不需要我去处理吧，上一层网络通讯的时候是 HTTPS 呢，这一层可以解决。
第二个，大家说 RSA 效率问题，这怎么会有问题呢，AB 客户端，只解自己的消息，CPU 这点能力都没有吗？这根本不在考虑问题内。
服务端才要考虑这个问题，因为服务端 RSA 解密的话，是要面对 N 多个客户端的。
 |
101
blackshow 2021-07-29 14:22:26 +08:00
|
 |
102
jim9606 2021-07-29 15:35:18 +08:00
你这个已经是大幅简化的模型，E2E 聊天软件通常是使用 A 和 B 的 RSA/ECC 密钥对通过密钥交换算法（例如 DHE/ECDHE ）获得双方共享的 Session Key （对称密钥），用这个进行消息加解密。
问题在于虽然 Session Key 建立后服务器无法窃取信息，但它可以干涉公钥传递，A 不能保证拿到的公钥是 B 的公钥还是 C 的公钥。 |
 |
104
liuidetmks 2021-07-29 17:31:12 +08:00
@lonnyzhang 交换 m 和 n 过程中,服务器被黑客攻击了,服务器自己生成 m1 n1 ,替换发给对 A,B，一人分饰两角， 后面所有的消息都能被服务器拦截并转发。
当然，AB 也可在建立信道之后，给对方发一次自己的随机数，这样就知道是否被攻击，可相应的黑客也能篡改消息内容，更进一步的欺骗。 |
 |
105
rpman 2021-07-29 17:58:03 +08:00  1
我一直认为计算机是民科最泛滥的行业
|
 |
106
rrfeng 2021-07-29 18:07:48 +08:00 2
好家伙，100 多层楼里一半多想法安全的都跟筛子一样……
|
 |
107
lonnyzhang 2021-07-29 18:22:15 +08:00
@liuidetmks 再仔细看看，key 只在 AB 端生成，不会经过网络传输，包括服务器都是不可能知道的。所以即使服务器自己就是“黑客”，它也不可能知道 AB 两端用 key 对称加密后传输的是什么内容。
|
 |
108
maybedk 2021-07-29 18:48:18 +08:00
@liuidetmks 哈哈，抓包软件都是这么抓 https 的
|
 |
109
0576coder 2021-07-29 19:42:27 +08:00
@agee
如果端到端的代码还是被看到的话 ecdh 也没用 也能伪造中间人攻击 或者被中间人猜出了算法 也有可能是中间人攻击 |
 |
110
jimmyismagic 2021-07-29 19:58:52 +08:00
telegram, keybase 了解一下
|
 |
112
Meano 2021-07-29 23:09:01 +08:00
楼里的人都不在一个层次啊，楼主还在想怎么用 RSA 做（密钥？数据？）交换呢，有些朋友已经在讨论公钥可靠性了。
加密通信的风险除了监听风险外，主要还是密钥协商时的公钥风险（ CA 劫持，公钥伪造等），也没人提 IBE 啊，相比 DHE/ECDHE，IBE 用 User ID （公开，比如邮箱，相当于见字如面，不易伪造）+ 随机数（私钥）生成用户协商公钥，用户可以互相通过主公钥和 User ID 验证协商公钥是否来自于对方，相当于签名，可能的风险就看算法有没有后门了，主公钥如果受到干扰协商也不会成功。 @jim9606 这样应该没法做公钥干涉吧 倒是计算开销比较大，目前看到的 IBE 算法都是用双线性对，前段时间搞过 SM9 通用 CPU 计算，不用 Native code 耗时到秒级了 |
|
113
lonnyzhang 2021-07-29 23:35:46 +08:00 via Android
@liuidetmks 真正的端到端加密只会在端生成密钥，是不会经过网络传输的，服务端也破解不了传输的内容。
|
 |
114
anonymous256 2021-07-30 00:57:05 +08:00
keybase，信息完全密钥加密
|
 |
115
LeslieLeung 2021-07-30 01:33:16 +08:00 via iPhone
跟楼主有一样的想法 所以我做了一个这个 目前只开源了客户端 服务端暂时没时间上传
其实这个方案考虑不完全 不能防范中间人攻击 但是加上证书和签名就可以了 https://github.com/LeslieLeung/silbo |
 |
116
clearc 2021-07-30 06:43:29 +08:00 via iPhone
看内容和讨论，有一种十来年前复古的味道了
|
 |
117
godblessumilk 2021-07-30 09:15:24 +08:00
|
 |
118
zl939144892 2021-07-30 09:27:02 +08:00
量子纠缠 手动狗头
|
|
119
liuidetmks 2021-07-30 09:43:53 +08:00
|
|
120
liuidetmks 2021-07-30 09:44:42 +08:00
@lonnyzhang
你的意思我了解,可能是我没说清楚,你没了解我说的意思 服务器生成 (x,y)时候,同时自己模拟两个客户端 A1(用于和 B 通信,并生成 m1= x^r3 %y ) B1 （用于和 A 通信,并生成 m2 = x^r4 %y )，r3 ,r4 随机 AB 在交换中间 m 和 n 的时候，肯定会通过服务器，服务器这时候 收到的 m 和 n 截流,把 n1 发送给 A,把 m1 发送给 A 。 A 得到的密钥 m^n1 = n1 ^ m = x^(n1*m) % y B 得到的密钥 n^m1 = m1 ^ n = x^(n*m1) % y 这样 A 和 B 不知情的情况下，分别和服务器建立了点对点加密通信,这样,服务器就完成中间人攻击了。 |
 |
121
newmlp 2021-07-30 10:55:15 +08:00
https 加可信任证书才能保证不被劫持，只有 https 是不能保证不被劫持流量的
|
|
124
lonnyzhang 2021-07-30 14:54:36 +08:00
@liuidetmks DH 算法本身不具备身份鉴定功能，一般要和数字签名结合才能防止中间人攻击。
|
 |
125
piku 2021-07-31 09:38:45 +08:00
你们
唉，不知道说什么好 真正的点对点通讯，为什么会走公网环境，必然是点对点专线啊 还可以走大功率无线网桥 或者搞一对数字对讲机，随便加个密码，第三方就没辙了 |
Select Language