HTTPS的中那些加密算法

密碼學在計算機科學中使用很是普遍，HTTPS就是創建在密碼學基礎之上的一種安全的通訊協議。HTTPS早在1994年由網景公司首次提出，而現在在衆多互聯網廠商的推廣之下HTTPS已經被普遍使用在各類大小網站中。在徹底理解HTTPS以前，有必要弄清楚一些密碼學相關的概念，好比：明文、密文、密碼、密鑰、對稱加密、非對稱加密、摘要、數字簽名、數字證書。

密碼(cipher)

密碼學中的密碼（cipher）和咱們平常生活中所說的密碼不太同樣，計算機術語『密碼 cipher』是一種用於加密或者解密的算法，而咱們平常所使用的『密碼 password』是一種口令，它是用於認證用途的一組文本字符串，這裏咱們要討論的是前者：cipher。

密鑰(key)

密鑰是一種參數，它是在使用密碼（cipher）算法過程當中輸入的參數。同一個明文在相同的密碼算法和不一樣的密鑰計算下會產生不一樣的密文。不少知名的密碼算法都是公開的，密鑰纔是決定密文是否安全的重要參數，一般密鑰越長，破解的難度越大，好比一個8位的密鑰最多有256種狀況，使用窮舉法，能很是輕易的破解，知名的DES算法使用56位的密鑰，目前已經不是一種安全的加密算法了，主要仍是由於56位的密鑰過短，在數小時內就能夠被破解。密鑰分爲對稱密鑰與非對稱密鑰。

明文/密文

明文（plaintext）是加密以前的原始數據，密文是經過密碼（cipher）運算後獲得的結果成爲密文（ciphertext）

對稱密鑰

對稱密鑰（Symmetric-key algorithm）又稱爲共享密鑰加密，對稱密鑰在加密和解密的過程當中使用的密鑰是相同的，常見的對稱加密算法有DES、3DES、AES、RC五、RC6。對稱密鑰的優勢是計算速度快，可是他也有缺點，密鑰須要在通信的兩端共享，讓彼此知道密鑰是什麼對方纔能正確解密，若是全部客戶端都共享同一個密鑰，那麼這個密鑰就像萬能鑰匙同樣，能夠憑藉一個密鑰破解全部人的密文了，若是每一個客戶端與服務端單獨維護一個密鑰，那麼服務端須要管理的密鑰將是成千上萬，這會給服務端帶來噩夢。下面就是一個簡單的對稱加密，將明文加密成ASCII。

# 加密的方式：在ASCII的基礎上 + 密鑰的值

def encipher(plain_text, key): # 加密 cipher_text = [] for c in plain_text: cipher_text.append(str(ord(c) + key)) return ' '.join(cipher_text) def decipher(cipher_text, key): # 解密 plain_text = [] for c in cipher_text.split(" "): plain_text.append(chr(int(c)+key)) return "".join(plain_text) if __name__ == '__main__': print "cipher_text:", encipher("abcdef", 0) print "plain_text:", decipher("97 98 99 100 101 102", 0) 

非對稱密鑰

非對稱密鑰（public-key cryptography），又稱爲公開密鑰加密，服務端會生成一對密鑰，一個私鑰保存在服務端，僅本身知道，另外一個是公鑰，公鑰能夠自由發佈供任何人使用。客戶端的明文經過公鑰加密後的密文須要用私鑰解密。非對稱密鑰在加密和解密的過程的使用的密鑰是不一樣的密鑰，加密和解密是不對稱的，因此稱之爲非對稱加密。與對稱密鑰加密相比，非對稱加密無需在客戶端和服務端之間共享密鑰，只要私鑰不發給任何用戶，即便公鑰在網上被截獲，也沒法被解密，僅有被竊取的公鑰是沒有任何用處的。常見的非對稱加密有RSA，非對稱加解密的過程：

1. 服務端生成配對的公鑰和私鑰
2. 私鑰保存在服務端，公鑰發送給客戶端
3. 客戶端使用公鑰加密明文傳輸給服務端
4. 服務端使用私鑰解密密文獲得明文

數字簽名（Digital Signature）

