https中加密算法的密钥是随机生成吗？和用户帐号密码有什么关联？

Posted 2021-04-30 车小胖谈网络

刚了解这些原理，不是专业人士，所以不懂，望指教。一般用的rsa+aes混合加密算法，密钥是随机的吗？不会存在直接用帐户密码（口令）来作为密钥加密数据的吧？加解密的密钥和用户帐号的密码（口令）有一定的相似或者关联吗？比如现在一个黑客截取了被https加密后的数据包，同时知道我的帐号密码了（但是他无法登陆帐号，因为有登陆保护），用暴力破解，是否能更快破解加密数据的密钥出来呢？

正文

密钥是随机生成的，和账户密码没有关联。题主提到的RSA算法，在这个问题里，RSA不仅仅充当认证算法，还充当密钥交换（Key Exchange）算法。


RSA认证算法

客户端请求服务器RSA数字证书，服务器将自己的证书、给自己签名的二级CA证书、给二级CA签名的一级CA证书，一股脑发给客户端。客户端验证以上三个证书形成的证书链，信任的源头就是操作系统/浏览器早已安装的一级CA证书明文公钥。认证完成会进入下一个环节，RSA密钥交换算法。

RSA密钥交换算法

客户端调用伪随机函数PRF，PRF返回一串伪随机字符串，字符串被客户端永服务器RSA证书公钥加密，发给服务器。服务器使用RSA证书私钥解密，获取明文字符串。至此双方共同分享了一个共同的秘密，“伪随机字符串”，双方以此为素材，共同推导出AES对称加密/解密“密钥”，推导过程略。

伪随机函数

完全随机函数很难实现，所以才有了伪随机函数的叫法，意思是接近随机。为了让PRF输出的字符串最大可能随机，可以将用户滑动鼠标的轨迹取样生成随机素材，也可以以当前时间+ 随机数的组合，然后选择感兴趣素材为输入量，运行Hash函数，得到伪随机字符串。

 

用户身份认证

完成了以上安全通信准备工作，一个HTTPS加密通道就建立了起来。

 

为了让用户能访问自己的账户，需要先验证用户的身份。

 

为了最大限度保护用户密码安全，在任何场合下绝对避免用户密码在Internet上传输，即使有HTTPS保护也不行，甚至用户明文密码在传输前使用MD5加密也不行。

 

为了满足以上约束条件，需要将用户密码加盐（Salt）处理，即用户密码MD5 散列+ 一次性随机码组合，将这个组合再计算MD5散列值，得到一次性验证密码。

 

服务器运行同样的算法，如果双方的一次性验证密码匹配，用户认证成功，否则认证失败。

 

将来即使有第三方破解了HTTPS加密/解密的密钥，但是依然无法获取用户明文密码，甚至连用户密码的MD5散列值也无法获取。

 

为了最大限度保护数据传输安全，通常需要很多功能模块的协作。为了防止某一环节出问题而造成系统性风险，通常会做这样的假设，如果其他模块不安全了（被破解），能否最大限度保护数据的安全，保护用户的隐私（密码）！

 

这个术语叫PFS，Perfect  Forward  Secrecy，通俗地说，一个小兵掉链子，不能影响帝国集团军整体掉链子！

 

 

RSA一身兼二职模式不满足PFS要求

如果某一天RSA证书的私钥泄露了，那么可以用私钥解开公钥加密的随机字符串，进而推导出AES加密密钥，然后将用户历史加密数据全部解密。

 

但即使用户传输的数据被解密了，但是用户的密码从来没有在数据中传输，所以依然无法得到用户明文密码、甚至密码的MD5散列值。

 

TLS 1.3为何要完全抛弃RSA密钥交换算法？

答案上文已经回答了，一个环节掉链子（证书私钥泄露），所有用该RSA证书分发密钥的历史数据全部躺枪。

 

TLS 1.3只留下满足PFS条件的密钥交换算法：DHE算法。

 

DHE算法

E代表Ephemeral，临时的、一次性的，交换的密钥只使用一段时间，然后需要双方重新交换DHE密钥素材，这样即使被第三方破解了其中一段密钥，也只能解密这一段的数据，其它数据依然是安全的。