概述：
兩個計算機在互聯網上通信時，它們之間發送的信息如果不經過特殊的處理，即加密機制，很容易被其他人給獲取到，如果是普通的信息，那倒是無所謂，但是如果涉及到個人的私密信息，那這樣豈不是很糟糕，本篇來說一下這個安全和加密機制。
加密算法和協議：
對稱加密：數據加密（保密性）（3DES,AES) 公鑰加密：身份認證、密鑰交換、數據加密（不常用，比對稱加密要慢3個數量級）（RSA,DSA） 單項加密：數據完整性（MD5,SHA） 密鑰交換：RSA、DH（迪菲-赫爾曼）、ECDH（橢圓曲線DH）、ECDHE（臨時橢圓曲線DH）
一 、對稱加密：加密和解密使用同一個密鑰
DES：Data Encryption Standard，56bits 3DES： AES：Advanced (128, 192, 256bits) Blowfish，Twofish IDEA，RC6，CAST5
特性：
1、加密、解密使用同一個密鑰，效率高
2、將原始數據分割成固定大小的塊，逐個進行加密
缺陷：
1、密鑰過多
2、密鑰分發
3、數據來源無法確認
二 、非對稱加密算法：即公鑰加密
公鑰加密：密鑰是成對出現
公鑰：公開給所有人；public key 私鑰：自己留存，必須保證其私密性；secret key
特點：
用公鑰加密數據，只能使用與之配對的私鑰解密；反之亦然
功能：
1 數字簽名：主要在于讓接收方確認發送方身份
2 對稱密鑰交換：發送方用對方的公鑰加密一個對稱密鑰后發送給對方
3數據加密：適合加密較小數據
缺點：
密鑰長，加密解密效率低下
算法：
RSA（加密，數字簽名）,DSA（數字簽名）,ELGamal
具體實現：
基于一對公鑰/密鑰對: 用密鑰對中的一個加密，另一個解密 接收者 生成公鑰/密鑰對：P和S 公開公鑰P，保密密鑰S 發送者 使用接收者的公鑰來加密消息M 將P(M)發送給接收者 接收者 使用密鑰S來解密：M=S(P(M))
三、單項加密：將任意數據縮小成固定大小的“指紋”
特點：
1 任意長度輸入
2 固定長度輸出
3 若修改數據，指紋也會改變（“不會產生沖突”）
4 無法從指紋中重新生成數據（“單向”）
功能：
數據完整性
常見算式：
md5: 128bits、sha1: 160bits、sha224
sha256、sha384、sha512
常用工具：
md5sum | sha1sum [ --check ] file
openssl、gpg
rpm -V
密鑰交換：IKE（Internet Key Exchange ）
公鑰加密：
DH (Deffie-Hellman)：
DH： 1、A: a,p協商生成公開的整數a,大素數p B: a,p 2、A:生成隱私數據:x (x<p )，計算得出a^x%p，發送給B B:生成隱私數據:y,計算得出a^y%p，發送給A 3、A:計算得出（a^y%p）^x = a^xy%p，生成為密鑰 B:計算得出（a^x%p）^y = a^xy%p, 生成為密鑰 此時，A和B便生成了一個相同的密鑰，注意這個密鑰交換協議算法只能用于密鑰的交換，而不能用于消息的加密處理，當雙方確定要用的密鑰后，要使用其他的對稱加密操作實際加密和解密數據
注意：
以上所說的加密算法和協議雖然能夠實現兩個兩個計算機之間的加密通信，可是保證不了其他計算機的干預消息。
例如：A和B是互聯網上的兩臺主機，A擁有自己的私鑰，B擁有自己的私鑰，此時如若A要給B發送消息，但是第一次它并不知道誰是B，如果此時有另一臺機器C告訴A說我就是B，然后把自己的公鑰發送給A，A此時還以為和它通信的真的是B，然而卻是A和C在通信。 那么問題來了，如何確定B的身份呢？如果此時有一個雙方都信任的第三方機構，由它來確認B的身份，那么問題就可以解決了，隨之而來的是誰來確定這個第三方機構的身份呢，如果是一個假的機構呢？所以還需要這個機構的上級來確定它，知道到了頂層。當然這個頂層是我們所有人在心底都默認知道和了解的。
說了這么多，這個所謂的第三方機構就叫做CA，當CA每確認一臺機器的時候，就會給它頒發一個證書，具體如下:
CA和證書
PKI: Public Key Infrastructure 簽證機構：CA（Certificate Authority） 注冊機構：RA 證書吊銷列表：CRL 證書存取庫： X.509：定義了證書的結構以及認證協議標準 版本號 序列號 簽名算法 頒發者 有效期限 主體名稱 主體公鑰 CRL分發點 擴展信息 發行者簽名 證書類型： 證書授權機構的證書 服務器 用戶證書 獲取證書兩種方法： 使用證書授權機構 生成簽名請求（csr） 將csr發送給CA 從CA處接收簽名 自簽名的證書 自已簽發自己的公鑰
證書簽發過程：如下圖所示
- 1、A將自己的公鑰發送給CA
- 2、CA在確定A的身份后，會將證書頒發給A，其中過程如下
1）CA會將應有內容整合到證書上，證書的內容結構如上。 2）然后將此內容使用單向加密算法生成特征碼（用于驗證證書完整性） 3）最后，CA會使用自己的私鑰來對此特征嗎進行加密，生成數字簽名（用來驗證是否為CA簽署的證書），然后發給A
- 3）B的過程與A相同
當B驗證A的身份時，就是通過證書來驗證的，步驟如下
- 1 使用CA的公鑰來解密數字簽名，如果成功，則驗證了CA身份
- 2 利用相同的單項加密算法來計算證書內容結構的特征碼，與原來的特征碼相比較，如果相同，則保證了證書的完整性
- 3 從證書內容中取出A的公鑰
加密通信過程詳解
第一階段：ClientHello：客戶端向服務器端發起加密通信的請求
1 向服務器發送自己支持的協議版本，比如tls1.2 2 客戶端生成一個隨機數，稍后用戶生成”會話密鑰“ 3 自己支持的各種加密算法，比如AES，RSA等 支持的壓縮算法；
第二階段：ServerHello（回應）
1 確認使用的加密通信協議版本，比如tls1.2；（如果版本不一樣，則拒絕通信） 2 服務器端生成一個隨機數，主要在稍后用戶生成”會話密鑰“ 3 確認使用的加密方法 4 發送服務器證書 5 索要客戶端證書（不過一般服務器端都不會驗證客戶端）
第三階段：
1 驗證服務器證書，確認無誤后，取出其公鑰；（驗證發證機構、證書簽名、證書完整性、證書持有者、證書有效期、吊銷列表） 2 發送一下信息給服務器端 3 一個隨機數：用于服務器公鑰加密 4 編碼變更通知：表示隨后的信息都將用雙方商定的加密方法和密鑰發送 5 客戶端握手結束通知
第四階段：
1 收到客戶端發來的第三個隨機數-pre-master-kty后，計算生成本次會話用到的會話密鑰 2 向客戶端發送如下消息 3 編碼變更通知：與上相同 4 服務器端握手結束通知
此時雙方已經彼此確認了對方的身份，并且建立一條安全的通道，接下來就可以傳輸信息了。此過程如下圖所示：
（1）A-->B
1）使用單向加密算法計算要傳輸的數據的特征碼（并沒有對原數據內容加密） 2）使用自己的私鑰來加密這段特征碼生成數字簽名 3）使用對稱加密算法加密上面的所有數據（包括原數據，特征碼，數字簽名），將生成的對稱加密的密碼附加在加密過的數據后面 4）使用B的公鑰來加密這段對稱加密的密碼，并將以上所有數據發送給B
（2）B收到A發送的數據后
1）使用B的要來解密對稱加密的密碼（如果可以解密，則保證接收放是B） 2）利用解密過的對稱加密密碼來解密這段數據 3）解密后通過利用A的公鑰來解密數字簽名（如果可以，則保證了數據是從A發的） 4）此時，呈現在B的有兩樣東西，一個是原數據，還有一個是特征碼。且原數據是沒有加密的。此時B需要使用相同的單項加密算法對此時的原數據計算特征碼，與A發送過來的特征碼相比較，如果相等，則保證了原數據的完整性。
至此。信息的加密與解密過程完成。
總結：
在以上所述的過程中，個人認為有幾點需要強調：
1）單項加密并不加密原數據，只是為了計算原數據的特征碼。用于數據的完整性校驗
2）對稱加密算法加密和解密都是用同一個密鑰。用于加密數據
3）公鑰加密加密的是特征碼。用于生成數字簽名
4）證書的頒發和驗證過程和數據的傳輸過程是兩個過程
