文章目錄

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

密鑰配送問題

上面幾篇文章我們講到了對稱加密，包括它的幾種實現(xiàn)AES，DES算法。那么有了對稱加密算法，我們是否就可以安全的和第三方進行通信了呢？ 考慮如下情況：

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

于是小明想，如果我將情書使用對稱加密算法進行加密，然后再把加密后的情書傳給小紅豈不就是安全了？ 但是小明又仔細思考了一下，發(fā)現(xiàn)了一個問題，對稱加密算法必須需要密鑰才能解密，除了傳遞情書以外，小明還需要把對稱加密算法的密鑰也傳過去，這樣小紅才能正常解密。

但是怎么才能安全的傳遞密鑰呢？ 密鑰必須要發(fā)送，但是又不能發(fā)送，這個就是密鑰配送的問題。

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

事先共享密鑰

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

如果他們分隔兩地那就麻煩了。因為郵寄或者遠程傳輸?shù)倪^程中，密鑰可能會被劫持。

即使能夠有效的共享密鑰，也會存在一個密鑰保存的問題，每兩個人間進行通信都需要一個完全不同的密鑰，如果通信的人數(shù)很多的話，則需要保存一個相當大數(shù)量的密鑰個數(shù)。實際操作起來不是很方便。

密鑰中心分配密鑰

為了解決保存大數(shù)量的密鑰的問題?？梢圆捎妹荑€中心來對密鑰進行集中管理。我們可以將密鑰中心看成是一個服務器，它里面保存了每一個人的密鑰信息，下面我們看一下具體的通信流程：

小明和小紅需要進行通信

密鑰中心隨機生成一個密鑰，這個密鑰將會是小明和小紅本次通信中使用的臨時密鑰

密鑰中心取出保存好的小明和小紅的密鑰

密鑰中心將臨時密鑰使用小明的密鑰加密后，發(fā)給小明

密鑰中心將臨時密鑰使用小紅的密鑰加密后，發(fā)給小紅

小明收到加密后的數(shù)據(jù)，使用自己的密鑰解密后，得到臨時密鑰

小紅收到加密后的數(shù)據(jù)，使用自己的密鑰解密后，得到臨時密鑰。

小明和小紅可以使用這個臨時密鑰自由通信啦 。

大家請注意，這里的臨時密鑰的使用方法很巧妙，后面我們會講到大家最常用的https通信協(xié)議中對這個臨時密鑰的巧妙使用。

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

其次所有的通信都要經(jīng)過密鑰中心，可能會造成性能瓶頸。

使用Diffie-Hellman密鑰交互

Diffie-Hellman 通過交互一些信息，雙方來生成相同的密鑰。具體的細節(jié)我們后在后面的博客中講到。

使用公鑰私鑰

密碼配送的原因就在于對稱加密使用的密鑰是相同的。 如果我們使用非對稱加密算法（公鑰只用來加密，私鑰只用來解密），這個問題是不是就能夠解決了？

回到小明和小紅通信的問題，如果小紅事先生成了公鑰私鑰，并把公鑰發(fā)給了小明，則小明可以將情書使用公鑰進行加密，然后發(fā)給小紅，這個情書只有小紅才能解密。即使公鑰被竊聽了也沒有關系。

當然這里也有一個問題，就是小明要確保生成的公鑰的確是小紅發(fā)出來的。這個問題的解決方法我們會在后面討論。

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

下面畫個序列圖，解釋一下公鑰密碼的交互流程：

小紅小明小紅生成一個包含公鑰和私鑰的密鑰對將公鑰發(fā)給小明將情書用公鑰加密將密文發(fā)送給小紅將密文用私鑰解密小紅小明

更多精彩內(nèi)容且看：

• 區(qū)塊鏈從入門到放棄系列教程-涵蓋密碼學,超級賬本,以太坊,Libra,比特幣等持續(xù)更新
• Spring Boot 2.X系列教程:七天從無到有掌握Spring Boot-持續(xù)更新
• Spring 5.X系列教程:滿足你對Spring5的一切想象-持續(xù)更新
• java程序員從小工到專家成神之路（2020版）-持續(xù)更新中,附詳細文章教程

更多教程請參考 flydean的博客

總結

以上是生活随笔為你收集整理的公钥私钥的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。