加密、解密、公鑰，私鑰、Https協議

一、公鑰加密
假設一下，我找了兩個數字，一個是1，一個是2。我喜歡2這個數字，就保留起來，不告訴你們(私鑰），然后我告訴大家，1是我的公鑰。

我有一個文件，不能讓別人看，我就用1加密了。別人找到了這個文件，但是他不知道2就是解密的私鑰啊，所以他解不開，只有我可以用
數字2，就是我的私鑰，來解密。這樣我就可以保護數據了。

我的好朋友x用我的公鑰1加密了字符a，加密后成了b，放在網上。別人偷到了這個文件，但是別人解不開，因為別人不知道2就是我的私鑰，
只有我才能解密，解密后就得到a。這樣，我們就可以傳送加密的數據了。

 

二、私鑰簽名
如果我用私鑰加密一段數據（當然只有我可以用私鑰加密，因為只有我知道2是我的私鑰），結果所有的人都看到我的內容了，因為他們都知
道我的公鑰是1，那么這種加密有什么用處呢？

但是我的好朋友x說有人冒充我給他發信。怎么辦呢？我把我要發的信，內容是c，用我的私鑰2，加密，加密后的內容是d，發給x，再告訴他
解密看是不是c。他用我的公鑰1解密，發現果然是c。
這個時候，他會想到，能夠用我的公鑰解密的數據，必然是用我的私鑰加的密。只有我知道我得私鑰，因此他就可以確認確實是我發的東西。
這樣我們就能確認發送方身份了。這個過程叫做數字簽名。當然具體的過程要稍微復雜一些。用私鑰來加密數據，用途就是數字簽名。

 

總結：公鑰和私鑰是成對的，它們互相解密。

公鑰加密，私鑰解密。

私鑰數字簽名，公鑰驗證。

 

舉例

 

比如有兩個用戶Alice和Bob，Alice想把一段明文通過雙鑰加密的技術發送給Bob，Bob有一對公鑰和私鑰，那么加密解密的過程如下：

 

1. Bob將他的公開密鑰傳送給Alice。
2. Alice用Bob的公開密鑰加密她的消息，然后傳送給Bob。
3. Bob用他的私人密鑰解密Alice的消息。

 

　　上面的過程可以用下圖表示，Alice使用Bob的公鑰進行加密，Bob用自己的私鑰進行解密。

 

什么是HTTP協議？

HTTP協議全稱Hyper Text Transfer Protocol，翻譯過來就是超文本傳輸協議，位於TCP/IP四層模型當中的應用層。

HTTP協議通過請求/響應的方式，在客戶端和服務端之間進行通信

這一切看起來很美好，但是HTTP協議有一個致命的缺點：不夠安全。

HTTP協議的信息傳輸完全以明文方式，不做任何加密，相當於是在網絡上“裸奔”。這樣會導致什么問題呢？由於傳輸信息是明文，這個信息有可能被某個中間人惡意截獲甚至篡改。這種行為叫做中間人攻擊。

 

 

 小灰和小紅可以事先約定一種對稱加密方式，並且約定一個隨機生成的密鑰。后續的通信中，信息發送方都使用密鑰對信息加密，而信息接收方通過同樣的密鑰對信息解密。

雖然我們在后續的通信中對明文進行了加密，但是第一次約定加密方式和密鑰的通信仍然是明文，如果第一次通信就已經被攔截了，那么密鑰就會泄露給中間人，中間人仍然可以解密后續所有的通信內容。

 

 

這可怎么辦呢？別擔心，我們可以使用非對稱加密，為密鑰的傳輸做一層額外的保護。

 

非對稱加密的一組秘鑰對中，包含一個公鑰和一個私鑰。明文既可以用公鑰加密，用私鑰解密；也可以用私鑰加密，用公鑰解密。

 

在小灰和小紅建立通信的時候，小紅首先把自己的公鑰Key1發給小灰：收到小紅的公鑰以后，小灰自己生成一個用於對稱加密的密鑰Key2，並且用剛才接收的公鑰Key1對Key2進行加密（這里有點繞），發送給小紅：小紅利用自己非對稱加密的私鑰，解開了公鑰Key1的加密，獲得了Key2的內容。從此以后，兩人就可以利用Key2進行對稱加密的通信了。在通信過程中，即使中間人在一開始就截獲了公鑰Key1，由於不知道私鑰是什么，也無從解密。中間人雖然不知道小紅的私鑰是什么，但是在截獲了小紅的公鑰Key1之后，卻可以偷天換日，自己另外生成一對公鑰私鑰，把自己的公鑰Key3發送給小灰。

 

小灰不知道公鑰被偷偷換過，以為Key3就是小紅的公鑰。於是按照先前的流程，用Key3加密了自己生成的對稱加密密鑰Key2，發送給小紅。

 

這一次通信再次被中間人截獲，中間人先用自己的私鑰解開了Key3的加密，獲得Key2，然后再用當初小紅發來的Key1重新加密，再發給小紅。這樣一來，兩個人后續的通信盡管用Key2做了對稱加密，但是中間人已經掌握了Key2，所以可以輕松進行解密。

 

 

這時候，我們有必要引入第三方，一個權威的證書頒發機構（CA）來解決。

 

到底什么是證書呢？證書包含如下信息：

流程如下：

 

1.作為服務端的小紅，首先把自己的公鑰發給證書頒發機構，向證書頒發機構申請證書。

 

2.證書頒發機構自己也有一對公鑰私鑰。機構利用自己的私鑰來加密Key1，並且通過服務端網址等信息生成一個證書簽名，證書簽名同樣經過機構的私鑰加密。證書制作完成后，機構把證書發送給了服務端小紅。

3.當小灰向小紅請求通信的時候，小紅不再直接返回自己的公鑰，而是把自己申請的證書返回給小灰。

4.小灰收到證書以后，要做的第一件事情是驗證證書的真偽。需要說明的是，各大瀏覽器和操作系統已經維護了所有權威證書機構的名稱和公鑰。所以小灰只需要知道是哪個機構頒布的證書，就可以從本地找到對應的機構公鑰，解密出證書簽名。

接下來，小灰按照同樣的簽名規則，自己也生成一個證書簽名，如果兩個簽名一致，說明證書是有效的。

驗證成功后，小灰就可以放心地再次利用機構公鑰，解密出服務端小紅的公鑰Key1。

 

5.像之前一樣，小灰生成自己的對稱加密密鑰Key2，並且用服務端公鑰Key1加密Key2，發送給小紅。

 

6.最后，小紅用自己的私鑰解開加密，得到對稱加密密鑰Key2。於是兩人開始用Key2進行對稱加密的通信。

 

由於證書信息是由服務器網址等信息生成的並且經過機構私鑰加密，所以中間人無法篡改。

參考鏈接：https://blog.csdn.net/cut001/article/details/53189645 參考公眾號：程序員小灰