對稱加密與非對稱加密

在計算機領域網絡的安全性已經變得越來越重要了，在日常工作中也經常會聽到公鑰、私鑰、加密、簽名等相關名詞。下面做一個簡單的梳理。

一、加密算法的種類

大緻來講加密算法分為 雜湊演算法、對稱加密、非對稱加密 三大類。

1、雜湊演算法：

通常用于驗證消息的完整性，散列(hash)函數提供了這一功能。他對不同長度的輸入消息産生固定長度的輸出，常見的算法有MD5、SHA、HMAC等。

2、對稱加密：

雙方采用同樣的秘鑰進行加密和解密(可以就這麼認為)。實際上這裡更準确的表達應該是加密秘鑰能夠從解密秘鑰中推算出來，反之也能推到出來；隻不過在大多數對稱加密使用中，加密秘鑰與解密秘鑰是相同的，是以直接這樣認為也是沒有問題的。由此可見秘鑰對對稱加密的安全性至關重要，一旦洩露意味着任何人都可以對發送or接受的消息解密。

優點：這種加密方式加密速度非常快(算法公開、計算量小、速度快、效率高)，适合經常發送資料的場合。

缺點：1)雙方使用同樣的秘鑰，安全性得不到保證。2）每對使用者每次使用加密算法時都需要使用其他人不知道的唯一秘鑰，這會使得收發雙方所有用的秘鑰數量呈幾何級數增長，秘鑰管理稱為使用者負擔。3）它要求發送方和接受方在安全通信之前商定出一個秘鑰；而秘鑰的傳輸是比較麻煩的。

常用的對稱加密算法有AES、DES、3DES、TDEA，Blowfish、RC5、IDEA等算法。

3、非對稱加密    亦可參考

(1)與對稱加密不同，對于單方向的通信非對稱加密算法也需要兩個秘鑰，公開秘鑰和私有秘鑰。共有秘鑰和私有秘鑰是一對。如果用公開密鑰對資料進行加密，隻有用對應的私有密鑰才能解密；同樣如果用私鑰加密，公鑰也是可以解密的(注:私鑰一般用于簽名而不直接用于消息加密,後面會提到)。因為加密和解密使用的是兩個不同的密鑰，是以這種算法叫作非對稱加密算法。有了非對稱加密的公私鑰對，這樣通信中僅需傳遞公鑰，甚至公鑰可以開放給所有人。需要發消息給我的人使用我的公鑰加密後發給我，隻有我可以使用私鑰解密，其他人不可能獲知資訊的内容。這隻是單方向的加密，雙向加密怎麼辦呢？對方也建立一個公私鑰對就可以了。ps：雖然可能出現有人惡意亂發消息過來的情況，但是這并不會有什麼嚴重的負面影響，因為有用的資訊并沒有洩漏；此外我隻關心我關注的人的消息即可。

非對稱加密主要用于兩個場景，1)資料傳輸 和 2)簽名。

(2)非對稱加密下的通信過程——防止資料被破解  

公鑰隻是用來加密用的，并不用于解密。前面說了公鑰和私鑰是成對存在的。 舉個例子：現有A、B兩人要進行通信，如果要實作雙向通信，實際上要有兩個<公鑰,私鑰>對。即<A的私鑰,A的公鑰>與<B的私鑰,B的公鑰>。過程如下：

• A 根據非對稱加密算法生成自己的公私鑰對（PUBLIC_A，PRIVATE_A）；

• B 也根據非對稱加密算法生成自己的公私鑰對（PUBLIC_B，PRIVATE_B）；

• A 和 B 可以公開的交換自己的公鑰（私鑰不需要發送，各自儲存好即可）；

• A 使用 B 的公鑰 PUBLIC_B 加密資訊，發送給 B；

• B 接收到消息後，使用自己儲存的私鑰 PRIVATE_B 解密就可以看到消息内容（這條消息即使被他人獲得後也是不能解密的）；

• 同樣，B 要發消息給 A 時，使用 A 的公鑰 PUBLIC_A 加密發出；

• A 收到消息後使用自己的私鑰 PRIVATE_A 解密，這樣就實作了雙方加密的通信。

顯然，對于上述過程即使接受方的公鑰洩漏也不會導緻資訊洩漏，因為密文隻有通通過接受方的私鑰才能打開。是以資訊安全過程中，接受方隻需要保證自己的私鑰不洩露即可。

(3)數字簽名——驗證發送者身份與驗證資料未被篡改

有了公私鑰對後加密加密通信的問題似乎得到了解決。但是又有另外一個新的問題。那就是"A收到消息後如何确認發送者就是B而不是第三方呢？"。其實也很簡單；隻要發消息前多進行一次使用自己的私鑰加密過程就可以了，這次使用自己私鑰加密資訊的步驟就叫做簽名。具體玩法如下。私鑰隻有自己持有且公私鑰之間存在對應關系，即使用B的公鑰隻能解密出B的私鑰加密的東西；是以這個過程就可以當做驗證B身份的手段了。(注:這裡都假設私鑰又被妥善儲存)

