实现想法:
A 发送消息给 B
检测是否持有 B 的公钥
若有,使用 B 的公钥对消息进行 RSA 加密并发送。
若无,则先请求 B 传输公钥过来,B 生成公私钥并缓存在本地。
B 收到消息后,使用自己的私钥进行消息解密。
B 发送消息给 A
同理
我想,这样应该才是能实现真正隐私通讯的,连服务提供方都无法窃取消息的,而不是市面上一些聊天软件慌称的“隐私”。
这种通讯隐私方案可实现吗?会有软件愿意为了用户隐私而实现吗?
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
|