公鑰私鑰

文章目錄

• • 密鑰配送問題
  • 事先共享密鑰
  • 密鑰中心分配密鑰
  • 使用Diffie-Hellman密鑰交互
  • 使用公鑰私鑰

密鑰配送問題

上面幾篇文章咱們講到了對稱加密，包括它的幾種實現AES，DES算法。那麼有了對稱加密算法，咱們是否就能夠安全的和第三方進行通訊了呢？ 考慮以下狀況：

小明想寫一封情書給小紅，可是這封情書是很私密的東西， 小明不想讓除了小紅以外的其餘人知道。小明看過flydean的博客，他知道了有個對稱加密的好東西。

因而小明想，若是我將情書使用對稱加密算法進行加密，而後再把加密後的情書傳給小紅豈不就是安全了？ 可是小明又仔細思考了一下，發現了一個問題，對稱加密算法必須須要密鑰才能解密，除了傳遞情書之外，小明還須要把對稱加密算法的密鑰也傳過去，這樣小紅才能正常解密。

可是怎麼才能安全的傳遞密鑰呢？ 密鑰必需要發送，可是又不能發送，這個就是密鑰配送的問題。

下面咱們將一下解決密鑰配送問題的幾個方法。

事先共享密鑰

解決密鑰配送問題的最簡單方法就是事先共享密鑰，也就是小明提早將密鑰交給小紅。若是他們兩個離得很近，那沒有問題，直接線下見面交給小紅就能夠了。

若是他們分隔兩地那就麻煩了。由於郵寄或者遠程傳輸的過程當中，密鑰可能會被劫持。

即便可以有效的共享密鑰，也會存在一個密鑰保存的問題，每兩我的間進行通訊都須要一個徹底不一樣的密鑰，若是通訊的人數不少的話，則須要保存一個至關大數量的密鑰個數。實際操做起來不是很方便。

密鑰中心分配密鑰

爲了解決保存大數量的密鑰的問題。能夠採用密鑰中心來對密鑰進行集中管理。咱們能夠將密鑰中心當作是一個服務器，它裏面保存了每個人的密鑰信息，下面咱們看一下具體的通訊流程：

1. 小明和小紅須要進行通訊
2. 密鑰中心隨機生成一個密鑰，這個密鑰將會是小明和小紅本次通訊中使用的臨時密鑰
3. 密鑰中心取出保存好的小明和小紅的密鑰
4. 密鑰中心將臨時密鑰使用小明的密鑰加密後，發給小明
5. 密鑰中心將臨時密鑰使用小紅的密鑰加密後，發給小紅
6. 小明收到加密後的數據，使用本身的密鑰解密後，獲得臨時密鑰
7. 小紅收到加密後的數據，使用本身的密鑰解密後，獲得臨時密鑰。
8. 小明和小紅可使用這個臨時密鑰自由通訊啦 。

你們請注意，這裏的臨時密鑰的使用方法很巧妙，後面咱們會講到你們最經常使用的https通訊協議中對這個臨時密鑰的巧妙使用。

密鑰中心很好，可是也有缺點，首先密鑰中心的密鑰是集中管理的，一旦被攻破，全部人的密鑰都會暴露。

其次全部的通訊都要通過密鑰中心，可能會形成性能瓶頸。

使用Diffie-Hellman密鑰交互

Diffie-Hellman 經過交互一些信息，雙方來生成相同的密鑰。具體的細節咱們後在後面的博客中講到。

使用公鑰私鑰

密碼配送的緣由就在於對稱加密使用的密鑰是相同的。 若是咱們使用非對稱加密算法（公鑰只用來加密，私鑰只用來解密），這個問題是否是就可以解決了？

回到小明和小紅通訊的問題，若是小紅事先生成了公鑰私鑰，並把公鑰發給了小明，則小明能夠將情書使用公鑰進行加密，而後發給小紅，這個情書只有小紅才能解密。即便公鑰被竊聽了也沒有關係。

固然這裏也有一個問題，就是小明要確保生成的公鑰的確是小紅髮出來的。這個問題的解決方法咱們會在後面討論。

公鑰密鑰還有一個問題就是速度的問題，只有對稱加密算法的幾百分之一。