V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
byfar
V2EX  ›  程序员

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

  •  
  •   byfar · 2017-03-30 13:10:49 +08:00 · 5130 次点击
    这是一个创建于 2796 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

    我的问题是:

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

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

    26 条回复    2017-03-31 16:45:20 +08:00
    lcdtyph
        1
    lcdtyph  
       2017-03-30 13:21:54 +08:00
    非对称加密主要应用在秘钥协商阶段
    协商好秘钥之后的通信就用对称加密了
    这样子只需要服务端有一份公钥私钥对就可以了,通信秘钥是一次一密的
    ryd994
        2
    ryd994  
       2017-03-30 13:27:00 +08:00
    明显错误用法
    发给谁就用谁的公钥加密,服务器不需要解密,原样转发即可
    还是说你就说想要偷看别人内裤而已?
    要发给服务器的数据,用服务器公钥加密
    jybox
        3
    jybox  
       2017-03-30 13:29:12 +08:00
    http://images.apple.com/cn/business/resources/docs/iOS_Security_Guide.pdf
    可以看一下关于 IDS 和 iMessage 的部分。
    nilai
        4
    nilai  
       2017-03-30 13:36:53 +08:00
    本地生成随机数作为对称加密的密钥 + 服务器公钥加密随机数 这两东西一起发送给服务器就行
    monsterxx03
        5
    monsterxx03  
       2017-03-30 13:39:39 +08:00
    非对称加密不是用来直接加密数据的,和一楼说的一样用来做密钥协商,拿 DES 来说,可加密数据的长度和公钥的长度有关, 根本没法直接拿来加密数据。

    每个 client 和 server 在协商阶段生成一个随机字符串作为密钥,非对称加密用来加密这个密钥,实际数据用密钥进行对称加密。每个 client 的 server 之间的会话密钥只有他们两者知道,而又只有 server 的私钥能解密实际的会话密钥。 https 大概就这个过程,多了 CA
    byfar
        6
    byfar  
    OP
       2017-03-30 13:58:37 +08:00
    @lcdtyph 用非对称加密来传输对称加密用的密钥,好像可以解决问题, 但总感觉不是很赞啊
    rrfeng
        7
    rrfeng  
       2017-03-30 13:58:48 +08:00   ❤️ 1
    非对称加密也可以用来加密数据。
    但是用法是反的:要给 A 发数据,那么用 A 的公钥加密,只有 A 的私钥才能解开。而 A 的私钥是只有 A 自己知道的。所以可以做到『任何一个人都可以给 A 发送只有 A 能解密的消息』。
    rrfeng
        8
    rrfeng  
       2017-03-30 14:00:14 +08:00
    @byfar
    这里面很重要的一点是非对称加密算法普遍很慢,对称加密算法很快而且大部分有硬件指令加速。所以最终传输的数据大都是对称加密的。
    byfar
        9
    byfar  
    OP
       2017-03-30 14:01:13 +08:00
    @ryd994 对对对,我不偷看别人内裤,不过如果不是在发送消息的这个假设下,会不会有这种方式?
    byfar
        10
    byfar  
    OP
       2017-03-30 14:01:26 +08:00
    @jybox 感谢感谢
    SBEer
        11
    SBEer  
       2017-03-30 14:08:17 +08:00
    通信加密的话个人人为 OTR 比单纯的公钥加密更清真
    https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html
    RqPS6rhmP3Nyn3Tm
        12
    RqPS6rhmP3Nyn3Tm  
       2017-03-30 14:17:57 +08:00 via iPhone
    我认为你应该尝试一下 OTR ,是专为这种情况设计的
    zzh1823
        13
    zzh1823  
       2017-03-30 14:25:47 +08:00
    @SBEer 清真是啥意思。。。 OTR 用的是 DH 算法交换秘钥,然后是 AES 对称加密,这种方式胜在轻,对报文比较友好,但是中间人攻击一直是问题;现在主流都是用 RSA 公钥来加密交换 AES 秘钥,缺点就是报文很重, https 就是这么做的。
    byfar
        14
    byfar  
    OP
       2017-03-30 14:30:49 +08:00
    @monsterxx03 https 不是用自己的私钥加密的吗,看来一直都理解错了
    noli
        15
    noli  
       2017-03-30 14:40:55 +08:00
    非对称密钥算法甚少用于直接加密消息。

    多用于密钥协商(使用对称密钥建立通信信道的时候,双方协商用什么对称密钥,关键字 “ DH 交换”),
    消息摘要和签名(验证消息的完整性和发送者的身份, 关键字 “ DSA ” digital signature algorithem )
    thekll
        16
    thekll  
       2017-03-30 16:49:54 +08:00 via iPhone
    这种需求就是端到端加密,中间节点都不可信,包括作为中转的服务端。同时还要考虑前向安全问题( pfs )。

    Whatsapp 、 Signal 好像已经支持。
    邮件的话许多客户端支持 pgp 。
    crashX
        17
    crashX  
       2017-03-30 18:21:11 +08:00
    感觉你这个需求像 U 盾,客户端需要存一个私钥,比较麻烦。
    byfar
        18
    byfar  
    OP
       2017-03-31 08:56:02 +08:00
    @noli
    byfar
        19
    byfar  
    OP
       2017-03-31 08:59:27 +08:00
    @thekll 如果加密后在节点传递,节点不可信应该无碍吧?
    thekll
        20
    thekll  
       2017-03-31 11:14:35 +08:00 via iPhone
    中间节点指的是 server host ,比如邮件服务、微信服务等。
    SBEer
        21
    SBEer  
       2017-03-31 15:42:17 +08:00
    @zzh1823 请阅读"Authenticated Key Exchange (AKE)"段,仍有兴趣的话还可以了解下“ Socialist Millionaires' Protocol (SMP)”
    thekll
        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 草案已经废弃。
    另外公钥不能解密私钥加密的内容,一般用于加密和验证(非对称)。
    zzh1823
        23
    zzh1823  
       2017-03-31 16:03:36 +08:00 via Android
    @SBEer 。。。 RSA 的公钥实际上也是拿来做 key exchange 的,你提到的这个协议做 ake 就是用的 DH 啊。。清真是说实现起来轻么?
    SBEer
        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 的研究还不够充分,而且,你并不知道哪天会突然冒出来一个量子通用计算机。
    SBEer
        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
    zzh1823
        26
    zzh1823  
       2017-03-31 16:45:20 +08:00 via Android
    @SBEer 受教了,我好好消化下!
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1116 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 23:35 · PVG 07:35 · LAX 15:35 · JFK 18:35
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.