一，對稱加密

所謂對稱加密，就是它們在編碼時使用的金鑰e和解碼時一樣d(e=d)，我們就將其統稱為金鑰k。

對稱加解密的過程如下：

傳送端和接收端首先要共享相同的金鑰k(即通訊前雙方都需要知道對應的金鑰)才能進行通訊。傳送端用共享金鑰k對明文p進行加密，得到密文c，並將得到的密文傳送給接收端，接收端收到密文後，並用其相同的共享金鑰k對密文進行解密，得出明文p。

一般加密和解密的演算法是公開的，需要保持隱祕的是金鑰k，流行的對稱加密演算法有：DES，Triple-DES，RC2和RC4

對稱加密的不足主要有兩點：

1，  傳送方和接收方首先需要共享相同的金鑰，即存在金鑰k的分發問題，如何安全的把共享金鑰在雙方進行分享，這本身也是一個如何安全通訊的問題，一種方法是提前雙方約定好，不通過具體的通訊進行協商，避免被監聽和截獲。另外一種方式，將是下面我們介紹的通過非對稱加密通道進行對稱密碼的分發和共享，即混合加密系統。

2，  金鑰管理的複雜度問題。由於對稱加密的金鑰是一對一的使用方式，若一方要跟n方通訊，則需要維護n對金鑰。

對稱加密的好處是：

加密和解密的速度要比非對稱加密快很多，因此常用非對稱加密建立的安全通道進行共享金鑰的分享，完成後，具體的加解密則使用對稱加密。即混合加密系統。

另外一個點需要重點說明的是，金鑰k的長度對解密破解的難度有很重大的影響，k的長度越長，對應的密碼空間就越大，遭到暴力破解或者詞典破解的難度就更大，就更加安全。

二，非對稱加密

所謂非對稱加密技術是指加密的金鑰e和解密的金鑰d是不同的（e!=d），並且加密的金鑰e是公開的，叫做公鑰，而解密的金鑰d是保密的，叫私鑰。

非對稱加解密的過程如下：

加密一方找到接收方的公鑰e (如何找到呢？大部分的公鑰查詢工作實際上都是通過數字證書來實現的)，然後用公鑰e對明文p進行加密後得到密文c，並將得到的密文傳送給接收方，接收方收到密文後，用自己保留的私鑰d進行解密，得到明文p，需要注意的是：用公鑰加密的密文，只有擁有私鑰的一方才能解密，這樣就可以解決加密的各方可以統一使用一個公鑰即可。

常用的非對稱加密演算法有：RSA

非對稱加密的優點是：

1，  不存在金鑰分發的問題，解碼方可以自己生成金鑰對，一個做私鑰存起來，另外一個作為公鑰進行釋出。

2，  解決了金鑰管理的複雜度問題，多個加密方都可以使用一個已知的公鑰進行加密，但只有擁有私鑰的一方才能解密。

  非對稱加密不足的地方是加解密的速度沒有對稱加密快。

綜上，分析了對稱加密和非對稱加密各自的優缺點後，有沒有一種辦法是可以利用兩者的優點但避開對應的缺點呢？答應是有的，實際上用得最多的是混合加密系統，比如在兩個節點間通過便捷的公開密碼加密技術建立起安全通訊，然後再用安全的通訊產生併發送臨時的隨機對稱金鑰，通過更快的對稱加密技術對剩餘的資料進行加密。

三，數字簽名

上面討論了非對稱加密技術在編碼中的使用，解決的是傳送資料的私密性，一般是用公鑰作為加密key，而私鑰作為解密key，那假如是用私鑰作為加密key，而公鑰作為解密key呢？

由於私鑰只有對應一方才知道，因此若通過對應的公鑰可以驗證對方是用對應的私鑰進行加密的，則可以說明對方的身份，這就是數字簽名。

數字簽名需要解決的兩個任務是：

1，  誰編寫的報文；

2，  報文的內容是否被篡改過；

數字簽名的過程一般如下：

1，  傳送方A首先對變長的報文提取成一個定長的摘要，一般是md5等

2，  A對摘要應用了一個簽名函式，並且用A自己的私鑰作為引數，因為只有A才知道私鑰，所以正確的簽名會說明簽名者就是其所有者。

3，  一旦計算出簽名，節點A就將其附加到報文的末尾，並將報文和簽名一起都發送給B

