加密 & 解密
備注：密碼學領域不存在完全不能破解的密碼，但是如果一個密碼需要很久很久，例如一萬年才能破解，就認為這個密碼是安全的了。
對稱加密
非對稱加密
公鑰加密、私鑰解密
私鑰簽名、公鑰認證
非對稱的底層原理是密碼學，密碼學的底層是數學。
非對稱加密的數學底層原理是：兩個大質數相乘很容易得到一個結果，但是相反，將這個結果反推到是哪兩個質數相乘卻非常困難。
秘鑰長度可以理解為兩個質數相乘結果的大小，秘鑰越長則使用的兩個質數的相乘結果越大。
簽名 & 驗簽
私鑰簽名，公鑰認證。
公鑰驗證數字簽名的過程如下：
- 獲取要驗證的數據、公鑰和數字簽名。
- 使用公鑰對數字簽名進行解密，得到解密后的哈希。
- 對要驗證的數據進行哈希計算，通常使用與創建數字簽名時相同的哈希算法。
- 將哈希計算得到的結果與解密后的哈希進行比較。
- 如果兩者完全一致，則表明數字簽名有效，驗證通過；否則，數字簽名無效，驗證失敗。
再通俗一點：公鑰驗證通常是 1. 通過使用公鑰對數字簽名解密后，得到hash值；2. 對data數據進行hash。3. 比較兩個hash值是否一樣來實現的。
參考鏈接SSH 原理與應用
哈希
哈希使用場景1：
對一個很大的文件進行簽名很浪費計算機性能，因此一般情況下會先對待簽名的文件進行哈希。（通過哈希來提取這個文件的特征-生成固定長度的字符串，也可以理解成這個文件的身份證，即唯一標識）。然后在對哈希值進行簽名。
哈希使用場景2：
并不是所有的加密都使用非對稱加密，對于很大的文件很浪費計算機性能。通常情況是利用對稱加密和非對稱加密結合的方式。即通過對稱加密算法對大文件進行加密，然后通過非對稱加密算法對對稱加密的秘鑰進行加密。
數字證書
上面的非對稱加密已經是非常安全的了，包括驗簽都是沒有問題的。但是還要一個沒有解決的問題就是 “中間人” 攻擊。
舉例：Bob 想要把一個帶數字簽名的文件傳遞給 Alice 。于是 Bob 生成了公鑰和私鑰，用私鑰簽署了文件。然后把公鑰上傳到一個公共服務器上。如果一切順利，那 Alice 去下載這個公鑰，然后就可以驗證簽名，確認文件的確是 Bob 發出的，同時沒有被篡改過。但是這里的安全漏洞是明顯的，那就是 Alice 無法確認她下載的公鑰是不是真的是 Bob 的。這就給所謂的“中間人攻擊”提供了可能。假設在 Bob 的文件還沒有到達 Alice 之前，黑客發起了中間人攻擊，刪除 Bob 的文件，然后簽署一個假文件發送給 Alice ，Alice 收到后去公共服務上下載的公鑰其實也被黑客替換過的，她用這個公鑰去驗證了簽名，自認為文件就是 Bob 發出的，所以被騙了。其實仔細想想，問題就出在公鑰本身沒有辦法證明自己的主人是誰。
所以要避免中間人攻擊，就要使用數字證書。Bob 簽名文件之后，給 Alice 發送時附上自己的證書。Alice 收到證書之后，就可以信任證書中的公鑰的確就是 Bob 的了。有了這個公鑰，可以驗證文件附帶的數字簽名是 Bob 的。數字簽名沒問題，就保證了文件是沒有被篡改過的。至于 Alice 如何確認證書本身是可信的，稍后我們聊 HTTPS 的過程中再展開聊。
數字證書是數字簽名的升級，數字證書能證明公鑰屬于誰。
數字證書中的數字簽名是CA的簽名。
那么怎么確定CA是沒問題的呢？計算機或者操作系統等在出廠的時候默認了權威的根證書的公鑰，然后就可以來驗證傳過來的證書的真偽。
數字證書場景的兩個應用場景
1、數字簽名
如上。
2、HTTPS
比如，我現在用瀏覽器來訪問谷歌服務器。要建立加密通道，首先第一步是要傳遞公鑰過來，但是服務器傳遞過來的公鑰如果過程中被篡改過，那么后續的加密通信也就全無安全性可言了。所以谷歌需要先去 CA 機構申請 SSL 證書，放到自己的服務器上。這樣，我在瀏覽器中輸入谷歌的網址，谷歌那邊會首先給瀏覽器發送 SSL 證書。注意，各個瀏覽器中都內置了對全球各大 CA 機構的驗證機制，底層的原理就是擁有 CA 們的公鑰，可以驗證證書上 CA 的簽名。如果證書沒有問題，瀏覽器就可以斷定證書中攜帶過來的公鑰就是谷歌的。這時候，瀏覽器會生成一個秘鑰，注意這里就是對稱加密的思路了，發送給谷歌服務器。這樣，谷歌擁有瀏覽器的加密秘鑰，可以用對稱加密的思路來跟瀏覽器通信了，這樣一個雙向的加密通信通道也就開通了。對稱加密的加密效率要比非對稱高，所以大量數據的傳遞首選對稱加密。
參考鏈接：數字證書SSL
參考鏈接：HTTPS
