这是一个创建于 1248 天前的主题，其中的信息可能已经有所发展或是发生改变。
实现想法：
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 多个客户端的。
 |
1
learningman 2021-07-28 14:54:35 +08:00  5
Telegram 呗
|
 |
2
also24 2021-07-28 14:55:39 +08:00 1
『若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。 』
传输的过程被中间人了怎么办？ |
 |
3
Vegetable 2021-07-28 14:56:50 +08:00 1
这种聊天软件其实有很多...基于 matrix 开发的客户端可以轻松实现端到端加密
官方专门有文档指导开发者如何实现带有端到端加密的客户端 https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide 还有在大陆可以(几乎)无障碍使用的 keybase(已被 zoom 收购)，也是宣称端到端加密的。 我们生活中几乎没见过这种东西的原因，相信你也能想明白。 |
 |
4
SingeeKing 2021-07-28 14:57:04 +08:00
所有的 E2EE 通信不都是这样，主要问题还是在密钥交换上面
|
 |
5
lzxz1234 2021-07-28 14:57:29 +08:00 37
好家伙，https 诞生记
|
 |
8
jousca 2021-07-28 15:01:29 +08:00
这不就是 HTTPS 的工作原理？
|
 |
10
yfugibr 2021-07-28 15:04:40 +08:00 25
这种东西一直都不是技术问题。
|
 |
11
masterclock 2021-07-28 15:05:49 +08:00
常见通信软件是不是就绿色的那个不支持 e2ee ？
|
 |
14
finab 2021-07-28 15:14:18 +08:00
@brader
A 发送消息给 B 发现没有公钥， 从 B 请求公钥， 此时中间人生成公私钥，将中间人公钥发送给 A 并请求 B，B 返回正确的 B 公钥，中间人保存 B 公钥。 此时 A 拿到 中间人公钥加密消息，中间人获取密文，用中间人私钥解密，将消息再由 B 公钥加密，发送给 B |
 |
16
sakura1 2021-07-28 15:19:58 +08:00
https 也有一段通过对称加密交互公钥的过程吧我记得，它也不全依赖技术，而是利用证书解决陌生人之间的信任问题。好吧，蹲个大佬仔细说说。
|
 |
17
hiplon 2021-07-28 15:20:04 +08:00
PGP, autocrypt，现成的 delta chat 可以看看
|
 |
18
chizuo 2021-07-28 15:22:53 +08:00
建议学学网络安全吧。你说的就是一个小作业而已。
|
|
20
chizuo 2021-07-28 15:27:00 +08:00 2
@chizuo 小作业都比你的要复杂一点点，因为 RSA 耗费资源多，使用的是 OTP （ one time pad ），每次消息传输都用一次性的 AES 来加密，RSA 仅加密 AES 的密钥就行了。如果感兴趣，还是建议学学网络安全，会有一个基本的认识。
|
 |
22
Mitt 2021-07-28 15:31:39 +08:00
@brader #12 这一样防不住中间人的，中间人可以生成一份自己的公私钥分别拦截并返回给两边客户端，两边客户端的数据中间人也都能解开并重新加密，建议了解一下证书体系的信任机制
|
 |
24
UnknoownUser 2021-07-28 15:32:02 +08:00
刚学了《应用密码学》，你说的这个方案是一个仅使用非对称密码的一个很不成熟的方案。
1. 有中间人攻击：请求 B 的公钥的时候存在中间人攻击，解决方案是使用 CA 2. 计算效率低：使用非对称加密的计算代价都太高了，一般非对称加密用来传输对称密钥，对称密钥加密消息 3. 不具有鉴别性：还需要用 A 的私钥对消息进行签名，来供 B 验证确定你的身份 |
 |
25
securityCoding 2021-07-28 15:38:56 +08:00
@sakura1 你指的是 服务端用 ca 中心的私钥加密（电子证书+服务器公钥）到浏览器，浏览器用内置的 ca 中心公钥解密并验证电子证书合法性这个过程吧
|
 |
27
1041412569 2021-07-28 16:08:05 +08:00
跟楼主想法相似的是安全的多用途 Internet 邮件扩展 S/MIME ，而不是 https 、PGP 。
|
 |
28
gps949 2021-07-28 16:13:12 +08:00
RSA 加密？一般肯定产生会话对称密钥加密啊
|
 |
30
777777 2021-07-28 16:26:33 +08:00 1
对于上面所说的中间人攻击，我觉得可以用区块链解决，所有人公开公钥且公钥不和用户绑定。发消息时用公钥加密广播，仅持有此公钥的私钥的人才能看到所发消息。但存在一个消息泛滥问题，所有人都可以发消息给这个公钥，然而数字货币不会存在（因为没人会随便给你转账），这个问题可以用发消息+数字货币的方式解决。
|
 |
