對稱加密
兩邊用同一個密鑰來加解密。
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之間通信内容，還能任意修改，相當于一個代理抓包，修改資料。