加密與解密

加密解密

Base64編解碼

在參數傳輸的過程中經常遇到的一種情況：使用全英文的沒問題，但一旦涉及到中文就會出現亂碼情況。與此類似，網絡上傳輸的字元并不全是可列印的字元，比如二進制檔案、圖檔等。Base64的出現就是為了解決此問題，它是基于64個可列印的字元來表示二進制的資料的一種方法。

我們知道在計算機中任何資料都是按ascii碼存儲的，而ascii碼的128～255之間的值是不可見字元。而在網絡上交換資料時，比如說從A地傳到B地，往往要經過多個路由裝置，由于不同的裝置對字元的處理方式有一些不同，這樣那些不可見字元就有可能被處理錯誤，這是不利于傳輸的。是以就先把資料先做一個Base64編碼，統統變成可見字元，這樣出錯的可能性就大降低了。

Base64索引表:​

​['A','B'...'a','b',...'0','1',...'+','/']​

​

轉換步驟:

• 待轉換字元串每3個位元組分為一組,共24位
• 将上面24位每6個一組分為4組
• 在每組前面添加兩個0,總共32位,即4個位元組
• 根據上面Base64索引表獲得相應的值

是以Base64編碼之後的文本要比原文大約三分之一

如果位數不足,依舊是每6分位元組一組,不足的用0補齊,後面沒有對應資料的用​

​=​

​補齊.

Base64是一種任意二進制到文本字元串的編碼方法，常用于在URL、Cookie、網頁中傳輸少量二進制資料。在項目中,将封包進行壓縮、加密後,最後一步必然是使用base64編碼,因為base64編碼的字元串更适合不同平台、不同語言的傳輸.

SHA-256 哈希函數

一個​

​n​

​位的哈希函數就是一個從任意長的消息到​

​n​

​位哈希值的映射,這樣的函數是目前在數字簽名和密碼保護當中極為重要的手段。目前比較流行的哈希函數主要有128位的MD4和MD5和160位的SHA-1，今天介紹的SHA-2(Secure Hash Algorithm 2)族有着更多位的輸出哈希值，破解難度更大，能夠提高更高的安全性.

對于任意長度的消息，SHA256都會産生一個256位的哈希值，稱作消息摘要,通常用64個十六進制字元串表示.

稱謂: 單向散列函數, 哈希函數, 雜湊函數, 消息摘要函數

輸入: 原像

輸出: 散列值, 哈希值, 指紋, 摘要

常見的應用場景有: 資料庫中保護使用者密碼、防止檔案篡改、數字簽名、僞随機數生成、秒傳等.

RSA加密算法

RSA是目前最有影響力和最常用的公鑰加密算法(非對稱加密)，可以說是公鑰加密算法的事實标準。

​公鑰=(E,N)​

​ ​

​私鑰=(D,N)​

​ ​

​密鑰對=(E,D,N)​

是以生成密鑰對就是求E、D、N.

• N: 準備兩個互質數p，q。這兩個數不能太小，太小則會容易破解，将p乘以q就是N。如果互質數p和q足夠大，那麼根據目前的計算機技術和其他工具，至今也沒能從N分解出p和q。換句話說，隻要密鑰長度N足夠大（一般1024足矣），基本上不可能從公鑰資訊推出私鑰資訊。
• L: p－1 和 q－1的最小公倍數,即lcm(p-1,q-1)
• E: E是一個比1大比L小的數，E和L的最大公約數為1.
• D: 數D是由數E計算出來的，數D必須保證足夠大.1 < D < L; E*D mod L = 1.隻要D滿足上述2個條件，則通過E和N進行加密的密文就可以用D和N進行解密.

是以RSA公鑰加密體制包含三個算法:

(PK,M)<---KeyGen(

): 密鑰生成算法,

是安全常數,值越大,質數p越大

CT <---Encrypt(PK,M): 加密算法

M <---Decrypt(SK,CT): 解密算法

但是公鑰加密會面臨中間人攻擊的危險, 是以我們要確定公鑰必須是我們想要發送的對方的公鑰,而不是其他人頂替的.這就需要給公鑰簽名.

非對稱加密算法除了支援加密外,還可以實作簽名.

簽名過程: 使用發送方私鑰對消息摘要加密, 生成消息簽名, 接收方公鑰生成密文發送出去(防止hash值也被篡改)

驗簽過程: 使用接收方私鑰對密文進行解密, 獲得消息和消息簽名; 使用發送方公鑰解密消息簽名, 獲得消息摘要; 使用相同雜湊演算法生成消息摘要進行對比,如果相同驗簽成功.

RSA簽名體制同樣包含三個算法:

(PK,SK)<---KeyGen(

)

<---Sign(SK,M): 簽名算法以私鑰SK和待簽名的消息M作為輸入，輸出簽名

b <---Verify(PK,

,M): 驗證算法以公鑰PK，簽名

以及消息M作為輸入，輸出一個比特值b。b=1意味着驗證通過。b=0意味着驗證不通過

HTTPS加密過程和證書驗證過程