從主動使用的角度:公鑰一般用來加密，私鑰用來簽名。

還使用上邊的例子來看一下使用了加密和簽名之後的通信過程：

• A 先使用自己的私鑰 PRIVATE_A 對消息進行一遍加密（習慣性稱作簽名），再使用 B 的公鑰 PUBLIC_B 加密資訊，然後将加密結果發送給 B。
• B 接收到消息後，使用自己儲存的私鑰 PRIVATE_B 解密，然後使用 A 的公鑰 PUBLIC_A 再解密一遍，如果能解密成功，就可以確定這條消息不是僞造的。
• 同樣，B 要發消息給 A 時先使用自己的私鑰 PRIVATE_B 對消息進行一遍加密（習慣性稱作簽名），再使用 A 的公鑰 PUBLIC_A 加密後發出。
• A 收到消息後使用自己的私鑰 PRIVATE_A 解密，然後使用 B 的公鑰 PUBLIC_B 再解密一遍，這樣就實作了雙方互相确認身份的加密通信。

由于非對稱加密是複雜且耗時的，而且需要加密的内容越長就越耗時。在實際使用中一般經過摘要算法得到一串哈希值，然後使用私鑰對哈希值進行加密習慣性将這樣對摘要使用私鑰加密生成的檔案叫做簽名檔案。于是就演化出了目前使用的簽名、加密過程，如下：

• A 先使用雜湊演算法将要發送的消息計算出摘要(例如md5值)，再用自己的私鑰 PRIVATE_A 對摘要進行簽名得到簽名檔案，然後将原始消息和簽名檔案打包到一起，使用 B 的公鑰 PUBLIC_B 加密資訊，發送給 B。

• B 接收到消息後，使用自己儲存的私鑰 PRIVATE_B 解密，得到原始消息和一個簽名檔案。使用雜湊演算法對原始消息計算得到一個哈希值，再使用 A 的公鑰 PUBLIC_A 對簽名檔案進行解密，得到消息的哈希值，将這兩個哈希值進行對比，如果一緻就可以認為這條消息是 A 發送的且未經過篡改。

通常加密解密的速度比較慢，适合偶爾發送資料的場合。優點是密鑰傳輸友善。常見的非對稱加密算法為RSA、ECC和EIGamal。

(4)公鑰與證書——公鑰有可能是假的

從上邊的流程來看，似乎一切都完美了，但黑客也是絞盡腦汁的，他們還是從中找到了破綻。那就是我們對 A 的身份識别是建立在相信 PUBLIC_A 的公鑰确實是 A 的，然而黑客可以輕易的釋出自己的公鑰宣稱這是 A 的公鑰來欺騙我們，那我們又怎麼樣區分呢？這就需要一個機構來保證了，這個機構把 A 提供的公鑰和 A 的相關資訊放在一起組合成一份證書，這樣你從這個機構獲驗證書，就可以得到有權威機構背書的公鑰與 A 的對應關系。

這個機構叫做 CA，釋出的證書叫做 CA 證書。

(5)證書授權中心CA——來確定公鑰是ok的

CA 證書授權（CertificateAuthority）中心是數字證書發行的唯一機構。

CA 中心又稱 CA 機構，即證書授權中心（Certificate Authority），或稱證書授權機構，作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA 中心為每個使用公開密鑰的使用者發放一個數字證書，數字證書的作用是證明證書中列出的使用者合法擁有證書中列出的公開密鑰。CA 機構的數字簽名使得攻擊者不能僞造和篡改證書。在 SET 交易中，CA 不僅對持卡人、商戶發放證書，還要對獲款的銀行、網關發放證書。它負責産生、配置設定并管理所有參與網上交易的個體所需的數字證書，是以是安全電子交易的核心環節。

CA 證書是逐級保證安全的，最終的根證書内置在作業系統中。由作業系統來保證，這部分下文中會進行介紹。

(6)對稱加密與非對稱加密的聯合使用

由于非對稱加密是耗時的，如果在每一次 HTTPS 的資料傳輸中都使用非對稱加密是不合适的。實際上的做法是在第一次建立 HTTPS 連接配接時使用一次非對稱加密傳遞對稱加密的密鑰，然後就使用對稱加密來保證接下來的通信過程。

HTTPS 的通信過程如下：

• 浏覽器發出 HTTPS 請求。

• 伺服器傳回本網站的證書。

• 浏覽器基于内置在作業系統中的CA憑證鍊對網站證書的有效性進行校驗。校驗通過後使用證書中的公鑰加密一份對稱加密的密鑰資訊，發送給服務端。

• 服務端收到資訊後使用自己的私鑰解密資訊，得到浏覽器提供的用于對稱加密的密鑰資訊。之後的通信過程就使用這個對稱加密的密鑰來保護。

參考：https://www.cnblogs.com/traditional/p/12693249.html  強烈推薦。。。。