31
shansing 2021-07-28 16:38:19 +08:00
@777777 别什么都扯上区块链啊。去中心化的区块链恰恰就是不能解决身份认证的问题。如果只认公钥，不管现实用户是谁，简直就没有中间人冒充的余地了，哪里还需要区块链出场。
|
 |
34
NeezerGu 2021-07-28 16:49:48 +08:00
A 和 B 在线下通过投骰子选个地儿洗个澡儿，在洗澡过程中双方全身赤裸在淋浴头下时，交换一个 10 位数以上包含字母+数字+符号的密码。
之后双方用任意一个经得住考验的加密算法并加上这个密码（好像叫盐？）就行。 不太懂密码学，似乎这样就 ok 了？ |
 |
35
qrobot 2021-07-28 16:52:12 +08:00
回楼主， 有， 这个软件叫做 GnuPG , 也叫做 GPG
|
 |
36
tangds99 2021-07-28 16:57:15 +08:00
keybase 了解下
|
 |
37
dallaslu 2021-07-28 16:59:16 +08:00
@1041412569 PGP 也可以加密邮件呀，和 S/MIME 功能相近
|
 |
38
dqzcwxb 2021-07-28 17:24:19 +08:00 12
 |
 |
39
kera0a 2021-07-28 17:26:01 +08:00 via iPhone
你都 https 了，还要你这个方案干啥，毫无卵用
|
 |
42
Jooooooooo 2021-07-28 17:31:07 +08:00
端到端加密通讯早就有成熟技术并落地了...
搜下 tg 的实现. |
 |
43
expy 2021-07-28 17:31:39 +08:00
线下提前交换公钥吧，Email + GnuPG 勉强能用。
|
 |
44
DeutschXP 2021-07-28 17:31:48 +08:00 via iPhone
难道不是只有某一个聊天软件不是点对点加密么？
所以这哪是技术问题。 人家 WhatsApp 必须手机在线才能在电脑上使用，就是因为点对点加密，你电脑 /Web 端看到的消息是手机端解密后再加密传递过去的，服务器端是获取不到明文消息的。 某个聊天软件也一直无法单独使用电脑端，仅仅就是为了让你不方便。 上周 WhatsApp 开始内测多设备同时登陆并可以手机离线了，某软件这两天立刻抢先推出同时多设备的功能。 |
 |
45
gBurnX 2021-07-28 17:32:15 +08:00
题主的问题，是在于没有学习信息安全。
比如题主说，HTTPS 能解决中间人攻击问题，问题是，有了 HTTPS，还要你这套东西干嘛？ HTTPS 已经具备了你自己发明的这一套东西的所有功能。 |
 |
47
harwck 2021-07-28 17:34:23 +08:00
好，你说了一大堆，很牛逼，很 fancy 。
你还问了会有软件去实现吗。 那请问如果是你你会去实现吗？你是慈善家？ |
 |
48
earneet 2021-07-28 17:40:34 +08:00
看了你的补充想法，我再补充一点。。。
RSA 单次加密能力，密文一定得小于密钥，那么 1024 位的密钥，一次也只能加密 128 个字节，而你遇到稍微长点的消息，就要分很多组进行加密。 其次， 你所有消息都使用了同一组密钥进行加密，那么一旦密钥被窃（也可能是被破解），那么以前所有的记录都再无秘密可言。哪怕，你使用 DH 协议交换一个密钥都比这个来的强的多。 最后，要真正实现隐私，要不要考虑引入 OTP ? |
 |
49
catror 2021-07-28 17:44:21 +08:00 via Android
signal，直接去看代码吧，还有端到端加密的群聊
|
 |
50
chairuosen 2021-07-28 17:49:19 +08:00
这跟 HTTPS 原理不一样，这是"两军问题"，无解
|
|
52
Vegetable 2021-07-28 18:09:58 +08:00 1
@FS1P7dJz 之前也有帖子讨论过类似问题。iMessage 说到底不是一个在国内诞生的产品，作为一个面向其他地区设计的产品，做成这样自然是非常合理的。它引入中国究竟没有做出牺牲我们都不知道，但是诞生在国内，并面向国内用户，宣称端到端加密的聊天软件，貌似不会有什么好下场。
|
 |
53
JamesMackerel 2021-07-28 18:10:38 +08:00 via iPhone
双方线下交换公钥，随后在使用聊天软件时，每次都把要发送的消息用对面的公钥进行 gpg 加密再发送。稳得一批，微信也可以很安全。
|
 |
54
jiayong2793 2021-07-28 18:13:45 +08:00
政治上不允许
|
 |
55
huangmingyou 2021-07-28 18:15:40 +08:00
我手工用 gpg 加密内容，然后通过微信发送也可以啊，解密也是手工。也许可以把加密解密做到输入法？通过现成的 im 工具传输加密后的内容？
|
 |
