Ⅰ 常見密碼技術簡介
##
密碼技術在網路傳輸安全上的應用
隨著互聯網電子商務和網路支付的飛速發展，互聯網安全已經是當前最重要的因素之一。作為一名合格的軟體開發工程師，有必要了解整個互聯網是如何來保證數據的安全傳輸的，本篇文章對網路傳輸安全體系以及涉及到的演算法知識做了一個簡要的介紹，希望大家能夠有一個初步的了解。
###密碼技術定義
簡單的理解，密碼技術就是編制密碼和破譯密碼的一門技術，也即是我們常說的加密和解密。常見的結構如圖：
其中涉及到的專業術語：
1.秘鑰：分為加密秘鑰和解密秘鑰，兩者相同的加密演算法稱為對稱加密，不同的稱為非對稱加密；
2.明文：未加密過的原文信息，不可以被泄露；
3.密文：經過加密處理後的信息，無法從中獲取有效的明文信息；
4.加密：明文轉成密文的過程，密文的長度根據不同的加密演算法也會有不同的增量；
5.解密：密文轉成明文的過程；
6.加密/解密演算法：密碼系統使用的加密方法和解密方法；
7.攻擊：通過截獲數據流、釣魚、木馬、窮舉等方式最終獲取秘鑰和明文的手段。
###密碼技術和我們的工作生活息息相關
在我們的日常生活和工作中，密碼技術的應用隨處可見，尤其是在互聯網系統上。下面列舉幾張比較有代表性的圖片，所涉及到的知識點後面都會一一講解到。
1.12306舊版網站每次訪問時，瀏覽器一般會提示一個警告，是什麼原因導致的？ 這樣有什麼風險呢？
2.360瀏覽器瀏覽HTTPS網站時，點開地址欄的小鎖圖標會顯示加密的詳細信息，比如網路的話會顯示```AES_128_GCM、ECDHE_RSA```，這些是什麼意思？
3.在Mac系統的鑰匙串里有很多的系統根證書，展開後有非常多的信息，這些是做什麼用的？
4.去銀行開通網上支付都會附贈一個U盾，那U盾有什麼用呢？
##如何確保網路數據的傳輸安全
接下來我們從實際場景出發，以最常見的客戶端Client和服務端Server傳輸文件為例來一步步了解整個安全體系。
####1. 保密性
首先客戶端要把文件送到服務端，不能以明文形式發送，否則被黑客截獲了數據流很容易就獲取到了整個文件。也就是文件必須要確保保密性，這就需要用到對稱加密演算法。
** 對稱加密： **加密和解密所使用的秘鑰相同稱為對稱加密。其特點是速度快、效率高，適用於對較大量的數據進行加密。常見的對稱加密演算法有DES、3DES、AES、TDEA、RC5等，讓我們了解下最常見的3DES和AES演算法：
** DES(Data Encryption Standard)： **1972年由美國IBM研製，數學原理是將明文以8位元組分組（不足8位可以有不同模式的填充補位），通過數學置換和逆置換得到加密結果，密文和明文長度基本相同。秘鑰長度為8個位元組，後有了更安全的一個變形，使用3條秘鑰進行三次加密，也就是3DES加密。
**3DES：**可以理解為對明文進行了三次DES加密，增強了安全程度。
** AES(Advanced Encryption Standard)： **2001年由美國發布，2002年成為有效標准，2006年成為最流行的對稱加密演算法之一。由於安全程度更高，正在逐步替代3DES演算法。其明文分組長度為16位元組，秘鑰長度可以為16、24、32(128、192、256位)位元組，根據秘鑰長度，演算法被稱為AES-128、AES-192和AES-256。
對稱加密演算法的入參基本類似，都是明文、秘鑰和模式三個參數。可以通過網站進行模擬測試：[http://tool.chacuo.net/crypt3des]()。其中的模式我們主要了解下ECB和CBC兩種簡單模式，其它有興趣可自行查閱。
** ECB模式(Electronic Codebook Book)： **這種模式是將明文分成若干小段，然後對每一段進行單獨的加密，每一段之間不受影響，可以單獨的對某幾段密文進行解密。
** CBC模式(Cipher Block Chaining)： **這種模式是將明文分成若干小段，然後每一段都會和初始向量(上圖的iv偏移量)或者上一段的密文進行異或運算後再進行加密，不可以單獨解密某一斷密文。
** 填充補位： **常用為PKCS5Padding，規則為缺幾位就在後面補幾位的所缺位數。，比如明文數據為```/x01/x01/x01/x01/x01/x01```6個位元組，缺2位補```/x02```，補完位```/x01/x01/x01/x01/x01/x01/x02/x02```。解密後也會按照這個規則進行逆處理。需要注意的是：明文為8位時也需要在後面補充8個```/x08```。
####2. 真實性
客戶端有了對稱秘鑰，就需要考慮如何將秘鑰送到服務端，問題跟上面一樣：不能以明文形式直接傳輸，否則還是會被黑客截獲到。這里就需要用到非對稱加密演算法。
** 非對稱加密： **加密和解密秘鑰不同，分別稱為公開秘鑰(publicKey)和私有秘鑰(privateKey)。兩者成對出現，公鑰加密只能用私鑰解密，而私鑰加密也只能用公鑰加密。兩者不同的是：公鑰是公開的，可以隨意提供給任何人，而私鑰必須保密。特點是保密性好，但是加密速度慢。常見的非對稱加密演算法有RSA、ECC等；我們了解下常見的RSA演算法：
** RSA(Ron Rivest、Adi Shamir、Leonard Adleman)： **1977年由麻省理工學院三人提出，RSA就是他們三個人的姓氏開頭字母拼在一起組成的。數學原理是基於大數分解。類似於```100=20x5```，如果只知道100的話，需要多次計算才可以試出20和5兩個因子。如果100改為極大的一個數，就非常難去試出真正的結果了。下面是隨機生成的一對公私鑰:
這是使用公鑰加密後結果：
RSA的這種特性就可以保證私鑰持有者的真實性，客戶端使用公鑰加密文件後，黑客就算截獲到數據因為沒有私鑰也是無法解密的。
** Tips： **
+** 不使用對稱加密，直接用RSA公私鑰進行加密和解密可以嗎？ **
答案：不可以，第一是因為RSA加密速度比對稱加密要慢幾十倍甚至幾百倍以上，第二是因為RSA加密後的數據量會變大很多。
+** 由服務端生成對稱秘鑰，然後用私鑰加密，客戶端用公鑰解密這樣來保證對稱秘鑰安全可行嗎？ **
答案：不可行，因為公鑰是公開的，任何一個人都可以拿到公鑰解密獲取對稱秘鑰。
####3. 完整性
當客戶端向服務端發送對稱秘鑰加密後的文件時，如果被黑客截獲，雖然無法解密得到對稱秘鑰。但是黑客可以用服務端公鑰加密一個假的對稱秘鑰，並用假的對稱秘鑰加密一份假文件發給服務端，這樣服務端會仍然認為是真的客戶端發送來的，而並不知道閱讀的文件都已經是掉包的了。
這個問題就需要用到散列演算法，也可以譯為Hash。常見的比如MD4、MD5、SHA-1、SHA-2等。
** 散列演算法(哈希演算法)： **簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數。而且該過程是不可逆的，無法通過摘要獲得原文。
** SHA-1(Secure Hash Algorithm 1)： **由美國提出，可以生成一個20位元組長度的消息摘要。05年被發現了針對SHA-1的有效攻擊方法，已經不再安全。2010年以後建議使用SHA-2和SHA-3替代SHA-1。
** SHA-2(Secure Hash Algorithm 2)： **其下又分為六個不同演算法標准：SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA512/256。其後面數字為摘要結果的長度，越長的話碰撞幾率越小。SHA-224的使用如下圖：
客戶端通過上面的散列演算法可以獲取文件的摘要消息，然後用客戶端私鑰加密後連同加密的文件發給服務端。黑客截獲到數據後，他沒有服務端私鑰無法獲取到對稱秘鑰，也沒有客戶端私鑰無法偽造摘要消息。如果再像上面一樣去掉包文件，服務端收到解密得到摘要消息一對比就可以知道文件已經被掉包篡改過了。
這種用私鑰對摘要消息進行加密的過程稱之為數字簽名，它就解決了文件是否被篡改問題，也同時可以確定發送者身份。通常這么定義：
** 加密： **用公鑰加密數據時稱為加密。
** 簽名： **用私鑰加密數據時稱為簽名。
####4. 信任性
我們通過對稱加密演算法加密文件，通過非對稱加密傳輸對稱秘鑰，再通過散列演算法保證文件沒被篡改過和發送者身份。這樣就安全了嗎？
答案是否定的，因為公鑰是要通過網路送到對方的。在這期間如果出現問題會導致客戶端收到的公鑰並不一定是服務端的真實公鑰。常見的** 中間人攻擊 **就是例子：
** 中間人攻擊MITM(Man-in-the-MiddleAttack)： **攻擊者偽裝成代理伺服器，在服務端發送公鑰證書時，篡改成攻擊者的。然後收到客戶端數據後使用攻擊者私鑰解密，再篡改後使用攻擊者私鑰簽名並且將攻擊者的公鑰證書發送給伺服器。這樣攻擊者就可以同時欺騙雙方獲取到明文。
這個風險就需要通過CA機構對公鑰證書進行數字簽名綁定公鑰和公鑰所屬人，也就是PKI體系。
** PKI(Privilege Management Infrastructure)： **支持公鑰管理並能支持認證、加密、完整性和可追究性的基礎設施。可以說整個互聯網數據傳輸都是通過PKI體系進行安全保證的。
** CA(Certificate Authority)： **CA機構就是負責頒發證書的，是一個比較公認的權威的證書發布機構。CA有一個管理標准：WebTrust。只有通過WebTrust國際安全審計認證，根證書才能預裝到主流的瀏覽器而成為一個全球可信的認證機構。比如美國的GlobalSign、VeriSign、DigiCert，加拿大的Entrust。我國的CA金融方面由中國人民銀行管理CFCA，非金融CA方面最初由中國電信負責建設。
CA證書申請流程：公司提交相應材料後，CA機構會提供給公司一張證書和其私鑰。會把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式寫到證書裡面，然後用一個指紋演算法計算出這些數字證書內容的一個指紋，並把指紋和指紋演算法用自己的私鑰進行加密。由於瀏覽器基本都內置了CA機構的根證書，所以可以正確的驗證公司證書指紋（驗簽），就不會有安全警告了。
但是：所有的公司其實都可以發布證書，甚至我們個人都可以隨意的去發布證書。但是由於瀏覽器沒有內置我們的根證書，當客戶端瀏覽器收到我們個人發布的證書後，找不到根證書進行驗簽，瀏覽器就會直接警告提示，這就是之前12306打開會有警告的原因。這種個人發布的證書，其實可以通過系統設置為受信任的證書去消除這個警告。但是由於這種證書機構的權威性和安全性難以信任，大家最好不要這么做。
我們看一下網路HTTPS的證書信息：
其中比較重要的信息：
簽發機構：GlobalSign Root CA；
有效日期：2018-04-03到2019-05-26之間可用；
公鑰信息：RSA加密，2048位；
數字簽名：帶 RSA 加密的 SHA-256 ( 1.2.840.113549.1.1.11 )
綁定域名：再進行HTTPS驗證時，如果當前域名和證書綁定域名不一致，也會出現警告；
URI：在線管理地址。如果當前私鑰出現了風險，CA機構可以在線吊銷該證書。
####5. 不可抵賴性
看起來整個過程都很安全了，但是仍存在一種風險：服務端簽名後拒不承認，歸咎於故障不履行合同怎麼辦。
解決方法是採用數字時間戳服務：DTS。
** DTS(digital time-stamp)： **作用就是對於成功的電子商務應用，要求參與交易各方不能否認其行為。一般來說，數字時間戳產生的過程為：用戶首先將需要加時間戳的文件用Hash演算法運算形成摘要，然後將該摘要發送到DTS。DTS在加入了收到文件摘要的日期和事件信息後再對該文件進行數字簽名，然後送達用戶。
####6. 再次認證
我們有了數字證書保證了身份的真實性，又有了DTS提供的不可抵賴性。但是還是不能百分百確定使用私鑰的就是合法持有者。有可能出現被別人盜用私鑰進行交易的風險。
解決這個就需要用到強口令、認證令牌OTP、智能卡、U盾或生物特徵等技術對使用私鑰的當前用戶進行認證，已確定其合法性。我們簡單了解下很常見的U盾。
** USB Key(U盾)： **剛出現時外形比較像U盤，安全性能像一面盾牌，取名U盾。其內部有一個只可寫不可讀的區域存儲著用戶的私鑰(也有公鑰證書)，銀行同樣也擁有一份。當進行交易時，所有涉及到私鑰的運算都在U盾內部進行，私鑰不會泄露。當交易確認時，交易的詳細數據會顯示到U盾屏幕上，確認無誤後通過物理按鍵確認就可以成功交易了。就算出現問題黑客也是無法控制U盾的物理按鍵的，用戶可以及時取消避免損失。有的U盾裡面還有多份證書，來支持國密演算法。
** 國密演算法： **國家密碼局針對各種演算法制定了一些列國產密碼演算法。具體包括：SM1對稱加密演算法、SM2公鑰演算法、SM3摘要演算法、SM4對稱加密演算法、ZUC祖沖之演算法等。這樣可以對國產固件安全和數據安全進行進一步的安全控制。
## HTTPS分析
有了上面的知識，我們可以嘗試去分析下HTTPS的整個過程，用Wireshark截取一次HTTPS報文：
Client Hello: 客戶端發送Hello到服務端443埠，裡麵包含了隨機數、客戶端支持的加密演算法、客戶端的TLS版本號等；
Server Hello: 服務端回應Hello到客戶端，裡麵包含了服務端選擇的加密套件、隨機數等；
Certificate： 服務端向客戶端發送證書
服務端計算對稱秘鑰：通過ECDH演算法得到對稱秘鑰
客戶端計算對稱秘鑰：通過ECDH演算法得到對稱秘鑰
開始用對稱秘鑰進行加密傳輸數據
其中我們又遇到了新的演算法：DH演算法
** DH(Diffie-Hellman)： **1976年由Whitefield與Martin Hellman提出的一個奇妙的秘鑰交換協議。這個機制的巧妙在於可以通過安全的方式使雙方獲得一個相同的秘鑰。數學原理是基於原根的性質，如圖：
*** DH演算法的用處不是為了加密或解密消息，而是用於通信雙方安全的交換一個相同的秘鑰。 ***
** ECDH： **基於ECC(橢圓曲線密碼體制)的DH秘鑰交換演算法，數學原理是基於橢圓曲線上的離散對數問題。
** ECDHE： **字面少了一個E，E代表了臨時。在握手流程中，作為伺服器端，ECDH使用證書公鑰代替Pb，使用自身私鑰代替Xb。這個演算法時伺服器不發送server key exchange報文，因為發送certificate報文時，證書本身就包含了Pb信息。
##總結
| 演算法名稱 | 特點 | 用處 | 常用演算法名 |
| --- | :--- | :---: | ---: |
| 對稱加密 | 速度快，效率高| 用於直接加密文件 | 3DES、AES、RC4 |
| 非對稱加密 | 速度相對慢，但是確保安全 | 構建CA體系 | RSA、ECC |
| 散列演算法 | 算出的摘要長度固定，不可逆 | 防止文件篡改 | SHA-1、SHA-2 |
| DH演算法 | 安全的推導出對稱秘鑰 | 交換對稱秘鑰 | ECDH |
----
Ⅱ 如何查看本機能夠支持的https加密演算法套件
WIN 2008 R2 IIS 7 以上版本
CentOS 6+ OpenSSL 1.0.1c+
Apache 2.4 +
Nginx 1.0.6+
JDK1.7
tomcat7.0.56+
(以上版本都可以）
Ⅲ 如何在反編譯的apk中找到加密演算法
所謂APK指的是android操作系統的應用程序安裝文件。所謂Crack，簡單地理解為「破解」。我具體指的是反編譯APK文件進行匯編級的代碼分析，並修改或插入自己的代碼，重新簽名打包為APK文件，以達到改變程序原有行為的目的。
由以上的說明可知，我們要Crack一個APK文件，主要流程有三步：反編譯、代碼分析、重新打包簽名。
基本准備
我們需要一些基本的工具進行一些主要的工作。如果你是一個會做Android APK漢化的朋友，那麼你應該對這些工具非常熟悉：
第一個工具是android-apktool，A tool for reengineering Android apk files 。這個工具是我們完成APK Crack的核心，利用它實現APK文件的反編譯和重新打包。它是Google Code上一個非常著名的開源項目，大家可以在Google Code的網頁上獲取它和它的Wiki、源碼及其他相關信息。
第二個工具是Auto-sign。這個工具實現的是APK打包後的簽名工作，屬於一個小工具。
除了這些基本工具外，為了更好的分析代碼，你可能還需要用到一些其他工具，例如：dex2jar和jd-gui等，這里不做詳述。
反編譯
如果你是一個經常漢化APK程序的朋友，那麼反編譯這一步你肯定不會陌生。不過，既然這篇文章側重於基本流程講解，那麼這一步想來是不能省掉的。所以，覺得羅嗦的朋友，請跳過。首先我們需要有一個待反編譯的APK。這里我自己寫了一個HelloWorld的APK，代碼如下：
package com.zh_weir.helloworld;import android.app.Activity;
import android.os.Bundle;
public class MainActivity extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
復制代碼
我們通過android-apktool對這個APK進行反編譯。對於android-apktool的使用，我就不做太多翻譯的工作，直接給出說明文檔吧。簡單一句話，就是命令行執行。
Apktool v1.3.2 - a tool for reengineering Android apk files
Copyright 2010 Ryszard Wi?niewski <[email protected]>
Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0)
Usage: apktool [-v|--verbose] COMMAND [...]
COMMANDs are:
d[ecode] [OPTS] <file.apk> [<dir>]
Decode <file.apk> to <dir>.
OPTS:
-s, --no-src
Do not decode sources.
-r, --no-res
Do not decode resources.
-d, --debug
Decode in debug mode. Check project page for more info.
-f, --force
Force delete destination directory.
-t <tag>, --frame-tag <tag>
Try to use framework files tagged by <tag>.
--keep-broken-res
Use if there was an error and some resources were dropped, e.g.:
"Invalid config flags detected. Dropping resources", but you
want to decode them anyway, even with errors. You will have to
fix them manually before building.
b[uild] [OPTS] [<app_path>] [<out_file>]
Build an apk from already decoded application located in <app_path>.
It will automatically detect, whether files was changed and perform
needed steps only.
If you omit <app_path> then current directory will be used.
If you omit <out_file> then <app_path>/dist/<name_of_original.apk>
will be used.
OPTS:
-f, --force-all
Skip changes detection and build all files.
-d, --debug
Build in debug mode. Check project page for more info.
if|install-framework <framework.apk>
Install framework file to your system.
For additional info, see: http://code.google.com/p/android-apktool/
復制代碼
通過apktool d HelloWorld.apk的命令，我們就完成了一個簡單的APK的反編譯工作。得到了一個叫做「HelloWorld」的文件夾。你可以看見文件夾下有Manifest文件，有反編譯出的res資源文件。這些東西都是平時漢化特別關心的，而不是我們要注意的重點。我們需要注意的是一個叫做「smali」的文件夾。
仔細觀察，你會發現這個文件夾下的文件組織結構和我們的Android工程中java源碼的組織結構幾乎一致。只不過Java文件被.smali的文件取而代之了。我們用文本編輯器打開這些.smali文件，你會發現它們都是可識別的、並且非常「整齊」的文本文件。
Ⅳ 2019-07-15
檢測到遠端XFS服務正在運行中漏洞
臨時關閉fs.auto服務：
可以通過編輯/etc/inetd.conf文件，重新啟動Inetd進程來關閉fs.auto服務：
1. 注釋/etc/inetd.conf文件中的如下一行：
#fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs
2. 重新啟動inetd進程：
# ps -elf |grep inetd
root 138 1 0 Oct 15 ? 0:00 /usr/sbin/inetd
# kill -1 138
solaris 查找文件 find命令
1. find命令格式
find: [-H | -L] 路徑列表 謂詞列表
可以使用：man find 查看命令選項。
2. 通過文件名查找法：
如果你把這個文件放在單個的文件夾裡面，只要使用常見的「ls"命令就能方便的查找出來，如果知道了某個文件的文件名，而不知道這個文件放到哪個文件夾，甚至是層層套嵌的文件夾里。舉例說明，假設你忘記了sshd_config（ssh 伺服器 的配置文件）這個文件在系統的哪個目錄下，甚至在系統的某個地方也不知道，則這是可以使用如下命令
find / -name sshd_config
這個命令語法看起來很容易就明白了，就是直接在find後面寫上 -name，表明要求系統按照文件名查找，最後寫上httpd.conf這個目標文件名即可。稍等一會系統會在計算機 屏幕 上顯示出查找結果列表：
#find / -name sshd_config
/var/sadm/pkg/SUNWsshdr/save/pspool/SUNWsshdr/reloc/etc/ssh/sshd_config
/etc/ssh/sshd_config
如果輸入以上查找命令後系統並沒有顯示出結果，那麼不要以為系統沒有執行find/ -name sshd_config 命令，而可能是你的系統中沒有安裝ssh 伺服器 ，這時只要你安裝了ssh伺服器，然後再使用find / -name sshd_config 就能找到這個配置文件了。
伺服器支持 TLS Client-initiated 重協商攻擊 (CVE-2011-1473)
SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通信提供安全及數據完整性的一種安全協議。
重協商就是大部分TLS連接都以handshake為開始，經過應用數據的交換，最後關閉會話。如果在第一次handshake之後（可能經歷了應用數據的交換也可能沒有）請求重新協商，就會發起一次新的handshake，對新的安全參數達成一致
關閉命令：ssl renegotiation disable
遠端rsh 服務允許部分用戶登錄。需要禁止rsh 服務 。
方法：
cat /.rhosts 查看是否有 + 號，意思是允許所有其他機器訪問。 我們主要VI編輯將+去掉即可。（該配置文件，其做用就是控制訪問IP）
因為RSH服務不能控制入訪因此我們需要禁用內網所有主機的出訪服務
禁用RSH出訪服務 svcadm disable svc:/network/shell:default
禁用rlogin服務 svcadm disable svc:/network/login:rlogin
檢測到遠端rsh 服務正在運行中。禁用RSH 服務，改用SSH 代替 。
方法：
1、vi /.rhosts 去掉其中的+號
2、vi /etc/default/login
CONSOLE=/dev/console 將這一行#注釋掉。
因為RSH服務不能控制入訪因此我們需要禁用內網所有主機的出訪服務
3、禁用RSH出訪服務 svcadm disable svc:/network/shell:default
4、禁用rlogin服務 svcadm disable svc:/network/login:rlogin
SSL 3.0 POODLE攻擊信息泄露漏洞(CVE-2014-3566)
現場次漏洞只存在於伺服器，後又發現此漏洞依賴於伺服器的5989埠，可以在防火牆禁用此埠或殺掉此進程
方法一 編輯： vi /etc/sysconfig/iptables
添加：-A INPUT -p tcp --dport 5989 -j DROP
-A INPUT -p tcp --sport 5989 -j DROP
重啟網路服務：service iptables restart
方法二 根據netstat –tunlp|grep 5989 查找PID ，pwdxPID查看程序路徑，如沒問題則可以殺死此進程。
POODLE = Padding Oracle On Downgraded Legacy Encryption.是最新安全漏洞(CVE-2014-3566)的代號，俗稱「貴賓犬」漏洞。 此漏洞是針對 SSL 3.0中CBC模式加密演算法的一種padding oracle攻擊，可以讓攻擊者獲取 SSL 通信中的部分信息明文，如果將明文中的重要部分獲取了，比如cookie,session，則信息的安全出現了隱患。
從本質上說，這是 SSL 設計上的缺陷， SSL 先認證再加密是不安全的。
修復措施：
禁用sslv3協議
不同的web server不盡相同。這邊列舉主流的伺服器的禁用方式
Nginx伺服器：
注意：nginx和openssl套件版本過低可能會導致無法啟用新型加密套件和演算法，請升級最新版本。
（openssl1.0.1+版本支持TLS1.1和TLS1.2協議）
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL;
ssl_prefer_server_ciphers on;
apache伺服器：
注意：apache和openssl套件版本過低可能會導致無法啟用新型加密套件和演算法，請升級最新版本。
（openssl1.0.1+版本支持TLS1.1和TLS1.2協議）
apache2.X版本：
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL
SSLHonorCipherOrder on
Tomcat伺服器：
JDK版本過低也會帶來不安全漏洞，請升級JDK為最新版本。升級JDK風險請安按照系統升級風險酌情考慮。
（先備份再配置，低版本的配置後有啟動不了的風險，請升級tomcat和jdk版本，JDK1.7及以上支持TLS1.2協議）
maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
keystoreFile="keystore/domain.jks" keystorePass="證書密碼"
clientAuth="false" sslProtocol="TLS"
ciphers="TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
SSL_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA" />
使用apr的tomcat（windows環境路徑請使用「\」，證書文件是for apache壓縮包中的三個文件）
maxThreads="150"
protocol="org.apache.coyote.http11.Http11AprProtocol"
enableLookups="false" disableUploadTimeout="true"
acceptCount="100" scheme="https" secure="true"
SSLEnabled="true"
SSLProtocol="all -SSLv2 -SSLv3"
SSLCertificateFile="conf/domian.com.crt"
SSLCertificateKeyFile="conf/domian.com.key"
SSLCertificateChainFile="conf/root_bundle.crt"
SSLCipherSuite="ECDH:AESGCM:HIGH:!RC4:!DH:!MD5:!aNULL:!eNULL" />
Ⅳ 【深度知識】區塊鏈之加密原理圖示(加密,簽名)
先放一張以太坊的架構圖：
在學習的過程中主要是採用單個模塊了學習了解的，包括P2P,密碼學，網路，協議等。直接開始總結：
秘鑰分配問題也就是秘鑰的傳輸問題，如果對稱秘鑰，那麼只能在線下進行秘鑰的交換。如果在線上傳輸秘鑰，那就有可能被攔截。所以採用非對稱加密，兩把鑰匙，一把私鑰自留，一把公鑰公開。公鑰可以在網上傳輸。不用線下交易。保證數據的安全性。
如上圖，A節點發送數據到B節點，此時採用公鑰加密。A節點從自己的公鑰中獲取到B節點的公鑰對明文數據加密，得到密文發送給B節點。而B節點採用自己的私鑰解密。
2、無法解決消息篡改。
如上圖，A節點採用B的公鑰進行加密，然後將密文傳輸給B節點。B節點拿A節點的公鑰將密文解密。
1、由於A的公鑰是公開的，一旦網上黑客攔截消息，密文形同虛設。說白了，這種加密方式，只要攔截消息，就都能解開。
2、同樣存在無法確定消息來源的問題，和消息篡改的問題。
如上圖，A節點在發送數據前，先用B的公鑰加密，得到密文1，再用A的私鑰對密文1加密得到密文2。而B節點得到密文後，先用A的公鑰解密，得到密文1，之後用B的私鑰解密得到明文。
1、當網路上攔截到數據密文2時， 由於A的公鑰是公開的，故可以用A的公鑰對密文2解密，就得到了密文1。所以這樣看起來是雙重加密，其實最後一層的私鑰簽名是無效的。一般來講，我們都希望簽名是簽在最原始的數據上。如果簽名放在後面，由於公鑰是公開的，簽名就缺乏安全性。
2、存在性能問題，非對稱加密本身效率就很低下，還進行了兩次加密過程。
如上圖，A節點先用A的私鑰加密，之後用B的公鑰加密。B節點收到消息後，先採用B的私鑰解密，然後再利用A的公鑰解密。
1、當密文數據2被黑客攔截後，由於密文2隻能採用B的私鑰解密，而B的私鑰只有B節點有，其他人無法機密。故安全性最高。
2、當B節點解密得到密文1後， 只能採用A的公鑰來解密。而只有經過A的私鑰加密的數據才能用A的公鑰解密成功，A的私鑰只有A節點有，所以可以確定數據是由A節點傳輸過來的。
經兩次非對稱加密，性能問題比較嚴重。
基於以上篡改數據的問題，我們引入了消息認證。經過消息認證後的加密流程如下：
當A節點發送消息前，先對明文數據做一次散列計算。得到一個摘要, 之後將照耀與原始數據同時發送給B節點。當B節點接收到消息後，對消息解密。解析出其中的散列摘要和原始數據，然後再對原始數據進行一次同樣的散列計算得到摘要1, 比較摘要與摘要1。如果相同則未被篡改，如果不同則表示已經被篡改。
在傳輸過程中，密文2隻要被篡改，最後導致的hash與hash1就會產生不同。
無法解決簽名問題，也就是雙方相互攻擊。A對於自己發送的消息始終不承認。比如A對B發送了一條錯誤消息，導致B有損失。但A抵賴不是自己發送的。
在(三)的過程中，沒有辦法解決交互雙方相互攻擊。什麼意思呢？ 有可能是因為A發送的消息，對A節點不利，後來A就抵賴這消息不是它發送的。
為了解決這個問題，故引入了簽名。這里我們將(二)-4中的加密方式，與消息簽名合並設計在一起。
在上圖中，我們利用A節點的私鑰對其發送的摘要信息進行簽名，然後將簽名+原文，再利用B的公鑰進行加密。而B得到密文後，先用B的私鑰解密，然後 對摘要再用A的公鑰解密，只有比較兩次摘要的內容是否相同。這既避免了防篡改問題，有規避了雙方攻擊問題。因為A對信息進行了簽名，故是無法抵賴的。
為了解決非對稱加密數據時的性能問題，故往往採用混合加密。這里就需要引入對稱加密，如下圖:
在對數據加密時，我們採用了雙方共享的對稱秘鑰來加密。而對稱秘鑰盡量不要在網路上傳輸，以免丟失。這里的共享對稱秘鑰是根據自己的私鑰和對方的公鑰計算出的，然後適用對稱秘鑰對數據加密。而對方接收到數據時，也計算出對稱秘鑰然後對密文解密。
以上這種對稱秘鑰是不安全的，因為A的私鑰和B的公鑰一般短期內固定，所以共享對稱秘鑰也是固定不變的。為了增強安全性，最好的方式是每次交互都生成一個臨時的共享對稱秘鑰。那麼如何才能在每次交互過程中生成一個隨機的對稱秘鑰，且不需要傳輸呢？
那麼如何生成隨機的共享秘鑰進行加密呢？
對於發送方A節點，在每次發送時，都生成一個臨時非對稱秘鑰對，然後根據B節點的公鑰 和 臨時的非對稱私鑰 可以計算出一個對稱秘鑰(KA演算法-Key Agreement)。然後利用該對稱秘鑰對數據進行加密，針對共享秘鑰這里的流程如下：
對於B節點，當接收到傳輸過來的數據時，解析出其中A節點的隨機公鑰，之後利用A節點的隨機公鑰 與 B節點自身的私鑰 計算出對稱秘鑰(KA演算法)。之後利用對稱秘鑰機密數據。
對於以上加密方式，其實仍然存在很多問題，比如如何避免重放攻擊(在消息中加入 Nonce )，再比如彩虹表(參考 KDF機制解決 )之類的問題。由於時間及能力有限，故暫時忽略。
那麼究竟應該採用何種加密呢？
主要還是基於要傳輸的數據的安全等級來考量。不重要的數據其實做好認證和簽名就可以，但是很重要的數據就需要採用安全等級比較高的加密方案了。
密碼套件 是一個網路協議的概念。其中主要包括身份認證、加密、消息認證(MAC)、秘鑰交換的演算法組成。
在整個網路的傳輸過程中，根據密碼套件主要分如下幾大類演算法：
秘鑰交換演算法：比如ECDHE、RSA。主要用於客戶端和服務端握手時如何進行身份驗證。
消息認證演算法：比如SHA1、SHA2、SHA3。主要用於消息摘要。
批量加密演算法：比如AES, 主要用於加密信息流。
偽隨機數演算法：例如TLS 1.2的偽隨機函數使用MAC演算法的散列函數來創建一個 主密鑰 ——連接雙方共享的一個48位元組的私鑰。主密鑰在創建會話密鑰（例如創建MAC）時作為一個熵來源。
在網路中，一次消息的傳輸一般需要在如下4個階段分別進行加密，才能保證消息安全、可靠的傳輸。
握手/網路協商階段：
在雙方進行握手階段，需要進行鏈接的協商。主要的加密演算法包括RSA、DH、ECDH等
身份認證階段：
身份認證階段，需要確定發送的消息的來源來源。主要採用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA簽名)等。
消息加密階段：
消息加密指對發送的信息流進行加密。主要採用的加密方式包括DES、RC4、AES等。
消息身份認證階段/防篡改階段：
主要是保證消息在傳輸過程中確保沒有被篡改過。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC ：Elliptic Curves Cryptography，橢圓曲線密碼編碼學。是一種根據橢圓上點倍積生成 公鑰、私鑰的演算法。用於生成公私秘鑰。
ECDSA ：用於數字簽名,是一種數字簽名演算法。一種有效的數字簽名使接收者有理由相信消息是由已知的發送者創建的，從而發送者不能否認已經發送了消息(身份驗證和不可否認)，並且消息在運輸過程中沒有改變。ECDSA簽名演算法是ECC與DSA的結合，整個簽名過程與DSA類似，所不一樣的是簽名中採取的演算法為ECC，最後簽名出來的值也是分為r,s。 主要用於身份認證階段 。
ECDH ：也是基於ECC演算法的霍夫曼樹秘鑰，通過ECDH，雙方可以在不共享任何秘密的前提下協商出一個共享秘密，並且是這種共享秘鑰是為當前的通信暫時性的隨機生成的，通信一旦中斷秘鑰就消失。 主要用於握手磋商階段。
ECIES： 是一種集成加密方案,也可稱為一種混合加密方案，它提供了對所選擇的明文和選擇的密碼文本攻擊的語義安全性。ECIES可以使用不同類型的函數：秘鑰協商函數(KA)，秘鑰推導函數(KDF)，對稱加密方案(ENC)，哈希函數(HASH), H-MAC函數(MAC)。
ECC 是橢圓加密演算法，主要講述了按照公私鑰怎麼在橢圓上產生，並且不可逆。 ECDSA 則主要是採用ECC演算法怎麼來做簽名， ECDH 則是採用ECC演算法怎麼生成對稱秘鑰。以上三者都是對ECC加密演算法的應用。而現實場景中，我們往往會採用混合加密(對稱加密，非對稱加密結合使用，簽名技術等一起使用)。 ECIES 就是底層利用ECC演算法提供的一套集成(混合)加密方案。其中包括了非對稱加密，對稱加密和簽名的功能。
<meta charset="utf-8">
這個先訂條件是為了保證曲線不包含奇點。
所以，隨著曲線參數a和b的不斷變化，曲線也呈現出了不同的形狀。比如:
所有的非對稱加密的基本原理基本都是基於一個公式 K = k G。其中K代表公鑰，k代表私鑰，G代表某一個選取的基點。非對稱加密的演算法 就是要保證 該公式 不可進行逆運算( 也就是說G/K是無法計算的 )。 *
ECC是如何計算出公私鑰呢？這里我按照我自己的理解來描述。
我理解，ECC的核心思想就是：選擇曲線上的一個基點G，之後隨機在ECC曲線上取一個點k(作為私鑰)，然後根據k G計算出我們的公鑰K。並且保證公鑰K也要在曲線上。*
那麼k G怎麼計算呢？如何計算k G才能保證最後的結果不可逆呢？這就是ECC演算法要解決的。
首先，我們先隨便選擇一條ECC曲線，a = -3, b = 7 得到如下曲線：
在這個曲線上，我隨機選取兩個點，這兩個點的乘法怎麼算呢？我們可以簡化下問題，乘法是都可以用加法表示的，比如2 2 = 2+2，3 5 = 5+5+5。 那麼我們只要能在曲線上計算出加法，理論上就能算乘法。所以，只要能在這個曲線上進行加法計算，理論上就可以來計算乘法，理論上也就可以計算k*G這種表達式的值。
曲線上兩點的加法又怎麼算呢？這里ECC為了保證不可逆性，在曲線上自定義了加法體系。
現實中，1+1=2，2+2=4，但在ECC演算法里，我們理解的這種加法體系是不可能。故需要自定義一套適用於該曲線的加法體系。
ECC定義，在圖形中隨機找一條直線，與ECC曲線相交於三個點(也有可能是兩個點)，這三點分別是P、Q、R。
那麼P+Q+R = 0。其中0 不是坐標軸上的0點，而是ECC中的無窮遠點。也就是說定義了無窮遠點為0點。
同樣，我們就能得出 P+Q = -R。 由於R 與-R是關於X軸對稱的，所以我們就能在曲線上找到其坐標。
P+R+Q = 0, 故P+R = -Q , 如上圖。
以上就描述了ECC曲線的世界裡是如何進行加法運算的。
從上圖可看出，直線與曲線只有兩個交點，也就是說 直線是曲線的切線。此時P,R 重合了。
也就是P = R, 根據上述ECC的加法體系，P+R+Q = 0, 就可以得出 P+R+Q = 2P+Q = 2R+Q=0
於是乎得到 2 P = -Q (是不是與我們非對稱演算法的公式 K = k G 越來越近了)。
於是我們得出一個結論，可以算乘法，不過只有在切點的時候才能算乘法，而且只能算2的乘法。
假若 2 可以變成任意個數進行想乘，那麼就能代表在ECC曲線里可以進行乘法運算，那麼ECC演算法就能滿足非對稱加密演算法的要求了。
那麼我們是不是可以隨機任何一個數的乘法都可以算呢？ 答案是肯定的。 也就是點倍積 計算方式。
選一個隨機數 k, 那麼k * P等於多少呢？
我們知道在計算機的世界裡，所有的都是二進制的，ECC既然能算2的乘法，那麼我們可以將隨機數k描 述成二進制然後計算。假若k = 151 = 10010111
由於2 P = -Q 所以 這樣就計算出了k P。 這就是點倍積演算法 。所以在ECC的曲線體系下是可以來計算乘法，那麼以為這非對稱加密的方式是可行的。
至於為什麼這樣計算 是不可逆的。這需要大量的推演，我也不了解。但是我覺得可以這樣理解：
我們的手錶上，一般都有時間刻度。現在如果把1990年01月01日0點0分0秒作為起始點，如果告訴你至起始點為止時間流逝了 整1年，那麼我們是可以計算出現在的時間的，也就是能在手錶上將時分秒指針應該指向00：00：00。但是反過來，我說現在手錶上的時分秒指針指向了00：00：00,你能告訴我至起始點算過了有幾年了么？
ECDSA簽名演算法和其他DSA、RSA基本相似，都是採用私鑰簽名，公鑰驗證。只不過演算法體系採用的是ECC的演算法。交互的雙方要採用同一套參數體系。簽名原理如下：
在曲線上選取一個無窮遠點為基點 G = (x,y)。隨機在曲線上取一點k 作為私鑰， K = k*G 計算出公鑰。
簽名過程：
生成隨機數R, 計算出RG.
根據隨機數R,消息M的HASH值H,以及私鑰k, 計算出簽名S = (H+kx)/R.
將消息M,RG,S發送給接收方。
簽名驗證過程：
接收到消息M, RG,S
根據消息計算出HASH值H
根據發送方的公鑰K,計算 HG/S + xK/S, 將計算的結果與 RG比較。如果相等則驗證成功。
公式推論：
HG/S + xK/S = HG/S + x(kG)/S = (H+xk)/GS = RG
在介紹原理前，說明一下ECC是滿足結合律和交換律的，也就是說A+B+C = A+C+B = (A+C)+B。
這里舉一個WIKI上的例子說明如何生成共享秘鑰，也可以參考 Alice And Bob 的例子。
Alice 與Bob 要進行通信，雙方前提都是基於 同一參數體系的ECC生成的 公鑰和私鑰。所以有ECC有共同的基點G。
生成秘鑰階段：
Alice 採用公鑰演算法 KA = ka * G ，生成了公鑰KA和私鑰ka, 並公開公鑰KA。
Bob 採用公鑰演算法 KB = kb * G ，生成了公鑰KB和私鑰 kb, 並公開公鑰KB。
計算ECDH階段：
Alice 利用計算公式 Q = ka * KB 計算出一個秘鑰Q。
Bob 利用計算公式 Q' = kb * KA 計算出一個秘鑰Q'。
共享秘鑰驗證：
Q = ka KB = ka * kb * G = ka * G * kb = KA * kb = kb * KA = Q'
故 雙方分別計算出的共享秘鑰不需要進行公開就可採用Q進行加密。我們將Q稱為共享秘鑰。
在以太坊中，採用的ECIEC的加密套件中的其他內容：
1、其中HASH演算法採用的是最安全的SHA3演算法 Keccak 。
2、簽名演算法採用的是 ECDSA
3、認證方式採用的是 H-MAC
4、ECC的參數體系採用了secp256k1, 其他參數體系 參考這里
H-MAC 全程叫做 Hash-based Message Authentication Code. 其模型如下：
在 以太坊 的 UDP通信時(RPC通信加密方式不同)，則採用了以上的實現方式，並擴展化了。
首先，以太坊的UDP通信的結構如下：
其中，sig是 經過 私鑰加密的簽名信息。mac是可以理解為整個消息的摘要， ptype是消息的事件類型，data則是經過RLP編碼後的傳輸數據。
其UDP的整個的加密，認證，簽名模型如下：
Ⅵ 溫故而知新之HTTPS
對於HTTPS其實很早之前就有過學習，但對其一直是一知半解，知道的並不深入全面，因此用了些時間，好好地閱讀了極客時間關於HTTPS的一些專欄，並總結一下嘗試著用自己的話來描述一下。
HTTP最初的目的：傳輸超文本文件，因此一直是明文傳輸文件，而且不安全。由於是明文傳輸，所以就很容易被中間人所截取，一切通信的內容也被這個中間人所掌握。這也就是常說的中間人攻擊。
那如何定義通信過程是安全的呢：機密性，完整性，身份驗證以及不可否認：
機密性：簡單來說就是數據是加密過的，除了參與通信之外的人都是都是看不了的。
完整性：數據在通信的過程中是完整的，沒加經過篡改的。
身份認證：通信雙方可以驗證對方的真實身份
不可否認：不能否認已經發生過的行為
因為是明文傳輸，所以在一些對安全要求高的場景就不能很好的滿足需求，因此在原有的基礎上引入了加密方案，在TCP和HTTP之間加入了一個安全層SSL/TLS
SSL全名叫Secure Sockets Layer中文名叫 安全套接層，在 OSI 模型中儲運第五層會話層的位置。這玩意兒是由網景公司所發明，並在其發展到 V3 的時候被 IETF 改名為 TLC（Transport Layer Security），並對其進行標准化。而 TLS 發展到現在也經歷了三個版本，最新的版本是2018年所制定的，牢牢的將密碼學的發展與當今互聯網的現狀相結合，持續提高安全與性能，因此也成為信息安全領域的權威標准。
而它的職責也很簡單：
當瀏覽器客戶端和服務端在使用 TLS 進行通信時，需要選擇一組合理的加密演算法來實現安全通信，而這些演算法的組合通常被稱為：加密套件。它的命名是很規范的，基本形式就是：密鑰交換演算法 + 簽名演算法 + 對稱加密演算法 + 摘要演算法。其中，簽名演算法可以進行身份驗證，摘要演算法可以保證數據的完整性，而對稱加密演算法則可以保證數據的機密性。（值得注意的是，在2019年不安全的 TLS 1.0 和 1.1 默認被禁用（ Safari TP 91 、Google Chrome 72+、Firefox Nightly）
前面我們提到，HTTP協議在進行傳輸的時候是通過明文進行傳輸的，因此不安全。那麼如果需要保證傳輸信息的機密性，最簡單的方法不外於將其進行加密，這樣第三方的人在拿到這些信息的時候，也就不能獲取信息裡面的內容了。因此這就引入了加密的第一個概念：對稱加密。
對稱加密其實很簡單：加密和解密都使用的是相同的密鑰，是對稱的，這里的密鑰就是用於解開加密信息的鑰匙。
簡單來說就是客戶端會給服務端發送它支持的加密的方法的列表，以及一個隨機數，然後伺服器端在接受到這些東西後，會從客戶端所支持的加密方法列表中選取一種，然後同時生成一個隨機數給客戶端，這樣兩端就都確定了加密方法和隨機數，也就可以通過這些信息來生成對應的密鑰了。這樣做的話即使黑客在獲取到瀏覽器與伺服器所傳輸的信息，得到的也只是一串亂碼，而他也沒有相應的密鑰，也就保證了信息傳輸的機密性。
TLS中所提供的對稱加密演算法有很多，其中最常用的當屬 AES（Advanced Encryption Standard）既高級加密標准，密鑰的長度可以是128，192，256，是當今用的最為廣泛的對稱加密演算法。當然除了上面這個AES之外，我們國家也存在這自己的一套對稱加密演算法：SM1 和 SM4。其中SM1演算法不公開，屬於國家機密，而 SM4 則是公開的，可以自行使用，這兩個演算法的最大的優勢就在於：國家支持！
對稱加密還有一個分組的概念，他可以讓演算法用固定的長度的密鑰加密任意長度的明文，從而將密鑰轉化為密文。最新的分組模式叫做AEAD，在加密的同時還增加了認證的功能。
對稱加密就是通過上面的這些東西，來完成一個簡單卻安全的加密方式的。
對稱加密看起來的確是解決了我們所說的安全要素中的機密性的要求，但它仍然存在一個致命的漏洞就是：密鑰交互的方式仍然是明文的。也正是為了解決密鑰安全的問題，我們就需要使用非堆成加密的方法，那什麼是非堆成加密呢？非對稱加密簡單來說就是有兩把私鑰，一把是公鑰，可以公開給任何人使用，一把是私鑰，需要嚴格保密。這就形成了一個非對稱性。具體舉個栗子來講就是：有 A、B 兩把密鑰，如果你用 A 密鑰來加密，那麼只能使用 B 密鑰來解密；反過來，如果你要 B 密鑰來加密，那麼只能用 A 密鑰來解密。
非對稱加密除了可以對信息進行加密外，很多非對稱加密演算法還有簽名的功能，這樣就可以提供身份認證，保證通信雙方可以確定對面的身份。
而從實現上來講，所有的非對稱加密演算法，都是基於各種數學難題來設計實現的，這些難題的特點在於：正向計算很簡單，反向推倒是無解的。其中比較經典的非對稱加密演算法包括：RSA，ECC以及SM2。
RSA 是所使用的數學難題是：兩個大的質數相乘的結果很容易計算，但根據這個結果去做質因分解得到原先的兩個質數，則需要很大的計算量。就比如這個：
https://lists.gforge.inria.fr/pipermail/cado-nfs-discuss/2019-December/001139.html 。
前段時間美國一群大佬宣布，240哥十進制的整數分解成功，找到了它的兩個大質數因子，不過這個成本也是很大的。
ECC和 SM2 都是是基於橢圓曲線的數學難題設計的。普遍的觀點認為，橢圓曲線的難度高於大質數難題，160 位密鑰的 ECC 加密強度，相當於 1088 位密鑰的 RSA。因為密鑰短，所以相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了，因此對於互聯網行業來講吸引力也是相當大的。而SM2除了加密強度和國際標准和ECC差不多以外，還屬於國家所支持的非對稱加密演算法。
需要注意的是，非對稱加密的安全性上雖然可以滿足我們的需求，但它卻存在這一個比較大的問題就是L：性能。由於非對稱加密在所需要的演算法運算非常復雜，因此在性能上得不到很好的保證。也正是由於這個原因，現在的TLS主要採用的是一種叫混合加密的方式來進行加密。
混合加密其實很簡單，就是使用非對稱加密的方式，解決密鑰交換的問題，然後用隨機數產生對稱演算法使用的會話密鑰，在對其使用公鑰加密，並傳送給通信對象。通信對象拿到密文後用私鑰解開並取出會話密鑰。這樣就是實現了堆成密鑰的安全交換了，後續就可以使用這個對稱密鑰來進行對稱加密。
在前面我們有提到過安全的幾大要素，其中機密性我們可以通過上面的對稱加密 + 非對稱加密來解決。而在完整性方面，我們則需要使用摘要演算法來解決。
簡單理解，我們可以將摘要演算法理解為一種特殊的壓縮演算法，他可以將任意長度的數據壓縮成固定長度且獨一無二的摘要字元串，且這個加密的過程也是單向的，加密後的數據無法解密，不能從摘要中反向推出原文。
https://time.geekbang.org/column/article/176569
https://time.geekbang.org/column/intro/189 ——安全篇