❶ 什麼是主密鑰，有什麼特點
主密鑰是在一對用戶之間的長期共享的秘密密鑰，它往往作為生成會話密鑰或密鑰加密密鑰的種子，實現這些密鑰的分發和安全保護。而主密鑰的分發則一般使用離線安全物理通道完成。
❷ 不同文檔採用不同密鑰加密保護,如何區分哪個密鑰解密
有以下的幾種方式，希望可以幫助到你：
1.基本密鑰
基本密鑰也稱為初始密鑰,通過用戶選定或系統分配,大多數用密鑰演算法實現。基本密鑰的使用期限一般比較長,可為數月、半年或一年等。一般用基本密鑰來啟動與控制系統的密鑰生成器,產生一次通信過程使用的會話密鑰。
2.會話密鑰
2個通信終端用戶在通信過程中用的密鑰叫做會話密鑰。會話密鑰如果用於保護傳輸的數據,則叫做數據加密密鑰;若用來對傳輸的文件進行保護,則稱為文件加密密鑰。使用會話密鑰可不用太頻繁地更換基本密鑰,又由於會話密鑰大多是臨時的、動態的,且使用的時間較短,這樣就限制了攻擊者能截獲的同一密鑰加密的密文量,進而加大了密碼分析的難度,有助於密鑰的安全與管理。
3.密鑰加密密鑰
用來對要傳送的會話密鑰等其他密鑰加密的密鑰叫密鑰加密密鑰,也叫次主密鑰或二級密鑰。通信網中的每個節點均需配備這樣的密鑰,且各節點的密鑰加密密鑰均不同,在主機與主機之間以及主機與各終端之間傳送會話密鑰時,都需要有相應的密鑰加密密鑰來保護。
4.主密鑰
主密鑰是對密鑰加密密鑰實施加密的一種密鑰,主密鑰通常被嚴格保護,保存於網路中心、主節點和主處理機中。它通常用手工分配,或是在初始階段通過過程式控制制在物理或電子隔離情況下安裝。
❸ 什麼是會話密鑰
主密鑰（master?key）是被客戶機和伺服器用於產生會話密鑰的一個密鑰。這個主密鑰被用於產生客戶端讀密鑰，客戶端寫密鑰，伺服器讀密鑰，伺服器寫密鑰。主密鑰能夠被作為一個簡單密鑰塊輸出
會話密鑰是指：當兩個端系統希望通信，他們建立一條邏輯連接。在邏輯連接持續過程中，所以用戶數據都使用一個一次性的會話密鑰加密。在會話和連接結束時，會話密鑰被銷毀。
❹ 密碼學筆記
別人用A的公鑰加密傳輸的信息，只有A的私鑰可以解密。保證了傳輸的信息的安全性。
A用A的私鑰加密的信息，別人用A的公鑰才可以解密。可以證明這個信息一定是A傳輸而來的。
共享秘鑰（對稱加密）：速度快，但無法保證客戶端與伺服器之間傳輸時秘鑰的安全性。
和公開密鑰（非對稱加密）：安全，速度慢。
一、客戶端請求SSL（安全套接層）通信，報文中包含自己支持的SSL版本、加密演算法等。
二、伺服器應答，附帶自己的公鑰證書，協商定好的SSL版本、加密組件。
三、客戶端根據自己本地的收信任的CA公鑰，解封伺服器公鑰證書，得到伺服器公鑰。客戶端生成一個隨機碼序列，用伺服器公鑰加密後，發回伺服器。
四、伺服器用私鑰解密後，再加密將字元串傳回客戶端。
五、客戶端確認伺服器身份後，生成對稱加密演算法和共享秘鑰，使用伺服器公鑰加密後，傳給伺服器。
六、此後，雙方使用對稱加密演算法加密數據，進行傳輸。
上面過程中，一二用於獲得合法的伺服器公鑰，三四用於確認伺服器是否為真正私鑰持有者（因為，伺服器公鑰誰都可以得到）。
使用與明文比特序列一樣長的，真正的隨機數序列，進行加密，絕對安全，因為窮舉破譯後能得到整個秘鑰空間，毫無意義。
以分組為單位進行處理的密碼演算法稱為 分組密碼。
採用 Feistel網路。
以 64 bit 為一個加密單位，首先分成兩部分，各32 bit 。
加密過程持續數輪，每輪中，使用子秘鑰與右側數據經過輪函數生成一個序列，然後與左側做 XOR 。
每輪結束後，左右兩側交換。
加解密結構相同，輪數任意，函數任意。
使用秘鑰1、2、3對明文進行加密、解密、加密三個過程，稱為三重DES。
解密過程是為了兼容老版DES，如果1、2、3秘鑰相同，則成為了普通DES。
1、3秘鑰相同，2不同時，稱為DES-EDE2 。
1、2、3秘鑰不同，稱為DES-EDE3 。
採用的是 Rijndael 演算法，SPN結構。
輸入分組為 128bit（16位元組），秘鑰長度可以以 32bit 為單位，在128~256bit之間選擇。
該演算法由多輪構成，10~14輪。
一輪中：
SubBytes，按位元組，將輸入分開，以每個位元組為索引，查表找值，替換。
ShiftRows（平移行），按位元組，打亂上面的輸出。
MixColumns （混合列），按4個位元組，比特運算。
與輪秘鑰進行 XOR 。
分組密碼：每次處理，特定長度的一塊數據。
流密碼：對數據流，連續處理，需要保持內部狀態，記錄進度。
明文分組加密後，直接成為，密文分組。
特點：攻擊者無需破譯，即可操縱明文。
明文分組，與前一個密文分組XOR，加密得到自己的密文分組。
第一個分組的前一個密文分組，由 初始化向量（隨機比特序列） 代替。
加密時，需要從頭開始。因為需要與密文分組做 XOR 。
解密時，對密文分組解密，直接與密文分組 XOR 即可。
同樣的明文分組，密文值可以不相等。
密文分組可以損壞，影響部分。
密文分組比特缺失，影響全部。
前一個密文分組，通過加密演算法得到一個比特序列，稱為 密鑰流 。
明文分組，與密鑰流 XOR，得到自己的密文分組。
解密時，加密演算法對密文分組進行加密，得到密鑰流，與密文 XOR 可得到明文。
重復攻擊：假設秘鑰相同。發送 4 個分組，攻擊者保存了後面3個。轉天，你又發送了 4 個分組，攻擊者將你後面三個替換，接收方解密後，只有 2 號分組有錯。
對於每個分組，初始化向量加密後，得到密鑰流。明文與密鑰流 XOR 後，得到密文。
速度快，密鑰流可以提前生成，或者，生成秘鑰過程可以和 XOR 運算並行。
對每個計數器加密得到密鑰流。密鑰流與明文分組 XOR ，得到密文分組。
計數器生成的數，由 一個隨機序列 nonce + 從1開始的遞增數字 組成。
對每個分組，計數器遞增後，加密，得到密鑰流。
能夠以任意順序處理分組，因為加密時需要的初始數字序列能夠計算出來。
為了確保安全，有地理局限，與不同的人通信需要不同密鑰，共享繁瑣。
每個員工有自己的密鑰，密鑰分配中心使用個人密鑰，包裹臨時會話密鑰，分配給各個員工使用。
密文=明文的E次方 MOD N
E 和 N 是RSA加密用的密鑰，也就是說，E 和 N 的組合就是公鑰。
明文=密文的D次方 MOD N
D 和 N 的組合就是私鑰。
尋兩個很大的質數 p 和 q，相乘得到 N
L為 p-1 和 q-1 的最小公倍數
隨機數生成器，不停地生成數字，直到滿足如下條件：
1 < E < L
E 和 L 的最大公約數為 1
根據 E ，計算 D
1 < E < L
E × D MOD L = 1
保證 E 與 L 互質，則 D 一定存在。
求對數很容易，求 離散對數 很困難
對一個大數字進行質因數分解，人類未找到高效演算法
利用了 MOD N下，求離散對數的困難度
加密後，密文長度翻倍
利用了 MOD N下，求平方根的困難度
密碼實現通過 對橢圓曲線上的特定點進行特殊乘法。
利用了該種乘法的逆運算非常困難這一特性
單向散列函數 又稱為，消息摘要函數、哈希函數、雜湊函數
輸入的消息 又稱為，原像
散列值 又稱為，消息摘要、指紋
完整性 又稱為，一致性
根據任意消息，計算出的散列值長度，固定
用時短
消息不同，散列值不同
具備單向性
MD是消息摘要的意思
可以產生 128bit 的散列值，但它們的抗碰撞性已被攻破
SHA-1散列值長度為 160bit，強碰撞性已被攻破
其餘的統稱為 SHA-2，散列值長度為各自後面的數字
歐盟版本
第三代 SHA
消息上限 2^64 bit。
消息長度需要是 512bit 的整數倍。這樣的 512比特 稱為一個輸入分組。
過程：
消息末尾添加 1
然後添加 0，直到最後一個分組的 448比特 的位置
最後 64比特 需要保存原是消息的長度
對每個分組計算 80 個 32bit 的值。
過程：
將 512bit 分成 32bit × 16組，稱為 W0~W15
從15組中按規律取4組，進行 XOR 運算，結果循環左移 1 位，得到另外一組。如此反復，得到總共 80 組。
ABCDE 五個 32bit 的緩沖區，保存了 160bit 的消息內部狀態。
內部狀態與每個 512bit 的輸入分組混合，一共 80 個步驟。
最終得到 160bit 的最終內部狀態。
暴力破解：暴力尋找與 1億元合同 散列值相同的文件
生日攻擊：准備兩份 散列值相同的 1億元合同
可以辨別 篡改，無法辨別 偽裝，因此還需要 認證技術
認證技術包括 消息驗證碼 和 數字簽名
消息驗證碼：可以向通信對象保證消息不被篡改
數字簽名：可以向任何人保證通信對象不被篡改
message authentication code，簡稱 MAC。
相當於 使用共享密鑰的單向散列函數
SWIFT：負責銀行間的交易，公鑰密碼使用前，都是人工配送密鑰的。
IPsec：對IP協議增加安全性，採用的是消息認證碼
SSL/TLS：網上購物等場景中所用協議。
過程：
密鑰填充 至單向散列函數要求的輸入分組大小
填充後的密鑰 與 ipad（16進制的36不斷循環）XOR，得到ipadkey
與 消息 組合，計算散列值
填充後的密鑰 與 opad（16進制的5C不斷循環）XOR，得到opadkey
與 上面得到的散列值 組合，計算新的散列值，為最終的MAC值
對第三方證明
防止否認
因為知曉密鑰的只有兩個當事人，第三者無法確定能拿到合法的密鑰，無法自己計算合法MAC值
RSA：利用質因數分解難度的那個
ElGamal：利用求離散對數的困難度的那個，數字簽名有漏洞，現僅用於公鑰密碼
DSA：Schnorr演算法與ElGamal方式的變體，只能用於數字簽名
Rabin：利用了求MOD N中平方根的困難度，可用於數字簽名和公鑰密碼
例如，verisign公司的認證業務分為三個等級，等級越高，越嚴格
ITU 國際電信聯盟和 ISO 國際標准化組織制定的 X.509 規范如下
大體包含以下內容：
簽名前的證書——簽名對象的各種消息
數字簽名演算法——簽名時所用的演算法
數字簽名——得到的數字簽名
PKI ：為了能有效使用公鑰而制定的一系列規范和規格
PKI 的組成要素如下
兩種方法：一種是由認證機構生成，一種是由 PKI 用戶自行生成
認證機構有一個 CRL（認證作廢清單），具有數字簽名，記載了已經作廢的證書的編號。
認證時，從上（根證書）往下
對於密鑰，關鍵的是 密鑰空間的大小
DES 的密鑰 實質長度（即，除去校驗錯誤的比特後的長度）7位元組
DES-EDE2 的實質長度 14位元組，DES-EDE3 的實質長度 21位元組
AES 的密鑰長度可以從 128、192 和 256bit 當中選
會話密鑰：每次通信中，僅使用一次的密鑰
主密鑰：一直被重復使用的密鑰
CEK：Contents Encrypting Key
KEK: Key Encrypting Key
各個步驟中的密鑰管理方法
兩種方法：
用隨機數生成密鑰：使用具備不可預測性的偽隨機數生成器生成隨機數
用口令生成密鑰：一般使用，口令 + 一串稱為 salt 的隨機數，得到他們的散列值作為密鑰（這種方法稱為：基於口令的密碼）
事先共享
秘鑰分配中心
使用公鑰密鑰
Diffie-Hellman 密鑰交換
密鑰更新：一種提高通信機密性的技術
原理：
使用 共享密鑰 進行通信時，定期改變密鑰。
雙方使用同樣的方法，對當前密鑰求 散列值，並作為下一個密鑰
優點：
後向安全：防止破譯過去的內容
對密鑰進行加密，然後保存
意義：
同時對多個密鑰進行加密，可以減少保存密鑰的數量
步驟：
P 為非常大的質數，G 為 P 的 生成元
目的為，將 隨機數 A 的信息 含蓄地發給了 B
目的為，將 隨機數 B 的信息 含蓄地發給了 A
計算方法：密鑰 = （G ^ B MOD P) ^ A MOD P = G^(A × B) MOD P
計算方法：密鑰 = （G ^ A MOD P) ^ B MOD P = G^(A × B) MOD P
對於一個質數 P ，只有它的生成元在進行 G ^ x MOD P 時，結果能夠覆蓋 0 ~ P-1 的所有數字
用途：用於安全的保存密鑰
由來：
一 生成會話密鑰 CEK ，加密消息
二 需要保密 會話密鑰CEK，使用 密鑰加密密鑰KEK 對會話密鑰進行保密
三 現在需要保密 KEK 這個密鑰，選擇使用口令生成這個 KEK
保密的問題最終都歸結為了 安全保存密鑰，然而我們記不住密鑰。
於是，選擇單向散列函數對口令生成散列值，作為密鑰。
這個密鑰無需保存，我們可以通過口令隨時求得，口令也無法被反向推出，且口令方便記憶。
順帶，為了防止字典攻擊，生成口令散列值時，需要使用 口令 + salt（隨機數序列）
事先 已准備好 候選列表 的攻擊方法
隨機性
不可預測性
不可重見性
這三個性質，越往下越嚴格。分別稱為：
弱偽隨機數（不可用於密碼學）
強偽隨機數
真隨機數
偽隨機數生成器是公開的，種子是保密的。
確保種子的不可預測性，更加容易些。
種子是用來對偽隨機數生成器的 內部狀態進行初始化 的
R1 = （A × R0 + C) MOD M
數據有限，不能用於密碼學
單向散列函數的單向性是支撐偽隨機數序列不可預測性的基礎
利用 AES 等對稱密鑰對內部狀態進行加密
從當前時間開始，利用加密演算法 求得加密後的時間的掩碼 （因為密鑰未知，別人無法推測出掩碼信息）
與內部狀態 XOR，加密後輸出， 得到偽隨機數序列
對偽隨機數序列加密後，作為 下一個內部狀態
針對極端情況的密碼軟體，具有全部功能。
TLS 由 TLS 記錄協議 和 TLS 握手協議 疊加而成。
負責消息的 加密、壓縮 和 認證
商定 客戶端和伺服器 所用的加密演算法和密鑰
負責 傳遞 變更密碼的信號
發生錯誤時 通知對方
傳輸數據
❺ 如何保證錢包私鑰安全
對於數字貨幣錢包來說，它並不是裝錢的，而是裝密鑰的工具，准確來說，就是裝私鑰的工具。有了私鑰就可以擁有根據其對應公鑰計算出的地址上的數字貨幣的支配權。
作為錢包開發者，如何存儲和使用用戶私鑰便是錢包安全的關鍵所在。
下面是使用imToken錢包App創建錢包的截圖。從截圖上可以清楚的看到我們在錢包的時候需要輸入密碼來保護私鑰。那這個私鑰究竟是如何被保護的呢？私鑰的生成和輸入的密碼有沒有關系呢？
這里一般有兩種誤解：
如果錢包應用開發者真的這么做的話，估計大家每天都是排著隊丟幣了 :)。
你想啊，如果是第一種情況，那如果兩個人用同樣的密碼不就可以互相看到對方錢包了么。
如果是第二種情況，在你輸入密碼進入錢包應用後，私鑰就要被載入並駐留在內存里。你在網上搜一下「從內存提取密碼工具」，保證可以搜到一大把。另外一個風險是，用戶輸入的密碼都不是太長並且很多時候有規律可循，這樣當加密後的私鑰數據泄漏後，黑客通過暴力破解結合彩虹表等工具將私鑰破解的幾率還是比較高的。
事實上，私鑰的生成永遠和你輸入的密碼沒有半毛錢關系，要麼是隨機生成，要麼是根據助記符（一串隨機生成的英文或其它語言片語）生成，保證每個人的私鑰都是唯一的。
私鑰的加密過程一般來說是下面這樣的：
第一步：錢包應用會生成一個32位元組隨機數，我們稱之為主密鑰。
第二步：使用用戶輸入的密碼對主密鑰加密，生成主密鑰密文。
第三步：使用主密鑰對錢包私鑰進行加密，生成私鑰密文。
第四步：清除主密鑰和私鑰，保留主密鑰密文和私鑰密文。
你可以會有疑問，這樣黑客拿到密文後先暴力破解主密鑰，再破解私鑰不也很容易么？其實在具體實現的時候，每個密文在生成的時候不只是用輸入的密碼，還有相應的密文生成參數，想通過密文和密碼直接解密得到明文沒那麼容易的。
從上一部分的解釋我們知道，錢包應用里保存的是主密鑰密文和私鑰密文。
當我們登錄錢包後，錢包應用會通過我們輸入的密碼對主密鑰密文解密，將解密後的主密鑰駐留內存。
當我們進行轉賬等需要私鑰簽名的操作時，通過主密鑰解密私鑰密文得到私鑰，使用後立即將私鑰從內存清除。
當我們需要修改密碼時，實際上只是修改了主密鑰密文，並不會觸碰私鑰相關部分。
這樣，基本上將私鑰明文暴露的幾率降到最低，最大限度的保證私鑰的安全。
還有疑問？歡迎加入我的知識星球，盡我所能為你答疑解惑。
❻ 什麼是主密鑰
KDC和每個實體之間共享一個秘密密鑰，這個密鑰成為主密鑰。
❼ 對稱密碼管理中密鑰分為高級密鑰中級密鑰和初級密鑰對嗎
對稱密碼管理中密鑰分為高級密鑰、中級密鑰和初級密鑰，是不對的。
對稱密碼管理中密鑰分為初級密鑰、二級密鑰、三級密鑰、高級密鑰。
對稱密碼術早已被人們使用了數千年，它有各種形式從簡單的替換密碼到較復雜的構造方式。
❽ TLS 詳解
SSL (Secure Sockets Layer) 安全套接層，是一種安全協議，經歷了 SSL 1.0、2.0、3.0 版本後發展成了標准安全協議 - TLS (Transport Layer Security) 傳輸層安全性協議。TLS 有 1.0 (RFC 2246)、1.1(RFC 4346)、1.2(RFC 5246)、1.3(RFC 8446) 版本。
TLS 在實現上分為 記錄層 和 握手層 兩層，其中握手層又含四個子協議: 握手協議 (handshake protocol)、更改加密規范協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警告協議 (alert protocol)
只需配置瀏覽器和伺服器相關設置開啟 TLS，即可實現 HTTPS，TLS 高度解耦，可裝可卸，與上層高級應用層協議相互協作又相互獨立。
TLS/SSL 的功能實現主要依賴於三類基本演算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密演算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。
TLS 的基本工作方式是，客戶端使用非對稱加密與伺服器進行通信，實現身份驗證並協商對稱加密使用的密鑰，然後對稱加密演算法採用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間採用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。
例如，在 HTTPS 協議中，客戶端發出請求，服務端會將公鑰發給客戶端，客戶端驗證過後生成一個密鑰再用公鑰加密後發送給服務端（非對稱加密），雙方會在 TLS 握手過程中生成一個協商密鑰（對稱密鑰），成功後建立加密連接。通信過程中客戶端將請求數據用協商密鑰加密後發送，服務端也用協商密鑰解密，響應也用相同的協商密鑰。後續的通信使用對稱加密是因為對稱加解密快，而握手過程中非對稱加密可以保證加密的有效性，但是過程復雜，計算量相對來說也大。
記錄協議負責在傳輸連接上交換的所有底層消息，並且可以配置加密。每一條 TLS 記錄以一個短標頭開始。標頭包含記錄內容的類型 (或子協議)、協議版本和長度。原始消息經過分段 (或者合並)、壓縮、添加認證碼、加密轉為 TLS 記錄的數據部分。
記錄層將信息塊分割成攜帶 2^14 位元組 (16KB) 或更小塊的數據的 TLSPlaintext 記錄。
記錄協議傳輸由其他協議層提交給它的不透明數據緩沖區。如果緩沖區超過記錄的長度限制（2^14），記錄協議會將其切分成更小的片段。反過來也是可能的，屬於同一個子協議的小緩沖區也可以組合成一個單獨的記錄。
壓縮演算法將 TLSPlaintext 結構轉換為 TLSCompressed 結構。如果定義 CompressionMethod 為 null 表示不壓縮
流加密（BulkCipherAlgorithm）將 TLSCompressed.fragment 結構轉換為流 TLSCiphertext.fragment 結構
MAC 產生方法如下：
seq_num（記錄的序列號）、hash（SecurityParameters.mac_algorithm 指定的哈希演算法）
塊加密（如 RC2 或 DES），將 TLSCompressed.fragment 結構轉換為塊 TLSCiphertext.fragment 結構
padding: 添加的填充將明文長度強制為塊密碼塊長度的整數倍。填充可以是長達 255 位元組的任何長度，只要滿足 TLSCiphertext.length 是塊長度的整數倍。長度大於需要的值可以阻止基於分析交換信息長度的協議攻擊。填充數據向量中的每個 uint8 必須填入填充長度值 (即 padding_length)。
padding_length: 填充長度應該使得 GenericBlockCipher 結構的總大小是加密塊長度的倍數。合法值范圍從零到 255（含）。 該長度指定 padding_length 欄位本身除外的填充欄位的長度
加密塊的數據長度（TLSCiphertext.length）是 TLSCompressed.length，CipherSpec.hash_size 和 padding_length 的總和加一
加密和 MAC 功能將 TLSCompressed 結構轉換為 TLSCiphertext。記錄的 MAC 還包括序列號，以便可以檢測到丟失，額外或重復的消息。
記錄協議需要一種演算法，從握手協議提供的安全性參數生成密鑰、 IV 和 MAC secret.
主密鑰 (Master secret): 在連接中雙方共享的一個 48 位元組的密鑰
客戶隨機數 (client random): 由客戶端提供的 32 位元組值
伺服器隨機數 (server random): 由伺服器提供的 32 位元組值
握手是 TLS 協議中最精密復雜的部分。在這個過程中，通信雙方協商連接參數，並且完成身 份驗證。根據使用的功能的不同，整個過程通常需要交換 6~10 條消息。根據配置和支持的協議擴展的不同，交換過程可能有許多變種。在使用中經常可以觀察到以下三種流程：(1) 完整的握手， 對伺服器進行身份驗證；(2) 恢復之前的會話採用的簡短握手；(3) 對客戶端和伺服器都進行身份驗證的握手。
握手協議消息的標頭信息包含消息類型（1 位元組）和長度（3 位元組），餘下的信息則取決於消息類型：
每一個 TLS 連接都會以握手開始。如果客戶端此前並未與伺服器建立會話，那麼雙方會執行一次完整的握手流程來協商 TLS 會話。握手過程中，客戶端和伺服器將進行以下四個主要步驟:
下面介紹最常見的握手規則，一種不需要驗證客戶端身份但需要驗證伺服器身份的握手:
這條消息將客戶端的功能和首選項傳送給伺服器。
是將伺服器選擇的連接參數傳回客戶端。
這個消息的結構與 ClientHello 類似，只是每個欄位只包含一個選項，其中包含服務端的 random_S 參數 (用於後續的密鑰協商)。伺服器無需支持客戶端支持的最佳版本。如果伺服器不支持與客戶端相同的版本，可以提供某個其他版本以期待客戶端能夠接受
圖中的 Cipher Suite 是後續密鑰協商和身份驗證要用的加密套件，此處選擇的密鑰交換與簽名演算法是 ECDHE_RSA，對稱加密演算法是 AES-GCM，後面會講到這個
還有一點默認情況下 TLS 壓縮都是關閉的，因為 CRIME 攻擊會利用 TLS 壓縮恢復加密認證 cookie，實現會話劫持，而且一般配置 gzip 等內容壓縮後再壓縮 TLS 分片效益不大又額外佔用資源，所以一般都關閉 TLS 壓縮
典型的 Certificate 消息用於攜帶伺服器 X.509 證書鏈 。
伺服器必須保證它發送的證書與選擇的演算法套件一致。比方說，公鑰演算法與套件中使用的必須匹配。除此以外，一些密鑰交換演算法依賴嵌入證書的特定數據，而且要求證書必須以客戶端支持的演算法簽名。所有這些都表明伺服器需要配置多個證書（每個證書可能會配備不同的證書鏈）。
Certificate 消息是可選的，因為並非所有套件都使用身份驗證，也並非所有身份驗證方法都需要證書。更進一步說，雖然消息默認使用 X.509 證書，但是也可以攜帶其他形式的標志；一些套件就依賴 PGP 密鑰
攜帶密鑰交換需要的額外數據。ServerKeyExchange 是可選的，消息內容對於不同的協商演算法套件會存在差異。部分場景下，比如使用 RSA 演算法時，伺服器不需要發送此消息。
ServerKeyExchange 僅在伺服器證書消息（也就是上述 Certificate 消息）不包含足夠的數據以允許客戶端交換預主密鑰（premaster secret）時才由伺服器發送。
比如基於 DH 演算法的握手過程中，需要單獨發送一條 ServerKeyExchange 消息帶上 DH 參數:
表明伺服器已經將所有預計的握手消息發送完畢。在此之後，伺服器會等待客戶端發送消息。
客戶端驗證證書的合法性，如果驗證通過才會進行後續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證內容包括如下:
由 PKI 體系 的內容可知，對端發來的證書簽名是 CA 私鑰加密的，接收到證書後，先讀取證書中的相關的明文信息，採用相同的散列函數計算得到信息摘要，然後利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性；然後去查詢證書的吊銷情況等
合法性驗證通過之後，客戶端計算產生隨機數字的預主密鑰（Pre-master），並用證書公鑰加密，發送給伺服器並攜帶客戶端為密鑰交換提供的所有信息。這個消息受協商的密碼套件的影響，內容隨著不同的協商密碼套件而不同。
此時客戶端已經獲取全部的計算協商密鑰需要的信息: 兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，然後得到協商密鑰(用於之後的消息加密)
圖中使用的是 ECDHE 演算法，ClientKeyExchange 傳遞的是 DH 演算法的客戶端參數，如果使用的是 RSA 演算法則此處應該傳遞加密的預主密鑰
通知伺服器後續的通信都採用協商的通信密鑰和加密演算法進行加密通信
Finished 消息意味著握手已經完成。消息內容將加密，以便雙方可以安全地交換驗證整個握手完整性所需的數據。
這個消息包含 verify_data 欄位，它的值是握手過程中所有消息的散列值。這些消息在連接兩端都按照各自所見的順序排列，並以協商得到的主密鑰 (enc_key) 計算散列。這個過程是通過一個偽隨機函數（pseudorandom function，PRF）來完成的，這個函數可以生成任意數量的偽隨機數據。
兩端的計算方法一致，但會使用不同的標簽（finished_label）：客戶端使用 client finished，而伺服器則使用 server finished。
因為 Finished 消息是加密的，並且它們的完整性由協商 MAC 演算法保證，所以主動網路攻擊者不能改變握手消息並對 vertify_data 的值造假。在 TLS 1.2 版本中，Finished 消息的長度默認是 12 位元組（96 位），並且允許密碼套件使用更長的長度。在此之前的版本，除了 SSL 3 使用 36 位元組的定長消息，其他版本都使用 12 位元組的定長消息。
伺服器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，同樣計算得到協商密鑰: enc_key = PRF(Pre_master, "master secret", random_C + random_S) ;
同樣計算之前所有收發信息的 hash 值，然後用協商密鑰解密客戶端發送的 verify_data_C，驗證消息正確性;
服務端驗證通過之後，伺服器同樣發送 change_cipher_spec 以告知客戶端後續的通信都採用協商的密鑰與演算法進行加密通信（圖中多了一步 New Session Ticket，此為會話票證，會在會話恢復中解釋）;
伺服器也結合所有當前的通信參數信息生成一段數據 (verify_data_S) 並採用協商密鑰 session secret (enc_key) 與演算法加密並發送到客戶端;
客戶端計算所有接收信息的 hash 值，並採用協商密鑰解密 verify_data_S，驗證伺服器發送的數據和密鑰，驗證通過則握手完成;
開始使用協商密鑰與演算法進行加密通信。
HTTPS 通過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能。加密過程中，需要用到非對稱密鑰交換和對稱內容加密兩大演算法。
對稱內容加密強度非常高，加解密速度也很快，只是無法安全地生成和保管密鑰。在 TLS 協議中，最後的應用數據都是經過對稱加密後傳輸的，傳輸中所使用的對稱協商密鑰(上文中的 enc_key)，則是在握手階段通過非對稱密鑰交換而來。常見的 AES-GCM、ChaCha20-Poly1305，都是對稱加密演算法。
非對稱密鑰交換能在不安全的數據通道中，產生只有通信雙方才知道的對稱加密密鑰。目前最常用的密鑰交換演算法有 RSA 和 ECDHE。
RSA 歷史悠久，支持度好，但不支持 完美前向安全 - PFS(Perfect Forward Secrecy) ；而 ECDHE 是使用了 ECC（橢圓曲線）的 DH（Diffie-Hellman）演算法，計算速度快，且支持 PFS。
在 PKI 體系 一節中說明了僅有非對稱密鑰交換還是無法抵禦 MITM 攻擊的，所以需要引入了 PKI 體系的證書來進行身份驗證，其中服務端非對稱加密產生的公鑰會放在證書中傳給客戶端。
在 RSA 密鑰交換中，瀏覽器使用證書提供的 RSA 公鑰加密相關信息，如果服務端能解密，意味著服務端擁有與公鑰對應的私鑰，同時也能算出對稱加密所需密鑰。密鑰交換和服務端認證合並在一起。
在 ECDH 密鑰交換中，服務端使用私鑰 (RSA 或 ECDSA) 對相關信息進行簽名，如果瀏覽器能用證書公鑰驗證簽名，就說明服務端確實擁有對應私鑰，從而完成了服務端認證。密鑰交換則是各自發送 DH 參數完成的，密鑰交換和服務端認證是完全分開的。
可用於 ECDHE 數字簽名的演算法主要有 RSA 和 ECDSA - 橢圓曲線數字簽名演算法 ，也就是目前密鑰交換 + 簽名有三種主流選擇:
比如我的網站使用的加密套件是 ECDHE_RSA，可以看到數字簽名演算法是 sha256 哈希加 RSA 加密，在 PKI 體系 一節中講了簽名是伺服器信息摘要的哈希值加密生成的
內置 ECDSA 公鑰的證書一般被稱之為 ECC 證書，內置 RSA 公鑰的證書就是 RSA 證書。因為 256 位 ECC Key 在安全性上等同於 3072 位 RSA Key，所以 ECC 證書體積比 RSA 證書小，而且 ECC 運算速度更快，ECDHE 密鑰交換 + ECDSA 數字簽名是目前最好的加密套件
以上內容來自本文: 開始使用 ECC 證書
關於 ECC 證書的更多細節可見文檔: ECC Cipher Suites for TLS - RFC4492
使用 RSA 進行密鑰交換的握手過程與前面說明的基本一致，只是沒有 ServerKeyExchange 消息，其中協商密鑰涉及到三個參數 (客戶端隨機數 random_C、服務端隨機數 random_S、預主密鑰 Premaster secret)，
其中前兩個隨機數和協商使用的演算法是明文的很容易獲取，最後一個 Premaster secret 會用伺服器提供的公鑰加密後傳輸給伺服器 (密鑰交換)，如果這個預主密鑰被截取並破解則協商密鑰也可以被破解。
RSA 演算法的細節見: wiki 和 RSA演算法原理（二）- 阮一峰
RSA 的演算法核心思想是利用了極大整數 因數分解 的計算復雜性
而使用 DH(Diffie-Hellman) 演算法 進行密鑰交換，雙方只要交換各自的 DH 參數(在 ServerKeyExchange 發送 Server params，在 ClientKeyExchange 發送 Client params)，不需要傳遞 Premaster secret，就可以各自算出這個預主密鑰
DH 的握手過程如下，大致過程與 RSA 類似，圖中只表達如何生成預主密鑰:
伺服器通過私鑰將客戶端隨機數 random_C，服務端隨機數 random_S，服務端 DH 參數 Server params 簽名生成 signature，然後在 ServerKeyExchange 消息中發送服務端 DH 參數和該簽名；
客戶端收到後用伺服器給的公鑰解密驗證簽名，並在 ClientKeyExchange 消息中發送客戶端 DH 參數 Client params；
服務端收到後，雙方都有這兩個參數，再各自使用這兩個參數生成預主密鑰 Premaster secret，之後的協商密鑰等步驟與 RSA 基本一致。
關於 DH 演算法如何生成預主密鑰，推薦看下 Wiki 和 Ephemeral Diffie-Hellman handshake
其核心思想是利用了 離散對數問題 的計算復雜性
演算法過程可以抽象成下圖:
雙方預先商定好了一對 P g 值 (公開的)，而 Alice 有一個私密數 a(非公開，對應一個私鑰)，Bob 有一個私密數 b(非公開，對應一個私鑰)
對於 Alice 和 Bob 來說通過對方發過來的公鑰參數和自己手中的私鑰可以得到最終相同的密鑰
而第三方最多知道 P g A B，想得到私鑰和最後的密鑰很困難，當然前提是 a b P 足夠大 (RFC3526 文檔中有幾個常用的大素數可供使用)，否則暴力破解也有可能試出答案，至於 g 一般取個較小值就可以
如下幾張圖是實際 DH 握手發送的內容:
可以看到雙方發給對方的參數中攜帶了一個公鑰值，對應上述的 A 和 B
而且實際用的加密套件是 橢圓曲線 DH 密鑰交換 (ECDH) ，利用由橢圓曲線加密建立公鑰與私鑰對可以更進一步加強 DH 的安全性，因為目前解決橢圓曲線離散對數問題要比因式分解困難的多，而且 ECC 使用的密鑰長度比 RSA 密鑰短得多(目前 RSA 密鑰需要 2048 位以上才能保證安全，而 ECC 密鑰 256 位就足夠)
關於 橢圓曲線密碼學 - ECC ，推薦看下 A Primer on Elliptic Curve Cryptography - 原文 - 譯文
盡管可以選擇對任意一端進行身份驗證，但人們幾乎都啟用了對伺服器的身份驗證。如果伺服器選擇的套件不是匿名的，那麼就需要在 Certificate 消息中跟上自己的證書。
相比之下，伺服器通過發送 CertificateRequest 消息請求對客戶端進行身份驗證。消息中列出所有可接受的客戶端證書。作為響應，客戶端發送自己的 Certificate 消息（使用與伺服器發送證書相同的格式），並附上證書。此後，客戶端發送 CertificateVerify 消息，證明自己擁有對應的私鑰。
只有已經過身份驗證的伺服器才被允許請求客戶端身份驗證。基於這個原因，這個選項也被稱為相互身份驗證（mutual authentication）。
在 ServerHello 的過程中發出，請求對客戶端進行身份驗證，並將其接受的證書的公鑰和簽名演算法傳送給客戶端。
它也可以選擇發送一份自己接受的證書頒發機構列表，這些機構都用其可分辨名稱來表示:
在 ClientKeyExchange 的過程中發出，證明自己擁有的私鑰與之前發送的客戶端證書中的公鑰匹配。消息中包含一條到這一步為止的所有握手消息的簽名：
最初的會話恢復機制是，在一次完整協商的連接斷開時，客戶端和伺服器都會將會話的安全參數保存一段時間。希望使用會話恢復的伺服器為會話指定唯一的標識，稱為會話 ID(Session ID)。伺服器在 ServerHello 消息中將會話 ID 發回客戶端。
希望恢復早先會話的客戶端將適當的 Session ID 放入 ClientHello 消息，然後提交。伺服器如果同意恢復會話，就將相同的 Session ID 放入 ServerHello 消息返回，接著使用之前協商的主密鑰生成一套新的密鑰，再切換到加密模式，發送 Finished 消息。
客戶端收到會話已恢復的消息以後，也進行相同的操作。這樣的結果是握手只需要一次網路往返。
Session ID 由伺服器端支持，協議中的標准欄位，因此基本所有伺服器都支持，伺服器端保存會話 ID 以及協商的通信信息，佔用伺服器資源較多。
用來替代伺服器會話緩存和恢復的方案是使用會話票證（Session ticket）。使用這種方式，除了所有的狀態都保存在客戶端（與 HTTP Cookie 的原理類似）之外，其消息流與伺服器會話緩存是一樣的。
其思想是伺服器取出它的所有會話數據（狀態）並進行加密 (密鑰只有伺服器知道)，再以票證的方式發回客戶端。在接下來的連接中，客戶端恢復會話時在 ClientHello 的擴展欄位 session_ticket 中攜帶加密信息將票證提交回伺服器，由伺服器檢查票證的完整性，解密其內容，再使用其中的信息恢復會話。
這種方法有可能使擴展伺服器集群更為簡單，因為如果不使用這種方式，就需要在服務集群的各個節點之間同步會話。
Session ticket 需要伺服器和客戶端都支持，屬於一個擴展欄位，佔用伺服器資源很少。
❾ 密碼技術（十一）之密鑰
——秘密的精華
在使用對稱密碼、公鑰密碼、消息認證碼、數字簽名等密碼技術使用，都需要一個稱為 密鑰 的巨大數字。然而，數字本身的大小並不重要，重要的是 密鑰空間的大小 ，也就是可能出現的密鑰的總數量，因為密鑰空間越大，進行暴力破解就越困難。密鑰空間的大小是由 密鑰長度 決定的。
對稱密碼DES的密鑰的實質長度為56比特（7個位元組）。
例如，
一個DES密鑰用二進制可以表示為：
01010001 11101100 01001011 00010010 00111101 01000010 00000011
用十六進制則可以表示為：
51 EC 4B 12 3D 42 03
而用十進制則可以表示為：
2305928028626269955
在對稱密碼三重DES中，包括使用兩個DES密鑰的DES-EDE2和使用三個DES密鑰的DES-EDE3這兩種方式。
DES-EDE2的密鑰長度實質長度為112比特（14位元組），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F
DES-EDE3的密鑰的實質長度為168比特（21位元組），比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
對稱密碼AES的密鑰長度可以從128、192和256比特中進行選擇，當密鑰長度為256比特時，比如：
51 EC 4B 12 3D 42 03 30 04 D8 98 95 93 3F 24 9F 61 2A 2F D9 96
B9 42 DC FD A0 AE F4 5D 60 51 F1
密鑰和明文是等價的 。假設明文具有100萬的價值，那麼用來加密這段明文的密鑰也就是具有100萬元的價值；如果明文值1億元，密鑰也就值1億元；如果明文的內容是生死攸關的，那麼密鑰也同樣是生死攸關的。
在對稱密碼中，加密和解密使用同一個密鑰。由於發送者和接收者需要共享密鑰，因此對稱密碼又稱為共享密鑰密碼。對稱密碼中所使用的密鑰必須對發送者和接收者以外的人保密，否則第三方就能夠解密了。
在消息認證碼中，發送者和接收者使用共享的密鑰來進行認證。消息認證碼只能由持有合法密鑰的人計算出來。將消息認證碼附加在通信報文後面，就可以識別通信內容是否被篡改或偽裝，由於「持有合法的密鑰」就是發送者和接收者合法身份的證明，因此消息認證碼的密鑰必須對發送者以外的人保密，否則就會產生篡改和偽裝的風險。
在數字簽名中，簽名生成和驗證使用不同的密鑰，只有持有私鑰的本人才能夠生成簽名，但由於驗證簽名使用的是公鑰，因此任何人都能夠驗證簽名。
對稱密碼和公鑰密碼的密鑰都是用於確保機密性的密鑰。如果不知道用於解密的合法密鑰，就無法得知明文的內容。
相對地，消息認證碼和數字簽名所使用的密鑰，則是用於認證的密鑰。如果不知道合法的密鑰，就無法篡改數據，也無法偽裝本人的身份。
當我們訪問以https://開頭的網頁時，Web伺服器和瀏覽器之間會進行基於SSL/TLS的加密通信。在這樣的通信中所使用的密鑰是僅限於本次通信的一次密鑰，下次通信時就不能使用了，想這樣每次通信只能使用一次的密鑰稱為 會話密鑰 。
由於會話密鑰只在本次通信中有效，萬一竊聽者獲取了本次通信的會話密鑰，也只能破譯本次通信的內容。
雖然每次通信都會更換會話密鑰，但如果用來生成密鑰的偽隨機數生成器品質不好，竊聽者就有可能預測出下次生成會話密鑰，這樣就會產生通信內容被破譯的風險。
相對於每次通信更換的會話密鑰，一直被重復使用的密鑰稱為 主密鑰 。
一般來說，加密的對象是用戶直接使用的信息，這樣的情況下所使用的密鑰稱為CEK(Contents Encryting Key，內容加密密鑰)；相對地，用於加密密鑰的密鑰則稱為KEK（Key Encryting Key，密鑰加密密鑰）。
在很多情況下，之前提到的會話密鑰都是被作為CEK使用的，而主密鑰則是被作為KEK使用的。
生成密鑰的最好方法就是使用隨機數，因為米喲啊需要具備不易被他人推測的性質。在可能的情況下最好使用能夠生成密碼學上的隨機數的硬體設備，但一般我們都是使用偽隨機數生成器這一專門為密碼學用途設計的軟體。
在生成密鑰時，不能自己隨便寫出一些像「3F 23 52 28 E3....」這樣的數字。因為盡管你想生成的是隨機的數字，但無論如何都無法避免人為偏差，而這就會成為攻擊者的目標。
盡管生成偽隨機數的演算法有很多種，但密碼學用途偽隨機生成器必須是專門針對密碼學用途而設計的。例如，有一些偽隨機數生成器可以用於游戲和模擬演算法，盡管這些偽隨機數生成器所生成的數列看起也是隨機的，但只要不是專門為密碼學用途設計的，就不能用來生成密鑰，因為這些偽隨機數生成器不具備不可預測性這一性質。
有時候我們也會使用人類的可以記住的口令（pasword或passphrase）來生成密鑰。口令指的是一種由多個單片語成的較長的password。
嚴格來說，我們很少直接使用口令來作為密鑰使用，一般都是將口令輸入單向散列函數，然後將得到的散列值作為密鑰使用。
在使用口令生成密鑰時，為了防止字典攻擊，需要在口令上附加一串稱為鹽（salt）的隨機數，然後在將其輸入單向散列函數。這種方法稱為「基於口令的密碼（Password Based Encryption，PBE）」。
在使用對稱密碼時，如何在發送者和接收者之間共享密鑰是一個重要的問題，要解決密鑰配送問題，可以採用事先共享密鑰，使用密鑰分配中心，使用公鑰密碼等方法，除了上述方法，之前還提到一種解決密鑰配送的問題的方法稱為Diffie-Hellman密鑰交換。
有一種提供通信機密性的技術稱為 密鑰更新 （key updating），這種方法就是在使用共享密鑰進行通信的過程中，定期更改密鑰。當然，發送者和接收者必須同時用同樣的方法來改變密鑰才行。
在更新密鑰時，發送者和接收者使用單向散列函數計算當前密鑰的散列值，並將這個散列值用作新的密鑰。簡單說，就是 用當前密鑰散列值作為下一個密鑰 。
我們假設在通信過程中的某個時間點上，密鑰被竊聽者獲取了，那麼竊聽者就可以用這個密鑰將之後的通信內容全部解密。但是，竊聽者卻無法解密更新密鑰這個時間點之前的內容，因為這需要用單向散列函數的輸出反算出單向散列函數的輸入。由於單向散列函數具有單向性，因此就保證了這樣的反算是非常困難的。
這種防止破譯過去的通信內容機制，稱為 後向安全 （backward security）。
由於會話密鑰在通信過程中僅限於一次，因此我們不需要保存這種秘密。然而，當密鑰需要重復使用時，就必須要考慮保存密鑰的問題了。
人類是 無法記住具有實用長度的密鑰 的。例如，像下面這樣一個AES的128比特的密鑰，一般人是很難記住的。
51 EC 4B 12 3D 42 03 30 04 DB 98 95 93 3F 24 9F
就算勉強記住了，也只過不是記住一個密鑰而已。但如果要記住多個像這樣的密鑰並且保證不忘記，實際上是非常困難的。
我們記不住密鑰，但如果將密鑰保存下來又可能會被竊取。這真是一個頭疼的問題。這個問題很難得到徹底解決，但我們可以考慮一些合理的解決方法。
將密鑰保存生文件，並將這個文件保存在保險櫃等安全地方。但是放在保險櫃里的話，出門就無法使用了。這種情況，出門時就需要隨身攜帶密鑰。而如果將密鑰放在存儲卡隨身攜帶的話，就會產生存儲卡丟失、被盜等風險。
萬一密鑰被盜，為了能夠讓攻擊者花更多的時間才能真正使用這個密鑰，我們可以使用將密鑰加密後保存的方法，當然，要將密鑰加密，必須需要另一個密鑰。像這樣用於密碼加密的密鑰，一般稱為KEK。
對密鑰進行加密的方法雖然沒有完全解決機密性的問題，但在現實中卻是一個非常有效地方法，因為這樣做可以減少需要保管密鑰的數量。
假設計算機上有100萬個文件，分別使用不同的密鑰進行加密生成100萬個密文，結果我們手上就產生了100萬個密鑰，而要保管100萬個密鑰是很困難的。
於是，我們用一個密鑰（KEK）將這100萬個密鑰進行加密，那麼現在我們只要保管者一個KEK就可以了，這一個KEK的價值相當於簽名的100萬個密鑰的價值的總和。
用1個密鑰來代替多個密鑰進行保管的方法，和認證機構的層級化非常相似。在後者中，我們不需要信任多個認證機構，而只需要信任一個根CA就可以了。同樣的，我們也不需要確保多個密鑰的機密性，而只需要確保一個KEK的機密性就可以了。
密鑰的作廢和生成是同等重要的，這是因為密鑰和明文是等價的。
假設Alice向Bob發送了一封加密郵件。Bob在解密之後閱讀了郵件的內容，這時本次通信所使用的密鑰對於Alice和Bob來說就不需要了。不在需要的密鑰必須妥善刪除，因為如果被竊聽者Eve獲取，之前發送的加密郵件就會被解密。
如果密鑰是計算機上的一個文件，那麼僅僅刪除這個文件是不足以刪除密鑰的，因為有一些技術能夠讓刪除的文件「恢復」。此外，很多情況下文件的內容還會殘留在計算機的內存中，因此必須將這些痕跡完全抹去。簡而言之，要完全刪除密鑰，不但要用到密碼軟體，還需要在設計計算機系統時對信息安全進行充分的考慮
如果包含密鑰的文件被誤刪或者保管密鑰的筆記本電腦損壞了，會怎麼樣？
如果丟失了對稱密鑰密碼的共享密鑰，就無法解密密文了。如果丟失了消息認證碼的密鑰，就無法向通信對象證明自己的身份了。
公鑰密碼中，一般不太會發送丟失公鑰的情況，因為公鑰是完全公開的，很有可能在其他電腦上存在副本。
最大的問題是丟失公鑰密碼的私鑰。如果丟失了公鑰密碼的私鑰，就無法解密用公鑰密碼加密的密文了。此外，如果丟失了數字簽名的私鑰，就無法生成數字簽名了。
Diffie-Hellman密鑰交換（Diffie-Hellman key exchange）是1976年由Whitfield Diffie和Martin Hellman共同發明的一種演算法。使用這種演算法，通信雙方僅通過交換一些可以公開的信息就能夠生成共享秘密數字，而這一秘密數字就可以被用作對稱密碼的密鑰。IPsec 中就使用了經過改良的Diffie-Hellman密鑰交換。
2 Alice 生成一個隨機數A
A是一個1 ~ P-2之間的整數。這個數是一個只有Alice知道的密碼數字，沒有必要告訴Bob，也不能讓Eve知道。
Alice計算出的密鑰=Bob計算出的密鑰
在步驟1-7中，雙方交換數字一共有4個，P、G、G A mod P 和 G B mod P。根據這4個數字計算出Alice和Bob的共享密鑰是非常困難的。
如果Eve能歐知道A和B的任意一個數，那麼計算G A*B 就很容易了，然而僅僅根據上面的4個數字很難求出A和B的。
根據G A mod P 計算出A的有效演算法到現在還沒有出現，這問題成為有限域(finite field) 的 離散對數問題 。
Diffie-Hellman密鑰交換是利用了「離散對數問題」的復雜度來實現密鑰的安全交換的，如果將「離散對數問題」改為「橢圓曲線上離散對數問題」，這樣的演算法就稱為 橢圓曲線Diffie-Hellman 密鑰交換。
橢圓曲線Diffie-Hellman密鑰交換在總體流程上是不變的，只是所利用的數學問題不同而已。橢圓曲線Diffie-Hellman密鑰交換能夠用較短的密鑰長度實現較高的安全性。
基於口令密碼（password based encryption，PBE）就是一種根據口令生成密鑰並用該密鑰進行加密的方法。其中加密和解密使用同一個密鑰。
PBE有很多種實現方法。例如RFC2898和RFC7292 等規范中所描述的PBE就通過java的javax.crypto包等進行了實現。此外，在通過密碼軟體PGP保存密鑰時，也會使用PBE。
PBE的意義可以按照下面的邏輯來理解。
想確保重要消息的機制性。
↓
將消息直接保存到磁碟上的話，可能被別人看到。
↓
用密鑰（CEK）對消息進行加密吧。
↓
但是這次又需要確保密鑰（CEK）的機密性了。
↓
將密鑰（CEK）直接保存在磁碟上好像很危險。
↓
用另一個密鑰（KEK）對密鑰進行加密（CEK）吧。
↓
等等！這次又需要確保密鑰（KEK）的機密性了。進入死循環了。
↓
既然如此，那就用口令來生成密鑰（KEK）吧。
↓
但只用口令容易遭到字典攻擊
↓
那麼就用口令和鹽共同生成密鑰（KEK）吧。
↓
鹽可以和加密後的密鑰（CEK）一切保存在磁碟上，而密鑰（KEK）可以直接丟棄。
↓
口令就記在自己的腦子里吧。
PBE加密包括下列3個步驟：
鹽是由偽隨機數生成器生成的隨機數，在生成密鑰（KEK）時會和口令一起被輸入單向散列函數。
密鑰（KEK）是根據秘密的口令生成的，加鹽好像沒有什麼意義，那麼鹽到底起到什麼作用呢？
鹽是用來防禦字典攻擊的 。字典攻擊是一種事先進行計算並准備好候選密鑰列表的方法。
我們假設在生成KEK的時候沒有加鹽。那麼主動攻擊者Mallory就可以根據字典數據事先生成大量的候選KEK。
在這里，事先是很重要的一點。這意味著Mallory可以在竊取到加密會話的密鑰之前，就准備好了大量的候選KEK。當Mallory竊取加密的會話密鑰後，就需要嘗試將它解密，這是准備好了大量事先生成的候選KEK，就能夠大幅度縮短嘗試的時間，這就是 字典攻擊 （dictionary attack）。
如果在生成KEK時加鹽，則鹽的長度越大，候選KEK的數量也會隨之增大，事先生成的的候選KEK就會變得非常困難。只要Mallory還沒有得到鹽，就無法生成候選KEK。這是因為加鹽之後，候選KEK的數量會變得非常巨大。
具有充足長度的密鑰是無法用人腦記憶的。口令也是一樣，我們也無法記住具有充足比特數的口令。
在PBE中，我們通過口令生成密鑰（KEK），在用這個密鑰來加密會話密鑰（CEK）。由於通過口令生成的密鑰（KEK）強度不如由偽隨機數生成器生成的會話密鑰（CEK），這就好像是將一個牢固的保險櫃的鑰匙放在了一個不怎麼牢固的保險櫃保管，因此在使用基於口令的密鑰時，需要將鹽和加密後的CEK通過物理方法進行保護。例如將鹽和加密後的CEK保存到存儲卡隨身攜帶。
在生成KEK時，通過多次使用單向散列函數就可以提高安全性。例如，將鹽和口令輸入單向散列函數，進行1000次的散列函數所得到的散列值作為KEK來使用，是一個不錯的方法。
像這樣將單向散列函數進行多次迭代的方法稱為 拉伸 （stretching）。
該系列的主要內容來自《圖解密碼技術第三版》
我只是知識的搬運工
文章中的插圖來源於原著