56
adsltsee94 2021-07-28 18:22:09 +08:00
小飞机不就是么
|
 |
57
RainyH2O 2021-07-28 18:23:58 +08:00
就是因为你这想法会被中间人攻击，所以才出现 CA 机构来颁发 CA 证书解决中间人攻击的啊。
有了 CA 证书，就有了 SSL，就有了 HTTPS 。SSL 还通过密钥交换确保前向安全性。 基于 SSL 的话就只有发信方和收信方能解读加密密文了，中间人劫持封包就得面对大数分解或者离散对数的数学难题。 我没看懂你觉得哪里还有问题，可能你没把 SSL/TLS 的原理学通透。 |
 |
58
clf 2021-07-28 18:28:48 +08:00
有这样的软件了，而且还是国内的，使用者很少罢了，个人觉得存在运营风险。
|
|
59
RainyH2O 2021-07-28 18:47:47 +08:00 1
至于市面上的 IM 软件为何不用这套方案，一方面是出于多端信息同步的需求，一方面就是上面提及的非技术因素了。
实际 IM 卖的是一个社交服务，真正的隐私 IM 应该只是卖一个通讯录，类似一个 DNS 让双方能互相找到彼此建立 SSL 会话即可。 |
 |
60
treblex 2021-07-28 18:54:22 +08:00
我最近在做一个手动加密的聊天工具，就是 app 本地维护一个公钥列表和消息列表，然后可以复制加密后的内容发送给朋友
暂时没考虑做服务端 |
 |
61
Dogtler 2021-07-28 18:54:39 +08:00 via iPhone
在国内别想了
|
|
62
treblex 2021-07-28 19:13:22 +08:00
@treblex 楼主的想法应该跟我这个差不多，就是客户端加密消息，服务端制作标准实现
但是运营不了，国内似乎要求必须有审查的能力，存密文的话没啥用，除非你把用户私钥存了😂 https://www.v2ex.com/t/745797 现在手上这个 app 只打算做到这个程度了 后端如果做的话，最好是能做一个标准或者开源实现给用户自己部署和开发，在 app 上设置服务器地址（实力不足 |
 |
64
treemonster 2021-07-28 20:09:56 +08:00 via Android
|
 |
65
nullcoder 2021-07-28 20:44:18 +08:00 via Android
啊，还以为会看到量子纠缠
|
 |
66
ck19920702 2021-07-28 21:28:56 +08:00
|
 |
67
v2clay 2021-07-28 21:29:25 +08:00
1. 你说的就是 rsa 公钥密码体系的雏形
2. ca 是为了解决中间人攻击的。 3.如果外层套一层 tls 。那么底层不需要 rsa，对称加密就行，效率还高。 4.此贴终结 |
|
68
v2clay 2021-07-28 21:31:54 +08:00
建议多读书，把 rsa 吃透。
|
 |
69
sholmesian 2021-07-28 22:25:53 +08:00
推荐楼主看看 XMPP 的
XEP-0384: OMEMO https://xmpp.org/extensions/xep-0384.html XEP-0364: OTR https://xmpp.org/extensions/xep-0364.html |
 |
70
railgun 2021-07-28 23:58:17 +08:00
通信加密已经不是一个技术问题了……
|
 |
71
agee 2021-07-29 00:28:59 +08:00 via iPhone
防中间人又不用根证书的话，只有上 ecdh 算法，可自行谷歌，真正实现不用见面的情况安全交换密钥，防中间人攻击腾讯就是用的 ecdh
|
 |
72
kirch 2021-07-29 00:29:31 +08:00
首先，不能有中心服务器
|
 |
73
Hardrain 2021-07-29 01:15:19 +08:00
"若无，则先请求 B 传输公钥过来，B 生成公私钥并缓存在本地。"
这就像一个没有 CA 的 TLS, 或者一个不校验证书有效性的糟糕 TLS 实现, 对中间人攻击没有任何免疫力. 跟你的想法类似的是 GPG, 但 GPG 的开发者认为, 交换密钥应该以"线下碰面"的形式完成. 以上是技术问题, 至于政治 /法律问题我不做讨论. 你认为微信如果想实现类似的技术, 不会受到阻力吗? |
|
74
Hardrain 2021-07-29 01:17:00 +08:00
@agee ECDH 是椭圆曲线域上的 Diffie-Hellman, 照样需要签名.
例如 TLS 的加密套件, ECDHE_RSA_* 和 ECDHE_ECDSA_* 中的 RSA 和 ECDSA 就是签名算法. |
 |
