來源：liuchenyang0515.blog.csdn.net/article/details/109263510
對稱加密
兩邊用同一個密鑰來加解密。
A把明文通過某一算法加密之後得到密文，然後把密文發送給B，B接收到密文之後用相同的密鑰執行相同的算法去解密。X沒有密鑰，即使竊取到密文也無法竊聽。
對稱加密的有優缺點
- 對稱加密的優點：加解密速度快
- 對稱加密的缺點：會出現密鑰分配問題；密鑰容易複製，不便於安全保管
密鑰分配問題
對稱加密的存在密鑰分配問題，A的密鑰怎麼才能安全的傳輸到B手裏不被X獲取到？A直接發送密鑰給B還是可能被X竊取到這個密鑰，這樣加密信息等於是在裸奔了。
只有用密鑰加密後的信息才能安全傳輸，但是隻有保證安全傳輸的前提下才能發送這個密鑰。
這個道理和下圖一樣
非對稱加密
雙方使用不同的密鑰來加解密，並且不能通過一個密鑰推算出另一個密鑰。
- 公鑰加密，私鑰解密
- 私鑰加密（數字簽名），公鑰解密
A把事先準備好了非對稱密鑰對，分別爲公鑰和私鑰，這一套非對稱密鑰對能相互加解密。公鑰是公開的，私鑰只有自己纔有。然後A把公鑰發送給B，或者公鑰放在服務器B自行下載。
B拿到了公鑰後用公鑰的一套算法加密信息後傳輸給A，A用私鑰執行另一個算法解密獲得明文信息。
推薦一個開源免費的 Spring Boot 最全教程：
非對稱加密的優缺點
- 非對稱加密的優點：不會出現密鑰分配問題
- 非對稱加密的缺點：加解密速度慢，仍有被竊聽的隱患，原因和中間人攻擊一樣，後面會講到。
既然對稱加密和非對稱加密都有缺點，那麼我們能不能用一種方法結合一下他們的優點形成一套比較好的方案呢？答案是有的，那就是混合加密
混合加密
傳輸大量數據的時候使用對稱加密，因爲加解密速度快。但是由於對稱加密有祕鑰分配問題，所以我們用非對稱加密來加密這個對稱密鑰再傳遞給對方。
我們會認爲接下來的方案應該是比較完美了吧？
雙向通信之前要先把公鑰相互交換，比如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之間通信內容，還能任意修改，相當於一個代理抓包，修改數據。
我們平時所用的抓包工具就需要安裝一個證書，也就是你自己糊弄自己的電腦，自己充當中間人去查看網絡通訊的數據，方便學習使用。
上面混合加密的例子已經涉及到數字簽名，混合加密解決了對稱密鑰分配問題，後續講解數字簽名的中間人攻擊也會提到這個例子，到時候可以返回來再看，中間人攻擊其實就是數字簽名存在的不足。
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這纔是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！