这是一个创建于 2785 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近看了点非对称加密的一些文章，
产生了一些疑问，不知道有没有有缘人可以帮忙解答。
如果要把这种加密加到聊天中去，我的想法是这样的： 每个客户端生成一份公钥发送给服务端，服务端也生成一份给每个客端。
这样应该就可以实现每条消息都只有两方可以查看，不过服务器需要维护一份用户和用户公钥的对应关系，在每次发送消息时取出来再对消息进行加密。
有个不知道对不对的想法：
如果像 https 一样用自己的私钥进行加密，客户端用服务端的公钥解开也能实现加密，不过这消息所有的客户端都能解开了，这样也不好。
我的问题是：
这种对于多客户端的加密，如何才能做到加密的且高效？
找了一些资料，并没有找到答案，当然你也可以： http://dwz.cn/5EbYc7 （手动滑机）
 |
1
lcdtyph 2017-03-30 13:21:54 +08:00
非对称加密主要应用在秘钥协商阶段
协商好秘钥之后的通信就用对称加密了 这样子只需要服务端有一份公钥私钥对就可以了，通信秘钥是一次一密的 |
 |
2
ryd994 2017-03-30 13:27:00 +08:00
明显错误用法
发给谁就用谁的公钥加密，服务器不需要解密，原样转发即可 还是说你就说想要偷看别人内裤而已？ 要发给服务器的数据，用服务器公钥加密 |
 |
3
jybox 2017-03-30 13:29:12 +08:00
http://images.apple.com/cn/business/resources/docs/iOS_Security_Guide.pdf
可以看一下关于 IDS 和 iMessage 的部分。 |
 |
4
nilai 2017-03-30 13:36:53 +08:00
本地生成随机数作为对称加密的密钥 + 服务器公钥加密随机数 这两东西一起发送给服务器就行
|
 |
5
monsterxx03 2017-03-30 13:39:39 +08:00
非对称加密不是用来直接加密数据的，和一楼说的一样用来做密钥协商，拿 DES 来说，可加密数据的长度和公钥的长度有关, 根本没法直接拿来加密数据。
每个 client 和 server 在协商阶段生成一个随机字符串作为密钥，非对称加密用来加密这个密钥，实际数据用密钥进行对称加密。每个 client 的 server 之间的会话密钥只有他们两者知道，而又只有 server 的私钥能解密实际的会话密钥。 https 大概就这个过程，多了 CA |
 |
7
rrfeng 2017-03-30 13:58:48 +08:00  1
非对称加密也可以用来加密数据。
但是用法是反的：要给 A 发数据，那么用 A 的公钥加密，只有 A 的私钥才能解开。而 A 的私钥是只有 A 自己知道的。所以可以做到『任何一个人都可以给 A 发送只有 A 能解密的消息』。 |
|
8
rrfeng 2017-03-30 14:00:14 +08:00
@byfar
这里面很重要的一点是非对称加密算法普遍很慢，对称加密算法很快而且大部分有硬件指令加速。所以最终传输的数据大都是对称加密的。 |
 |
11
SBEer 2017-03-30 14:08:17 +08:00
通信加密的话个人人为 OTR 比单纯的公钥加密更清真
https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html |
 |
12
RqPS6rhmP3Nyn3Tm 2017-03-30 14:17:57 +08:00 via iPhone
我认为你应该尝试一下 OTR ，是专为这种情况设计的
|
 |
13
zzh1823 2017-03-30 14:25:47 +08:00
@SBEer 清真是啥意思。。。 OTR 用的是 DH 算法交换秘钥，然后是 AES 对称加密，这种方式胜在轻，对报文比较友好，但是中间人攻击一直是问题；现在主流都是用 RSA 公钥来加密交换 AES 秘钥，缺点就是报文很重， https 就是这么做的。
|
 |
14
byfar OP @monsterxx03 https 不是用自己的私钥加密的吗，看来一直都理解错了
|
 |
15
noli 2017-03-30 14:40:55 +08:00
非对称密钥算法甚少用于直接加密消息。
多用于密钥协商（使用对称密钥建立通信信道的时候，双方协商用什么对称密钥，关键字 “ DH 交换”）， 消息摘要和签名（验证消息的完整性和发送者的身份， 关键字 “ DSA ” digital signature algorithem ） |
 |
16
thekll 2017-03-30 16:49:54 +08:00 via iPhone
这种需求就是端到端加密，中间节点都不可信，包括作为中转的服务端。同时还要考虑前向安全问题（ pfs ）。
Whatsapp 、 Signal 好像已经支持。 邮件的话许多客户端支持 pgp 。 |
 |
17
crashX 2017-03-30 18:21:11 +08:00
感觉你这个需求像 U 盾，客户端需要存一个私钥，比较麻烦。
|
|
20
thekll 2017-03-31 11:14:35 +08:00 via iPhone
中间节点指的是 server host ，比如邮件服务、微信服务等。
|
|
21
SBEer 2017-03-31 15:42:17 +08:00
@zzh1823 请阅读"Authenticated Key Exchange (AKE)"段，仍有兴趣的话还可以了解下“ Socialist Millionaires' Protocol (SMP)”
|
|
22
thekll 2017-03-31 15:44:15 +08:00 via iPhone
之前没看清你的要求，以为是想要端到端加密。实际上是对 TLS 理解不对，才会出现这种奇怪的想法。
TLS1.2 握手过程主要是完成服务端身份验证以及 key 交换，这个 key 用于实际的加解密。如果需要对每个客户端也进行证书验证，可以要求客户端提供自己的证书。实际的加解密 key 是和某次会话关联的，即使同一个客户端，这个 key 也可能不同，所以并不存在你说的情况。 TLS 支持 Static RSA 和 DH 两种方式实现 key 交换，前者用到了公私钥加解密，但存在 PFS 问题， TSL1.3 草案已经废弃。 另外公钥不能解密私钥加密的内容，一般用于加密和验证（非对称）。 |
|
23
zzh1823 2017-03-31 16:03:36 +08:00 via Android
@SBEer 。。。 RSA 的公钥实际上也是拿来做 key exchange 的，你提到的这个协议做 ake 就是用的 DH 啊。。清真是说实现起来轻么？
|
|
24
SBEer 2017-03-31 16:37:33 +08:00
@zzh1823 你自然可以用 signature based 的 DH 如 ECDHE 甚至直接拿 RSA 签名也行,但是 OTR 比传统的非对称加密多提供 forward secrecy 和 deniable authentication 。 forward secrecy ，即前向加密，保证私钥泄露后，攻击者无法根据之前的通信记录恢复通信明文。 deniable authentication, 保证在认证过程中不会泄露私钥信息(具体通过 SMP 实现)。一个可以接受的做法是利用 NTRU 公钥加密 psk 然后通过 SMP 验证通信对端，然后利用 psk 生成一个临时信道完成密钥交换，但这种方法依旧不够清真。对比 NTRUSign,SMP 依旧不会泄漏私钥信息。目前最清真的方法比较复杂,比较关于 NTRU 的研究还不够充分，而且，你并不知道哪天会突然冒出来一个量子通用计算机。
|
|
25
SBEer 2017-03-31 16:42:34 +08:00
@zzh1823 对于群聊环境，你可以看一下 Muti-party Off-the-record(mpOTR)。
https://www.cypherpunks.ca/~iang/pubs/mpotr.pdf |
Select Language