互联网|万字长文拿下HTTPS,面试不再慌!( 四 )



这个问题该怎么解决呢?一般来说除非是双方私下约定好了密钥 , 如果是每次通信都会发生变化的密钥是不能在通信过程中带给对端 , 这样你就陷入了要给密钥加一次密的尴尬境地 。 所以 , 就出现了非对称加密(也叫公钥加密算法) 。
它有两个密钥 , 一个叫公钥(public key) , 一个叫 私钥(private key) 。 两个密钥是不同的 , 不对称 , 公钥可以公开给任何人使用 , 而私钥必须严格保密 。
公钥和私钥有个特别的单向 性 , 虽然都可以用来加密解密 , 但公钥加密后只能用私钥解密 , 反过来 , 私钥加密后也只能用公钥解密 。
非对称加密可以解决密钥交换的问题 。 网站秘密保管私钥 , 在网上任意分发公钥 , 你想要登录网站只要用公钥加密就行了 , 密文只能由私钥持有者才能解密 。
而黑客因为没有私钥 , 所以就无法破解密文 。
互联网|万字长文拿下HTTPS,面试不再慌!
本文插图
非对称加密算法的设计要比对称算法难得多 , 在 TLS 里只有很少的几种 , 比如 DH、DSA、RSA、ECC 等 。

RSA 可能是其中最著名的一个 , 几乎可以说是非对称加密的代名词 , 它的安全性基于整数分解的数学难题 , 使用两个超大素数的乘积作为生成密钥的材料 , 想要从公钥推算出私钥是非常困难的 。

10 年前 RSA 密钥的推荐长度是 1024 , 但随着计算机运算能力的提高 , 现在 1024 已经不安全 , 普遍认为至少要 2048 位 。
ECC(Elliptic Curve Cryptography)是非对称加密里的后起之秀 , 它基于椭圆曲线离散对数的数学难题 , 使用特定的曲线方程和基点生成公钥和私钥 , 子算法 ECDHE 用于密钥交换 , ECDSA 用于数字签名 。
ECDHE 即使用椭圆曲线(ECC)的 DH 算法 , 优点是能用较小的素数(256 位)实现 RSA 相同的安全等级 。
缺点是算法实现复杂 , 用于密钥交换的历史不长 , 没有经过长时间的安全攻击测试 。
目前比较常用的两个曲线是 P-256(secp256r1 , 在 OpenSSL 称为 prime256v1)和 x25519 。
P-256 是 NIST(美国国家标准技术研究所)和 NSA(美国国家安全局)推荐使用的曲线 , 而 x25519 被认为是最安全、最快速的曲线 。
比起 RSA , ECC 在安全强度和性能上都有明显的优势 。 160 位的 ECC 相当于 1024 位的 RSA , 而 224 位的 ECC 则相当于 2048 位的 RSA 。
因为密钥短 , 所以相应的计算量、消耗的内存和带宽也就少 , 加密解密的性能就上去了 , 对于现在的移动互联网非常有吸引力 。
混合加密
看到这里你是不是认为可以抛弃对称加密 , 只用非对称加密来实现机密性呢?

很遗憾 , 虽然非对称加密没有 密钥交换 的问题 , 但因为它们都是基于复杂的数学难题 , 运算速度很慢 , 即使是 ECC 也要比 AES 差上好几个数量级 。
如果仅用非对称加密 , 虽然保证了安全 , 但通信速度有如乌龟、蜗牛 , 实用性就变成了零 。
是不是能够把对称加密和非对称加密结合起来呢 , 两者互相取长补短 , 即能高效地加密解密 , 又能安全地密钥交换 。
这就是现在 TLS 里使用的混合加密方式 , 其实说穿了也很简单:在通信刚开始的时候使用非对称算法 , 比如 RSA、ECDHE , 首先解决密钥交换的问题 。
然后用随机数产生对称算法使用的 「会话密钥」(session key) , 再用公钥加密 。 因为会话密钥很短 , 通常只有 16 字节或 32 字节 , 所以慢一点也无所谓 。
对方拿到密文后用私钥解密 , 取出会话密钥 。 这样 , 双方就实现了对称密钥的安全交换 , 后续就不再使用非对称加密 , 全都使用对称加密 。
互联网|万字长文拿下HTTPS,面试不再慌!


推荐阅读