首先https=http+tls. TLS是基于TCP協定之上的,由SSL發展而來.TLS協定的優勢是與高層應用層協定無耦合,應用層協定能夠透明的運作在TLS協定之上,由TLS協定進行建立加密通道需要的協商和認證。應用層協定傳送的資料在通過TLS協定時都會被加密，進而保證通信的私密性。

基本過程是: 用戶端像伺服器端索要公鑰;雙方生成“對話密鑰”;雙方采用“對話密鑰”進行通信.

問題:

1. 如何保證公鑰不被篡改?

   将公鑰放在證書裡,隻要證書可信,公鑰就是可信的.

2. 公鑰加密計算量太大,如何減少耗用時間?

   每一次對話（session），用戶端和伺服器端都生成一個"對話密鑰"（session key），用它來加密資訊。由于"對話密鑰"是對稱加密，是以運算速度非常快，而伺服器公鑰隻用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

TLS協定流程

一旦用戶端和伺服器都同意使用TLS協定,他們通過一個握手過程協商出一個有狀态的連接配接以傳輸資料.這通常發生在TCP連接配接建立以後.具體過程為:

• 用戶端發送TLS版本号+所支援加密套件清單(加密算法、雜湊演算法)+用戶端生成的随機數+希望使用的TLS選項
• 伺服器端選擇一個用戶端加密套件+自己的證書+服務端生成的随機數+希望使用的TLS選項+(要求用戶端證書)

• 用戶端驗證伺服器身份後,取出證書中的公鑰,發送(自己證書)+使用伺服器公鑰加密一個随機數(此時雙方各有三個相同随機數,用于生成會話密鑰)

  為什麼需要三個随機數?

  用戶端和伺服器加上pre master secret三個随機數一同生成的密鑰就不容易被猜出了，一個僞随機可能完全不随機，可是是三個僞随機就十分接近随機了，每增加一個自由度，随機性增加的可不是一.

• 伺服器端使用私鑰解密出資訊後,計算生成會話密鑰,發送加密的finish消息,表明完成握手,接下來進行的通信就是普通的http協定,隻不過發送的是加密過的消息.

證書驗證過程

證書簽發過程:

• 撰寫證書中繼資料資訊
• 通過Hash算法計算出消息摘要
• 然後用CA機構的私鑰對消息摘要加密,生成簽名,附在檔案證書上,使之變成一個簽名過的證書.

證書驗證過程:

• 用戶端獲得站點的證書,解碼後獲得中繼資料資訊和簽名,要驗證站點可信後,才能使用其公鑰,是以用戶端找到其站點證書頒發者的資訊
• 站點證書的頒發者驗證了服務端站點是可信的，但用戶端依然不清楚該頒發者是否可信
• 再往上回溯，找到了認證了中間證書商的根證書頒發者。由于根的證書頒發者非常少，我們浏覽器之前就認識了，是以可以認為根證書頒發者是可信的；
• 一路倒推，證書頒發者可信，那麼它所頒發的所有站點也是可信的，最終确定了我們所通路的服務端是可信的；
• 用戶端使用證書中的公鑰，繼續完成​

  ​TLS​

  ​的握手過程

自簽證書

首先,X.509是一個标準,規範了公開秘鑰認證、證書吊銷清單、授權憑證、憑證路徑驗證算法等。X.509證書包含三個檔案: .key、.csr、.crt(.pem),分别是私鑰、證書簽名請求檔案、簽名後的證書.

我們可以使用openssl指令行工具給自己簽證書,用于測試使用或内部系統使用,但這樣會被浏覽器提示未認證的簽名機構,需要我們自己信任該證書,不過有的浏覽器可能對于私有證書會直接拒絕不給提示的機會.

自簽證書相當于把自己生成的證書簽名請求檔案,用自己的私鑰去做簽名,相當于CA憑證,自己給自己做驗證.這個證書還可以給其他用戶端去做前面,這樣當我們有多個用戶端的時候,隻需要在用戶端安裝根證書就可以了,不必重複安裝用戶端證書.

X.509證書有兩種編碼格式:

• PEM: 是明文格式的, 以 -----BEGIN CERTIFICATE-----開頭，已-----END CERTIFICATE-----結尾，中間是經過base64編碼的内容,apache需要的證書就是這類編碼的證書 檢視這類證書的資訊的指令為 ：openssl x509 -noout -text -in server.pem
• DER: 是二進制格式的證書,檢視這類證書的資訊的指令為 ：openssl x509 -noout -text -inform der -in server.der

我們遇到常用的證書擴充名.crt、.cer、.pem大部分都使用PEM編碼格式.

.key 一般公鑰或者密鑰都會用這種擴充名，可以是DER編碼的或者是PEM編碼的 檢視DER編碼的（公鑰或者密鑰）的檔案的指令為 openssl rsa -inform DER -noout -text -in xxx.key 檢視PEM編碼的（公鑰或者密鑰）的檔案的指令為 openssl rsa -inform PEM -noout -text -in xxx.key