对称加密、非对称加密算法，数字证书

先看这里有一篇科普文章：https加密

对称加密：对称加密
对称加密用的是同一个密钥来加密和解密，所以，密钥需要在网络中传输（A把密钥发给B），
所以需要安全的密钥加密算法（数学理论保证可靠）：密钥交换算法

注意：密钥交换算法 结果 就是协商一个双方共用的密钥，至于廖老板文章内提到的交换算法内部又涉及到的A、a、B、b起到的类似于公私钥的功能可以忽略。

非对称加密：非对称加密

非对称加密使用对方的公钥加密，对方的私钥自己来解密；比如 A需要发送给B ：名字为File的文件，A先问B要B的公钥，A拿这个公钥给file加密，然后在网络中发送给B；B使用自己的密钥解密file即可；

---

既然非对称加密这么好，那抛弃对称加密，完全使用非对称加密行不行？

也不行。因为非对称加密的缺点就是运算速度非常慢，比对称加密要慢很多。

所以，在实际应用的时候，非对称加密总是和对称加密一起使用。假设小明需要给小红需要传输加密文件，他俩首先交换了各自的公钥（把上面非对称加密例子中的文件File换成对称加密的密钥即可），然后：

1. 小明生成一个随机的AES口令（对称加密公用的私钥），然后用小红的公钥通过RSA加密这个口令，并发给小红；
2. 小红用自己的RSA私钥解密得到AES口令；
3. 双方使用这个共享的AES口令用AES加密通信。

上面只有1、2步骤是非对称加密过程，目的在保证对称加密的密钥的传输安全，
步骤3及之后的真正的数据传递，就用对称加密来work了。

这也是我们在浏览器中常用的HTTPS协议的做法，即浏览器和服务器先通过RSA交换AES口令，接下来双方通信实际上采用的是速度较快的AES对称加密，而不是缓慢的RSA非对称加密。

但是，其实还存在一个问题就是，双方非对称加密协商的过程中，如果有中间人假冒双方，也会有问题（类似于网络中的ARP欺骗）

解决办法，就是要用到证书来解决（起到公证作用）

过程大致是这样：

1.小宇请求班长用证书私钥对公钥D进行加密，然后把加密后的D传给闪客，这个时候，虽然班长的公钥所有人都知道，也就是说所有人都可以解锁，但是中间坏蛋就算解锁了，也没有办法伪造这个D，因为只有班长的私钥可以加密；闪客用班长公钥解密，拿到D，用D加密锁M，发给小宇，中间人就无计可施了（没有D的私钥C，无法解密D加密的信息）。

可是如果班长同坏蛋勾结，把 J 泄漏或者卖给了坏蛋怎么办呢？
那没辙，说明他不配当班长！换句话说，如果证书机构CA都不可信了，那整个互联网都不可信了。

其实加密的过程永远有那么第一次的明文内容，会被中间人篡改。

怎么消除这个第一次明文的尴尬呢？
就是通过CA 机构。

CA 机构那边也有一套公私钥。

服务端把自己的公钥给 CA，让 CA 用 CA 的私钥加密，然后返回加密结果。
然后这个加密结果，可以用 CA 的公钥解，谁都可以解开。

但是，如果要篡改结果，必须再次用 CA 的私钥加密，可是这个做不到，只要 CA 不是坏蛋即可。

这就做到了第一次的明文传输的公钥，只能被看，无法被篡改。
于是中间人就只能眼睁睁看着一个自己知道的公钥，从服务端传给客户端。
然后客户端用这个公钥，给之后对称加密的秘钥加密，传给服务端，中间人由于不知道服务端私钥，解不开。

于是，客户端和服务端，有了一个中间人不知道的，解不开的对称秘钥。
之后就 OK 了。

这也是我们在浏览器中常用的HTTPS协议的做法：闪客就是客户端，小宇就是服务端，班长就是 CA 机构，中间那些坏蛋同学就是传输链路。

PS：我们用charlse 抓https包之前，要安装信任证书，也就是上面的原因。

关于数字证书的问题，可以参考这里：一文读懂加密与证书