小明想寫一封情書給小紅，但是這封情書是很私密的東西， 小明不想讓除了小紅之外的其他人知道。小明看過flydean的部落格，他知道了有個對稱加密的好東西。
於是小明想，如果我將情書使用對稱加密演算法進行加密，然後再把加密後的情書傳給小紅豈不就是安全了？ 但是小明又仔細思考了一下，發現了乙個問題，對稱加密演算法必須需要金鑰才能解密，除了傳遞情書以外，小明還需要把對稱加密演算法的金鑰也傳過去，這樣小紅才能正常解密。
但是怎麼才能安全的傳遞金鑰呢？ 金鑰必須要傳送，但是又不能傳送，這個就是金鑰配送的問題。
下面我們將一下解決金鑰配送問題的幾個方法。
解決金鑰配送問題的最簡單方法就是事先共享金鑰，也就是小明提前將金鑰交給小紅。如果他們兩個離得很近，那沒有問題，直接線下見面交給小紅就可以了。
如果他們分隔兩地那就麻煩了。因為郵寄或者遠端傳輸的過程中，金鑰可能會被劫持。
即使能夠有效的共享金鑰，也會存在乙個金鑰儲存的問題，每兩個人間進行通訊都需要乙個完全不同的金鑰，如果通訊的人數很多的話，則需要儲存乙個相當大數量的金鑰個數。實際操作起來不是很方便。
為了解決儲存大數量的金鑰的問題。可以採用金鑰中心來對金鑰進行集中管理。我們可以將金鑰中心看成是乙個伺服器，它裡面儲存了每乙個人的金鑰資訊，下面我們看一下具體的通訊流程：
小明和小紅需要進行通訊
金鑰中心隨機生成乙個金鑰，這個金鑰將會是小明和小紅本次通訊中使用的臨時金鑰
金鑰中心取出儲存好的小明和小紅的金鑰
金鑰中心將臨時金鑰使用小明的金鑰加密後，發給小明
金鑰中心將臨時金鑰使用小紅的金鑰加密後，發給小紅
小明收到加密後的資料，使用自己的金鑰解密後，得到臨時金鑰
小紅收到加密後的資料，使用自己的金鑰解密後，得到臨時金鑰。
小明和小紅可以使用這個臨時金鑰自由通訊啦 。
大家請注意，這裡的臨時金鑰的使用方法很巧妙，後面我們會講到大家最常用的https通訊協議中對這個臨時金鑰的巧妙使用。
金鑰中心很好，但是也有缺點，首先金鑰中心的金鑰是集中管理的，一旦被攻破，所有人的金鑰都會暴露。
其次所有的通訊都要經過金鑰中心，可能會造成效能瓶頸。
diffie-hellman 通過互動一些資訊，雙方來生成相同的金鑰。具體的細節我們後在後面的部落格中講到。
密碼配送的原因就在於對稱加密使用的金鑰是相同的。 如果我們使用非對稱加密演算法（公鑰只用來加密，私鑰只用來解密），這個問題是不是就能夠解決了？
回到小明和小紅通訊的問題，如果小紅事先生成了公鑰私鑰，並把公鑰發給了小明，則小明可以將情書使用公鑰進行加密，然後發給小紅，這個情書只有小紅才能解密。即使公鑰被竊聽了也沒有關係。
當然這裡也有乙個問題，就是小明要確保生成的公鑰的確是小紅發出來的。這個問題的解決方法我們會在後面討論。
公鑰金鑰還有乙個問題就是速度的問題，只有對稱加密演算法的幾百分之一。
下面畫個序列圖，解釋一下公鑰密碼的互動流程：
github 公鑰 私鑰 理解公鑰與私鑰
一 公鑰演算法與私鑰演算法 1 私鑰演算法 私鑰加密演算法，又稱 對稱加密演算法，因為這種演算法解密金鑰和加密金鑰是相同的。也正因為同一金鑰既用於加密又用於解密，所以這個金鑰是不能公開的。常見的有 des加密演算法 aes加密演算法 2 公鑰演算法 公鑰加密演算法，也就是 非對稱加密演算法，這種演算...
公鑰和私鑰
1，公鑰和私鑰成對出現 2，公開的金鑰叫公鑰，只有自己知道的叫私鑰 3，用公鑰加密的資料只有對應的私鑰可以解密 4，用私鑰加密的資料只有對應的公鑰可以解密 5，如果可以用公鑰解密，則必然是對應的私鑰加的密 6，如果可以用私鑰解密，則必然是對應的公鑰加的密 假設一下，我找了兩個數字，乙個是1，乙個是2...
公鑰，私鑰，證書
bob,alice和數字證書 一，公鑰私鑰 1，公鑰和私鑰成對出現 2，公開的金鑰叫公鑰，只有自己知道的叫私鑰 3，用公鑰加密的資料只有對應的私鑰可以解密 4，用私鑰加密的資料只有對應的公鑰可以解密 5，如果可以用公鑰解密，則必然是對應的私鑰加的密 6，如果可以用私鑰解密，則必然是對應的公鑰加的密 ...