4，  在接收端B，首先會按照同樣的演算法計算出報文的摘要，然後對簽名用A的公鑰進行解碼，得出解碼後的摘要，兩個摘要進行比較，則可以判斷是否是A傳送的且內容沒被篡改過。

四，數字證書

實際上，好多的公鑰都是通過數字證書進行釋出的，數字證書類似一個人的身份證一樣，由對應的官方的頒發結構頒發的，類似一個人的身份證有姓名，身份證ID，有效期，頒發機構-一般是某某派出所等，數字證書也有類似的形式。

基本的數字證書包括了一些常見的資訊：

1， 物件的名稱（人，伺服器，組織等）

2， 過期時間

3， 物件的公鑰

4， 證書釋出者（由誰為證書擔保）

5， 來自證書釋出者的數字簽名。

…

需要注意的是，任何人都可以建立一個證書，但不是所有人都能夠獲得受人尊敬的簽發權從而為證書資訊提供擔保，並用其私人金鑰簽發證書。

不幸的是，數字證書沒有單一的全球標準，但現在使用的大多數證書是以一種標準格式– X.509 v3，來儲存它們的資訊。

x.509證書格式：

x.509證書有很多種，如伺服器端證書，個人證書等。

瀏覽器中的證書：

注意：每個證書均有對應於證書公鑰的私鑰，私鑰不能被匯出，訪問一般需要密碼等。

瀏覽器會預設儲存一些受信任的根證書頒發機構的證書，從圖中可以看，這些證書都是頒發者頒發給自己的。

五、用伺服器證書對服務進行認證

在支付網站中，使用者需要確認他們輸入支付密碼的站點是真正的經過認證的站點，而不是被釣魚的網站，因此使用者有必要認證對應的伺服器，而這種方式是通過伺服器證書來進行的。過程大概如下：

1， 通過https建立一個安全web事務之後，瀏覽器會自動獲取所連伺服器的數字證書；

其中伺服器證書包括了：

        Web站點名稱和主機名

        Web站點的公鑰；

        頒發機構的名稱；

        頒發機構給證書的簽名；

2，  若伺服器沒有證書，則安全連線失敗。

3，  瀏覽器首先檢查伺服器證書是否還在有效期內，若過期，則提示失效；

4，  瀏覽器檢視伺服器證書對應的CA，若該CA是很權威的機構，則瀏覽器可能已經知道了對應的公鑰了（瀏覽器會預先安裝很多簽名頒發機構的證書並認為是受信任的），這時，瀏覽器用CA的數字證書裡面的公鑰來驗證該CA頒發的伺服器證書的有效性。類似去公安局驗證某人的身份證是否是真的。

5，則瀏覽器對簽名頒發機構CA一無所知，瀏覽器無法確定是否該信任這個簽名頒發機構，它通常會向用戶提示一個對話方塊，看看他是否相信這個簽名釋出者。

5，  一旦完成了對伺服器證書的驗證，接下來就可以使用伺服器證書裡面的公鑰進行伺服器身份的驗證；

6，  客戶端生成一個隨機數給到伺服器，要求對應的服務用對應伺服器證書是私鑰進行簽名。

7，  伺服器對隨機數進行簽名，並回傳給到客戶端。

8，  客戶端用伺服器證書的公鑰對隨機數的簽名進行驗證，若驗證通過，則說明對應的伺服器確實擁有對應伺服器證書的私鑰，因此判斷伺服器的身份正常。否則，則任務伺服器身份被偽造。

六，用客戶端證書對客戶端進行認證

客戶端證書和伺服器證書類似，只是伺服器證書增加一些對伺服器站點名稱和主機名等內容的簽註，客戶端證書一般是某個機構針對個人頒發的，用於標識個人的身份。如財付通提示使用者安裝對應的數字證書，就是一個客戶端證書，在安裝客戶端證書的時候，實際上會把使用者對應該證書的私鑰要儲存起來。客戶端用私鑰進行簽名，然後第三方用客戶端證書的公鑰進行驗籤實現對客戶端身份的認證。

七，HTTPS的雙向認證，則需要客戶端和伺服器交換證書。

在傳送已加密的HTTP報文前，客戶端和伺服器要進行一次SSL握手，在這個握手的過程中，它們要完成以下工作：

1，  交換協議版本號；

2，  選擇一個兩端都瞭解的密碼；

3，  對兩端的身份進行驗證；

4，  生成臨時的會話金鑰，後續便用該金鑰進行加密通道。