关于非对称加密在实际中应用的一些疑问

[byfar]

最近看了点非对称加密的一些文章，

产生了一些疑问，不知道有没有有缘人可以帮忙解答。

如果要把这种加密加到聊天中去，我的想法是这样的： 每个客户端生成一份公钥发送给服务端，服务端也生成一份给每个客端。

这样应该就可以实现每条消息都只有两方可以查看，不过服务器需要维护一份用户和用户公钥的对应关系，在每次发送消息时取出来再对消息进行加密。

有个不知道对不对的想法：

如果像 https 一样用自己的私钥进行加密，客户端用服务端的公钥解开也能实现加密，不过这消息所有的客户端都能解开了，这样也不好。

我的问题是：

这种对于多客户端的加密，如何才能做到加密的且高效？

找了一些资料，并没有找到答案，当然你也可以： http://dwz.cn/5EbYc7 （手动滑机）

[lcdtyph]

非对称加密主要应用在秘钥协商阶段
协商好秘钥之后的通信就用对称加密了
这样子只需要服务端有一份公钥私钥对就可以了，通信秘钥是一次一密的

[ryd994]

明显错误用法
发给谁就用谁的公钥加密，服务器不需要解密，原样转发即可
还是说你就说想要偷看别人内裤而已？
要发给服务器的数据，用服务器公钥加密

[jybox]

http://images.apple.com/cn/business/resources/docs/iOS_Security_Guide.pdf
可以看一下关于 IDS 和 iMessage 的部分。

[nilai]

本地生成随机数作为对称加密的密钥 + 服务器公钥加密随机数 这两东西一起发送给服务器就行

[monsterxx03]

非对称加密不是用来直接加密数据的，和一楼说的一样用来做密钥协商，拿 DES 来说，可加密数据的长度和公钥的长度有关, 根本没法直接拿来加密数据。

每个 client 和 server 在协商阶段生成一个随机字符串作为密钥，非对称加密用来加密这个密钥，实际数据用密钥进行对称加密。每个 client 的 server 之间的会话密钥只有他们两者知道，而又只有 server 的私钥能解密实际的会话密钥。 https 大概就这个过程，多了 CA

[byfar]

@lcdtyph 用非对称加密来传输对称加密用的密钥，好像可以解决问题， 但总感觉不是很赞啊

[rrfeng]

非对称加密也可以用来加密数据。
但是用法是反的：要给 A 发数据，那么用 A 的公钥加密，只有 A 的私钥才能解开。而 A 的私钥是只有 A 自己知道的。所以可以做到『任何一个人都可以给 A 发送只有 A 能解密的消息』。

[rrfeng]

@byfar
这里面很重要的一点是非对称加密算法普遍很慢，对称加密算法很快而且大部分有硬件指令加速。所以最终传输的数据大都是对称加密的。

[byfar]

@ryd994 对对对，我不偷看别人内裤，不过如果不是在发送消息的这个假设下，会不会有这种方式？

[byfar]

@jybox 感谢感谢

[SBEer]

通信加密的话个人人为 OTR 比单纯的公钥加密更清真
https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html

[RqPS6rhmP3Nyn3Tm]

我认为你应该尝试一下 OTR ，是专为这种情况设计的

[zzh1823]

@SBEer 清真是啥意思。。。 OTR 用的是 DH 算法交换秘钥，然后是 AES 对称加密，这种方式胜在轻，对报文比较友好，但是中间人攻击一直是问题；现在主流都是用 RSA 公钥来加密交换 AES 秘钥，缺点就是报文很重， https 就是这么做的。

[byfar]

@monsterxx03 https 不是用自己的私钥加密的吗，看来一直都理解错了

[noli]

非对称密钥算法甚少用于直接加密消息。

多用于密钥协商（使用对称密钥建立通信信道的时候，双方协商用什么对称密钥，关键字 “ DH 交换”），
消息摘要和签名（验证消息的完整性和发送者的身份， 关键字 “ DSA ” digital signature algorithem ）

[thekll]

这种需求就是端到端加密，中间节点都不可信，包括作为中转的服务端。同时还要考虑前向安全问题（ pfs ）。

Whatsapp 、 Signal 好像已经支持。
邮件的话许多客户端支持 pgp 。

[crashX]

感觉你这个需求像 U 盾，客户端需要存一个私钥，比较麻烦。

[byfar]

@noli 赞

[byfar]

@thekll 如果加密后在节点传递，节点不可信应该无碍吧？

[thekll]

中间节点指的是 server host ，比如邮件服务、微信服务等。