对称加密
两边用同一个密钥来加解密。
A把明文通过某一算法加密之后得到密文，然后把密文发送给B，B接收到密文之后用相同的密钥执行相同的算法去解密。X没有密钥，即使窃取到密文也无法窃听。
对称加密的有优缺点
- 对称加密的优点：加解密速度快
- 对称加密的缺点：会出现密钥分配问题；密钥容易复制，不便于安全保管
密钥分配问题
对称加密的存在密钥分配问题，A的密钥怎么才能安全的传输到B手里不被X获取到？A直接发送密钥给B还是可能被X窃取到这个密钥，这样加密信息等于是在裸奔了。
只有用密钥加密后的信息才能安全传输，但是只有保证安全传输的前提下才能发送这个密钥。
这个道理和下图一样
非对称加密
双方使用不同的密钥来加解密，并且不能通过一个密钥推算出另一个密钥。
- 公钥加密，私钥解密
- 私钥加密（数字签名），公钥解密
A把事先准备好了非对称密钥对，分别为公钥和私钥，这一套非对称密钥对能相互加解密。公钥是公开的，私钥只有自己才有。然后A把公钥发送给B，或者公钥放在服务器B自行下载。
B拿到了公钥后用公钥的一套算法加密信息后传输给A，A用私钥执行另一个算法解密获得明文信息。
推荐一个开源免费的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
非对称加密的优缺点
- 非对称加密的优点：不会出现密钥分配问题
- 非对称加密的缺点：加解密速度慢，仍有被窃听的隐患，原因和中间人攻击一样，后面会讲到。
既然对称加密和非对称加密都有缺点，那么我们能不能用一种方法结合一下他们的优点形成一套比较好的方案呢？答案是有的，那就是混合加密
混合加密
传输大量数据的时候使用对称加密，因为加解密速度快。但是由于对称加密有秘钥分配问题，所以我们用非对称加密来加密这个对称密钥再传递给对方。
我们会认为接下来的方案应该是比较完美了吧？
双向通信之前要先把公钥相互交换，比如A和B要通信
- A：这是我的公钥public_A，你收好，你生成对称密钥也给我一下
- B：好的，收到public_A，你收好对称密钥secretKey。然后用public_A加密这个secretKey
- A：收到消息，private_A解密出来是secretKey。
这就解决了对称密钥secretKey的密钥分配问题，然后双方就可以用secretKey加密消息进行通信了。
但是这还不够，这仍然会被中间人攻击！你怎么知道把公钥发送给对方时保证公钥没被篡改掉包呢？比如上面的例子被中间人攻击之后就变成了下面的样子
- A：这是我的公钥public_A，你收好，你生成对称密钥也给我一下
- X获得了A的公钥，把自己的公钥public_X发给B… B这傻子还以为真的是A的公钥呢
- B：好的，公钥public_X已收到，生成一个对称密钥secretKey，然后用public_X加密这个对称密钥。
- X截获了这个消息，用自己私钥private_X解密出对称密钥secretKey，自己再生成一个secretKeyXXX用public_A加密一下发送给A。A这傻子还以为你们接下来会安全的用secretKey通信吗哈哈哈
- A：收到消息，private_A解密出来对称密钥secretKeyXXX（其实是X篡改了）
X心想，这两个傻子真以为接下来用对称密钥加密就安全了呢，我倒要听听A和B在说什么悄悄话。
上图中，中间人X能不仅获取A和B之间通信内容，还能任意修改，相当于一个代理抓包，修改数据。
我们平时所用的抓包工具就需要安装一个证书，也就是你自己糊弄自己的电脑，自己充当中间人去查看网络通讯的数据，方便学习使用。
上面混合加密的例子已经涉及到数字签名，混合加密解决了对称密钥分配问题，后续讲解数字签名的中间人攻击也会提到这个例子，到时候可以返回来再看，中间人攻击其实就是数字签名存在的不足。