數據在瀏覽器和服務器之間傳輸時，有可能在傳輸過程當中被冒充的盜賊把內容替換了，那麼如何保證數據是真實服務器發送的而不被調包呢，同時如何保證傳輸的數據沒有被人篡改呢，要解決這兩個問題就必須用到數字簽名，數字簽名就如同平常生活的中的簽名同樣，一旦在合同書上落下了你的大名，從法律意義上就肯定是你本人籤的字兒，這是任何人都無法仿造的，由於這是你專有的手跡，任何人是造不出來的。那麼在計算機中的數字簽名怎麼回事呢？數字簽名就是用於驗證傳輸的內容是否是真實服務器發送的數據，發送的數據有沒有被篡改過，它就幹這兩件事，是非對稱加密的一種應用場景。不過他是反過來用私鑰來加密，經過與之配對的公鑰來解密。

第一步：服務端把報文通過Hash處理後生成摘要信息Digest，摘要信息使用私鑰private-key加密以後就生成簽名，服務器把簽名連同報文一塊兒發送給客戶端。 

第二步：客戶端接收到數據後，把簽名提取出來用public-key（服務端生成配對的私鑰和公鑰，把公鑰先傳給了客戶端）解密，若是能正常的解密出來Digest2，那麼就能確認是對方發的。 (數據的真實性）消息認證、是指確認消息來自正確的發送者
第三步：客戶端把報文Text提取出來作一樣的Hash處理，獲得的摘要信息Digest1，再與以前解密出來的Digist2對比，若是二者相等，就表示內容沒有被篡改，不然內容就是被人改過了。由於只要文本內容哪怕有任何一點點改動都會Hash出一個徹底不同的摘要信息出來。（數據的完整性）

數字證書（Certificate Authority）

數字證書簡稱CA，它由權威機構給某網站頒發的一種承認憑證，這個憑證是被你們（瀏覽器）所承認的，爲何須要用數字證書呢，難道有了數字簽名還不夠安全嗎？有這樣一種狀況，就是瀏覽器沒法肯定全部的真實服務器是否是真的是真實的，舉一個簡單的例子：A廠家給大家家安裝鎖，同時把鑰匙也交給你，只要鑰匙能打開鎖，你就能夠肯定鑰匙和鎖是配對的，若是有人把鑰匙換了或者把鎖換了，你是打不開門的，你就知道確定被竊取了，可是若是有人把鎖和鑰匙替換成另外一套表面看起來差很少的，但質量差不少的，雖然鑰匙和鎖配套，可是你卻不能肯定這是否真的是A廠家給你的，那麼這時候，你能夠找質檢部門來檢驗一下，這套鎖是否是真的來自於A廠家，質檢部門是權威機構，他說的話是能夠被公衆承認的（呵呵）。

一樣的， 由於若是有人（張三）用本身的公鑰把真實服務器發送給瀏覽器的公鑰替換了，因而張三用本身的私鑰執行相同的步驟對文本Hash、數字簽名，最後獲得的結果都沒什麼問題，但事實上瀏覽器看到的東西卻不是真實服務器給的，而是被張三從裏到外（公鑰到私鑰）換了一通。那麼如何保證你如今使用的公鑰就是真實服務器發給你的呢？咱們就用數字證書來解決這個問題。數字證書通常由數字證書認證機構（Certificate Authority）頒發，證書裏面包含了真實服務器的公鑰和網站的一些其餘信息，數字證書機構用本身的私鑰加密後發給瀏覽器，瀏覽器使用數字證書機構的公鑰（客戶端先下載CA獲得數字證書認證機構的公鑰？？？）解密後獲得真實服務器的公鑰。這個過程是創建在被你們所承認的證書機構之上獲得的公鑰，因此這是一種安全的方式。

 

（例：12306 中鐵CA根證書 您如今安裝的是中鐵數字證書認證中心（中鐵CA，SRCA）的根證書，完成這個操做可使您的購票體驗更爲順暢，同時得到一個更安全的網絡購票環境。 下載根證書而後得到數字證書認證機構（CA）的公鑰？）

參考：

http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html https://zh.wikipedia.org/wiki/%E5%85%AC%E5%BC%80%E5%AF%86%E9%92%A5%E5%8A%A0%E5%AF%86 https://zh.wikipedia.org/wiki/%E9%AB%98%E7%BA%A7%E5%8A%A0%E5%AF%86%E6%A0%87%E5%87%86 https://zh.wikipedia.org/wiki/%E8%B3%87%E6%96%99%E5%8A%A0%E5%AF%86%E6%A8%99%E6%BA%96 https://zh.wikipedia.org/wiki/%E6%95%B8%E4%BD%8D%E7%B0%BD%E7%AB%A0 http://www.guokr.com/post/114121/ http://op.baidu.com/2015/04/https-s01a01/

 

 

轉自：https://foofish.net/https-symmetric.html