75
iseki 2021-07-29 01:30:49 +08:00
恕我孤陋寡闻，中间人攻击基本上只能通过证书或者类似的其他“预共享的信息”来实现，你这里好像根本没提到对这个问题的解决方案。如果不想引入证书也可以参考下 Telegram 的 secret chat，两边用户可以通过对比一个颜色点阵来确保没有被中间人攻击。
|
 |
76
bs10081 2021-07-29 02:30:40 +08:00
Rocket.Chat?
|
 |
77
parametrix 2021-07-29 06:08:34 +08:00
1. 只用 RSA 效率低，也没必要，而且不是所有设备都有个人电脑的算力，就算有也不应该挥霍。
2. 只用 RSA 缺乏一些关键的安全特征，比如完全向前安全性。TLS 标准算法里头一长串又不是为了炫技。 3. 解决中间人问题要不然由第三方担保，要不然就是预共享密钥做 HMAC 。然而有预共享密钥的前提下，可以直接 HMAC 配合密钥交换算法进行端对端加密通信，RSA 反而不是必要的，徒增消耗。 4. 市面上端对端加密解决方案不是有没有，而是太多了，商业的、社区的应有尽有。 PS：好奇楼主认为 https 是怎么实现的？ |
 |
78
vagranth 2021-07-29 06:30:50 +08:00 via Android
https://github.com/evilcorpltd/aTox
tox 协议可以看看 |
 |
79
fan123199 2021-07-29 07:50:40 +08:00
lz 写的方案太初级，就像有个人说，我发现了用 break 可以退出 for 循环一样。 不过想要隐私通讯的想法是很 ok 的，可以多了解下评论里提及的开源软件。不说了，我也学习去
|
 |
80
MarkLeeyun 2021-07-29 08:45:02 +08:00
大陆应该不存在能商用的这玩意。
|
 |
81
love2020 2021-07-29 08:59:52 +08:00
没有绝对安全的网络
|
 |
83
wy315700 2021-07-29 09:23:57 +08:00
iMessage 好像就是这么设计的
|
 |
84
lonnyzhang 2021-07-29 09:30:33 +08:00
去看 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 的值难度很大，包括服务端。 |
 |
85
Rcnaec 2021-07-29 09:33:38 +08:00
歪个楼，目前对于端对端加密的聊天软件监控的通杀方式，是监控顶部通知栏
|
 |
86
lingxi27 2021-07-29 09:48:42 +08:00
密码学很有趣的，建议多学点
|
 |
87
newmlp 2021-07-29 09:53:06 +08:00
这不就是 tls 的原理吗，直接拿 tls 来用不就行了
|
 |
88
pkoukk 2021-07-29 10:01:13 +08:00
建议了解一下 telegram 的实现，加密不仅要考虑前向安全，还得考虑后项安全。
如果秘钥泄露，那么你的所有信息都会泄露。 tg 用了双棘轮算法保证每条消息的秘钥都是不一样的 |
 |
89
ilaipi 2021-07-29 10:33:13 +08:00
曾经做过一个利用邮箱实现类似聊天方式的。完全不需要服务器，没做完流产了
|
 |
90
misaka19000 2021-07-29 10:39:05 +08:00
楼主多去读点书吧，别做民科
|
 |
91
Kareless 2021-07-29 10:43:28 +08:00
这不就是 telegram 吗
|
 |
92
Joshua999 2021-07-29 11:41:34 +08:00 via Android
A 怎么知道收到的公钥是 B 发来的
|
 |
93
NilChan 2021-07-29 11:46:12 +08:00 via Android
思而不学则殆。看一下 HTTPS 工作原理就知道了。另外 RSA 一般用来加密对称密钥，而不是消息本身。
|
 |
94
villivateur 2021-07-29 11:56:23 +08:00 via Android
楼主可能刚刚了解非对称加密原理，然后就想了这一出。
但是还是要多读书啊 |
 |
95
Rheinmetal 2021-07-29 11:58:57 +08:00
读这个之前没人教你 don't make your own crypto 么
真密谈应该明文配 one time pad |
 |
96
DBT 2021-07-29 11:59:14 +08:00
@earneet 说的很对，有个细节需要更正，RSA 算法由于 PKCS#1 补丁的关系，单次加密最大数据长度为 117 字节，嘿嘿。
|
 |
97
LLaMA2 2021-07-29 12:13:55 +08:00
想要 End to End 的加密，首要解决的是两端交换的密钥确实是他们自己说的密钥，而不是由中间人篡改后的密钥。上面网友说的面对面交换密钥就能保证到。
|
 |
98
wlbyg888 2021-07-29 13:00:40 +08:00 via Android
技术早就有了！落地应用，环境不现实
|
 |
99
doveyoung 2021-07-29 13:44:50 +08:00
怎么说呢，楼主能来 v2，竟然不知道 telegram 吗
|
 |
100
GeruzoniAnsasu 2021-07-29 13:48:21 +08:00
|
Select Language