數據加密解密初探

在一次網絡通訊或者是進程通訊中，若是傳輸數據採用明文的方式，那麼很容易被第三方"竊聽"到，安全性難以保障。

而所謂加密是讓數據從明文變成密文，傳輸過程當中是密文，傳送過去以後對方接收到的也是密文。——能夠理解爲密文就是亂碼，看不出內在的任何意義，一般也都是逐位對應的。

在接收方接收到密文以後只有把它還原爲原來的樣子才能夠理解對方說的具體是什麼，此過程就叫作解密。

所謂系統的安全要實現的目標應該包括：機密性-confidentiality，完整性-integrity 和可用性-availability；在通訊中威脅到上述三者的***行爲分別有：

1.威脅機密性的***行爲：竊聽、嗅探、掃描、通訊量分析

2.威脅完整性的***行爲：更改、假裝、重放、否定

3.威脅可用性的***行爲: 拒絕服務(DoS)

針對各類威脅安全性***行爲，咱們分別從技術層面和服務層面出發，有不一樣的解決方案。

技術：數據的加密和解密；服務：安全服務；

今天來初探Linux世界裏的加密和解密是怎麼一回事；

加密須要兩個東西，算法+密鑰；

加密的算法分爲四類：

1. 對稱加密算法-通俗的說就是 用什麼密鑰加密就用同一個密鑰進行解密；

   其優點所在就是加密速度較快；但劣勢也很是明顯：

   對稱加密沒法保證完整性。被截獲了，隨破解不出來裏面的密文是什麼，可是，截獲者插入一些字符篡改內容，再發送給接收者；接收者在接收到被篡改的密文之後，解密出來，發現內容彷佛沒有什麼意義，此時，怎樣肯定此密文就是本身信任的對方發送過來的呢？因此完整性是沒法獲得保證的。

   這種算法的主流算法有：DES，AES，3DES等等；

2. 公鑰加密算法-採用公鑰加密，私鑰解密；

   公鑰加密也叫作非對稱加密，加密解密採用同一組的公鑰和私鑰。

   先來解釋一下什麼是公鑰私鑰：

   私鑰(seceret key|private key)：是經過特定的工具建立生成；由使用者本身留存。務必保證其私密性；

   公鑰(public key)：從私鑰中提取生成，能夠公開給全部人使用；

   
   

   這種方式加密的數據安全等級高，代價就是密鑰很長，從512位、768位、1024位、2048位、4096位、8192位不等；由此也對系統的性能提出了更高的要求，例如此種加密技術的RSA的發展彷佛遇到了瓶頸。所以，不多用公鑰加密算法來加密大批量的數據；

3. 單項加密算法 - 提取數據特徵碼，只能由明文計算出密文，也就是隻可加密不能解密；

   所以此種算法的功能就是保證數據的完整性，防止被篡改；

   常見的算法：md五、SHA1(安全hash算法)、SHA二、SHA25六、SHA5十二、SHA3(目前最新的)

4. 密鑰加密算法-IKE

所謂IKE：

一、IPsec使用IKE來完成對等體之間的認證和密鑰的生成以及交換

二、協商和維護安全關聯（SA）參數

三、SA是一個集合，包含了加密算法，認證方式等等

四、經過認證，防止假裝***

五、自動產生密鑰，並自動更新密鑰

六、動態，安全的交換密鑰

在實際應用裏，通訊雙方數據加密進行如下步驟：

1.通訊雙方互相交換證書，併到信任的CA進行證書驗證；

2.發送方使用某種對稱加密算法對數據進行加密；對加密後的數據使用單向加密，計算其特徵值；發送方再用本身的私鑰加密此特徵值，以證實數據來源的可靠；發送方使用接收方的證書加密對稱密鑰；

3.接收方在收到數據後，先使用本身的私鑰解密對此密鑰；而後使用發送方的公鑰特徵值，再利用相同的單向加密算法；

不使用SSL/TLS的HTTP通訊，就是不加密的通訊。全部信息明文傳播，帶來了三大風險。

    （1）竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。

    （2）篡改風險（tampering）：第三方能夠修改通訊內容。

    （3）冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

SSL/TLS協議是爲了解決這三大風險而設計的，但願達到：

    （1）全部信息都是加密傳播，第三方沒法竊聽。

    （2）具備校驗機制，一旦被篡改，通訊雙方會馬上發現。

    （3）配備×××書，防止身份被冒充。

SSL/TLS協議的基本思路是採用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，而後用公鑰加密信息，服務器收到密文後，用本身的私鑰解密。

它將將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。這樣保證了公鑰不會被篡改；

    數字證書裏包含的內容：

    擁有者的名稱

    擁有者所提交的公鑰

    有效期

    證書的版本號

    證書的序列號

    簽發算法ID

    簽發CA的名稱

    主體名稱

    發證者惟一標識

    發證者的數字簽名

    擴展信息

所以，SSL/TLS協議的基本過程是這樣的：

（1） 客戶端向服務器端索要並驗證公鑰。

（2） 雙方協商生成"對話密鑰"。

（3） 雙方採用"對話密鑰"進行加密通訊。

前兩步也叫握手階段 - handshake  

SSL/TSL的handshake的四個階段：

1.客戶端向服務器索要證書並驗證；

client_hello發送的信息內容：

支持的協議版本，如：TLS V1.2...

客戶端生成的隨機數，可能在以後充當加密的密鑰；

支持的加密算法，如AES，sha...

協商各自支持的壓縮算法。非必

2.雙方協商生成會話密鑰；dh算法交換密鑰

Server_hello的內容：

確認使用的加密協議的版本號。

服務器生成一個隨機數，稍後用於生成會話密鑰

確認加密算法及壓縮算法；

3.雙方採用生成的會話密鑰進行安全加密的通訊；

客戶端驗證服務器證書，在確認無誤後，取出其公鑰；

驗證服務器證書須要驗證下述內容：

驗證發證機構CA；

驗證證書的完整性；

驗證證書的持有者信息；

驗證證書的有效期

驗證證書的吊銷列表；

客戶端發送信息給服務器：

 1.一個隨機數，用於服務器上的公鑰加密

 2.編碼格式變動的通知，表示隨後的信息都將用雙方已經協商好的加密算法和密鑰進行加密發送；

客戶端握手結束；

4.雙方互相通告握手結束的信息；

服務器會收到客戶端發送來的這次握手階段的第三個隨機數 Pre-Master_key

計算本次會話所用到的會話密鑰，向客戶端發送相關信息；

編碼變動通知，表示隨後的信息都將用雙方已經協商好的加密算法和密鑰進行加密發送；

服務器端握手結束；

接下來，客戶端與服務器進入加密通訊，就徹底是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。