密碼套件密碼，演算法和協商安全設定（二）

上期內容我們分析了什麼是密碼套件以及它的背景，從演算法和金鑰、再到數學原理等方面進行詳細地**，小編我都感覺非常精彩。那麼這一期必須精彩繼續，讓我們接著深入地研究tls 1.2密碼套件的四個不同元件。但是首先看看我們在ssl / tls中看到的兩種不同型別的加密。

ssl / tls的最大困惑之一就是所使用的加密型別

，與ssl證書關聯的2048位金鑰用於幫助協商https連線，但是它的作用實際上比大多數人認為的要小得多。

我們似乎只專注於私鑰的位數，如2048位的私鑰，因為它聽起來似乎很安全。我們甚至會大膽地認為，「現代計算機要花上四千萬萬年才能破解此金鑰，到那時我們都已經死了！」

但是，可以說，你在連線期間使用的批量加密和對稱金鑰同等重要，甚至比公/私金鑰對還重要。

相反，如果我們使用非對稱加密，加解密使用的金鑰並不對稱，乙個金鑰用來加密，另乙個金鑰用來解密。非對稱加密通常採用帶tls 1.2的rsa形式，它負責驗證數字簽名，並且在使用rsa金鑰交換時，它從加密計算出對稱會話金鑰的主密碼，但是rsa並不是唯一的金鑰交換機制。

對稱加密金鑰（通常為aes或高階加密標準）的金鑰大小範圍為128位到256位。對於對稱加密，這是完全有效和安全的，在對稱加密中，計算難度必須與可用性或者說與其加密效能保持一致。

那些2048位非對稱rsa金鑰的計算成本很高，並且增加了握手延遲。在某些實際應用中，它們還容易遭受填充攻擊。

長話短說，這裡既講了非對稱加密也講了對稱加密，但是對稱加密在密碼套件的上下文中關聯性更強。

現在，讓我們看一下密碼套件的四個不同元件。

tls 1.2密碼套件中的第乙個位置指定用於將要使用的金鑰交換機制。

金鑰交換是指用於傳輸對稱會話金鑰的實際過程，但這並不是金鑰生成過程中使用的唯一演算法。握手的金鑰交換部分確定用於金鑰生成的引數，但是雜湊演算法在通過提供偽隨機函式（prf）（通常作為加密安全的偽隨機數生成器「csprng」）提供金鑰的過程中也發揮著作用。

我們要明白的重要一點是，所選的金鑰交換機制並不完全負責生成實際金鑰。

rsarsa以建立它的紳士的名字命名：rivest，shamir和adleman。這是最常見的非對稱密碼演算法。它使用質數的冪運算，具有廣泛的應用範圍。使用ssl / tls，通常會在金鑰交換的上下文中看到使用rsa。同樣，這是所有這些2048位（以及3072和4096位）金鑰的**。

每次握手，無論是否選擇rsa金鑰協商機制都會從clienthello和serverhello交換隨機數。

一旦客戶端和服務端決定使用包含rsa金鑰交換的密碼套件，並且在客戶端對服務端進行身份驗證之後，rsa的執行方式就非常簡單。

客戶端使用服務端傳送的公鑰來加密預主金鑰並進行傳輸。

服務端使用其私鑰解密預主金鑰。

雙方都使用prf，客戶端隨機數，服務端隨機和主機密碼來匯出主金鑰。

雙方都使用主金鑰和更多偽隨機函式來計算會話金鑰。

在最後兩個步驟3和4中，混合主金鑰並派生會話金鑰，在此利用雜湊演算法的偽隨機函式。

rsa金鑰交換已經使用了很長時間，但是它已經壽終正寢了。由於已知漏洞，tls 1.3除了所有其他靜態金鑰交換機制之外，還取消了rsa金鑰交換。

diffie-hellman和橢圓曲線diffie-hellman

它們以惠特菲爾德·迪菲（whitfield diffie）和馬丁·海爾曼（martin hellman）的名字命名，這是乙個金鑰交換協議，但它與rsa非對稱加密協議並不相同。diffie和hellman在這裡著手解決的問題是如何在不安全的網路上交換安全金鑰，並由攻擊者監視。

diffie-hellman金鑰交換的工作方式如下：

在交換了隨機數（g＆p）之後，客戶端和服務端都選擇了自己的主控機密（分別為a＆b），並計算出乙個類似的方程式– g amod p = a，＆g bmod p =b。

每個到達的值（a＆b）被傳送給對方，並且雙方重複相同的操作-b a modp和a b mod p。

各方提供所謂的「金鑰共享」，並且他們各自獨立地到達共享會話金鑰。有乙個模冪的規則規定了這一點。

如果這是很多數**算，那麼關鍵在於：使用diffie-hellman進行金鑰交換時，實際上沒有進行非對稱加密，而是兩方相互得出了可用於匯出會話金鑰的值。

現在讓我們來談談橢圓曲線diffie-hellman，它基本上只是diffie-hellman的現代迭代，它受橢圓曲線密碼學的支配，而不是其他一些密碼系統。基本上，它使用繪製在橢圓曲線上的點作為其計算的基礎。

首先，diffie-hellman需要牢記兩點–在短暫使用時，它缺乏真正的身份驗證機制。臨時金鑰是臨時的，所以通常不進行身份驗證。

其次，正如我們剛剛提到的，在tls 1.3中，所有靜態金鑰生成/交換機制都已棄用。這基本上是廢棄rsa的原因，它也消除了非短暫的dh方案。現在ecdhe或「橢圓曲線diffie-hellman臨時」是金鑰交換的標準。

因為在tls 1.3中，perfect forward secrecy是必須的。完美**保密功能可保護各個會話免遭解密，即使證書的私鑰被洩露也是如此。靜態金鑰交換方案不支援這一點。

psk（共享金鑰）

通常是寫為tls-psk的密碼，它是根據預先在各方之間交換的預共享對稱金鑰提供安全通訊的。在這裡我們就不講psk了，因為在高度管制的網路環境之外它還是很少見的，並且我們絕對不建議其作為商業用途。它也未包含在tls 1.3中。

以上是本期的內容，不知道童鞋們看明白了嗎？沒關係，我建議慢慢消化，更建議大家認真細看後提出異議給小編，我們共同**。下期我們接著密碼套件的大主題，圍繞數字簽名認證以及批量加密密碼的內容而繼續展開**，下期精彩持續，不見不散。

密碼套件 密碼，演算法和協商安全設定（二）