請教DH演算法在混合加密中，到底起什麼作用？

12-28

在此請教高手了，我在學習PKI/RSA的過程中，遇到太多似懂非懂，似是而非的問題，也許密碼學本身就比較難吧。
第一個問題是，在RSA演算法中引入DH演算法，到底起什麼作用
先說說我對RSA的運作過程的理解
假設A與B通信
1、A用對稱密鑰key加密數據
2、A用B的公鑰加密key，得到Ckey
3、把加密後的數據和Ckey一併發給B
4、B用自己的私鑰解密Ckey，得到對稱密鑰key
5、用這個對稱密鑰key解密A發來的數據數據，得到原始的數據
我看到的所有的關於RSA加密的視頻講座里，都是這麼說的。

可當我繼續深入了解密碼學的時候，出現了另一個演算法：
Diffie-Hellman，也就是DH演算法
DH演算法說，上述我說的「用對稱密鑰加密」的過程，這裡的對稱密鑰，其實是通過DH演算法，在A和B之間協商的，協商的結果就是A和B得到了同一個數字，也就是對稱密鑰。

那麼好，既然A和B已經得到了同一個對稱密鑰，那A加密數據以後，根本就不用把這個密鑰（用B的公鑰加密）發給B了。
可視頻里為啥都這麼說呢？
而且，就視頻里所言：A在本地生成一個對稱密鑰，用B的公鑰加密後發給B

因為對稱密鑰是在B的公鑰的保護下發給B的，所以安全性是有保證的，何必多出一個DH演算法呢？
我猜測，可能是解釋：
DH演算法不僅僅是得出了對稱密鑰，也得出了A和B的公鑰/私鑰對，
也就是說，A和B的對稱密鑰，以及A和B的公鑰/私鑰，都是通過DH演算法得出的
是不是跟這個有關係？
是：B如何驗證，信息肯定是A發出來的
A在發送數據之前，可以先做數字簽名
B得到數據以後，驗證簽名，即可確認是否是A發出的
但，每個向B發送的數據包里，都必須要發送A的證書么？
謝謝！

謝邀。

今天（2015.8.29）晚上差不多19點就收到邀請了。剛看到題目的時候一愣，再看題目描述更是一頭霧水。於是在評論區給題主發了個評論，不過未能得到回復。自己又想了一下，終於知道問題到底出在哪裡了。我用我淺顯的協議安全知識回答一下，如果有錯誤或者不嚴謹的地方，還請知乎er們在評論區留言，或者另開一個回答。我會隨時更新答案。

=============================
0. 簡答
題主之所以對視頻中的講解一頭霧水，應該是視頻中混淆了公鑰加密/解密、數字簽名的概念，特別是RSA公鑰加密/解密、數字簽名的概念。RSA演算法實際上有兩種使用方法：RSA加密、RSA簽名。我個人已經看到了無數的討論，無數的答案，都把數字簽名也寫成了加密/解密，比如「用私鑰加密信息，用公鑰解密信息」。因此，視頻中的本意應該是：

用Diffie-Hellman密鑰交換協議時，對於通信過程使用RSA進行數字簽名，從而使得Diffie-Hellman密鑰協商協議可以抵禦中間人攻擊。

也就是說，並非是RSA加密和Diffie-Hellman密鑰協商協議結合，而是RSA簽名和Diffie-Hellman密鑰協商協議的結合。

之所以有這樣的混淆，是因為RSA用於加密和用於簽名時，演算法的執行流程是完全一樣的！甚至，RSA中如果把公鑰和私鑰弄混了，演算法照樣可以執行，而且可以很順利的執行。但是注意，只有RSA有這樣的特性。後續提出的加密/簽名演算法中，幾乎沒有再有這樣的特性了，公鑰私鑰不能調換使用。

有關RSA演算法中，公鑰私鑰可以調換使用，請參考我的另一個答案：RSA的公鑰和私鑰到底哪個才是用來加密和哪個用來解密？ - 劉巍然-學酥的回答

=============================
為了讓題主更清楚對稱加密、公鑰加密、密鑰協商、數字簽名，以及它們在現代通信系統中的具體使用方法，請看下面的介紹。注意，下面的介紹中沒有給出具體的演算法，而是將所有演算法當做黑盒（Black-Box）使用。在實際操作中，將具體的演算法套用其中，就可以得到具體的例子了。這樣寫可以避免歧義和混淆。

=============================
1. 最初的加密方式：對稱加密方式
一直以來，人們一直使用的加密方式都是對稱加密（Symmetric Encryption）。對稱加密的意思是，通信雙方有一個相同的密鑰K。加密和解密時，雙方都使用這個相同的密鑰K進行操作。具體來說，對稱加密擁有兩個演算法：

加密演算法SymEncrypt以密鑰K和數據Data作為輸入，輸出密文CT。
解密演算法SymDecrypt以密鑰K和密文CT作為輸入，輸出數據Data。

舉個例子，如果一個小女孩兒Alice想和一個小男孩兒Bob進行秘密的通信，雙方都有一個相同的密鑰K的話，那麼通信很容易就能實現：分別執行上述兩個演算法，兩個人互相發互相收，其樂融融。

但是，人們一直都沒法解決一個問題：怎麼讓雙方都擁有一個相同的密鑰K呢？通常的方法就是把K用各種方法秘密的傳送給對方。比如使用雞毛信啊，使用隱寫筆什麼的。這的確是一個不錯的方法。但是，多數情況下通信雙方很可能根本沒法見面，或者沒有任何方法可以快速地傳遞這個密鑰K，比如現如今的互聯網。如何解決這個問題呢？

=============================
2. 創新性的解決方法：公鑰加密
一種方法不行，我們來看另一種方法。1977年，Rivest，Shamir和Adleman三個人提出了一種改變世界的加密方法：公鑰加密（PublicKey Encryption），也成非對稱加密（Asymmetric Encryption）。與密鑰協商演算法類似，在公鑰加密中，接收方產生一個公鑰/私鑰對，公鑰公開的告訴所有人，私鑰自己保留。任何人在獲得公鑰後，都可以執行加密演算法，用公鑰對數據進行加密。只有擁有私鑰的人才能夠解密數據。公鑰加密有三個演算法：

密鑰生成演算法EGen輸出一個公鑰和私鑰對(epk, esk)，esk需要秘密地保存，epk可以公開。
公鑰加密演算法AsymEncrypt以公鑰epk和數據data作為輸入，輸出密文CT。
公鑰解密演算法AsymDecrypt以私鑰esk和密文CT作為輸入，輸出數據data。

這種方法很厲害，看似能夠解決對稱加密中的全部問題。但是這種方法有個最大的缺陷，就是無論公鑰加密怎麼設計，其加密的速度都會遠遠慢於對稱加密。因此在實際中，人們更多地是利用公鑰加密給對方發送一個密鑰K，以後將密鑰K作為對稱加密的密鑰進行通信。這樣一來，既利用了公鑰加密可以公開加密的特點，又利用了對稱加密速度快的特點，一舉兩得。

如圖所示，Alice和Bob可以用下述方法分享密鑰K，並在隨後使用對稱加密進行通信。

公鑰加密體制最大的特點就是，加密方可以使用公鑰加密。但問題也出在了這裡：任何人都可以獲得這個公鑰（因為公鑰是公開的），那麼任何人都可以利用這個方法將一個密鑰K發送給Alice了。舉個例子，Bob可以發送，一個小惡魔Eve也可以用相同的方法發送，如圖所示：

這樣一來，Alice根本無法區分收到的密文到底是Bob發送的還是Eve發送的。=============================
3. 另一種方法，公開信道分享密鑰：密鑰交換協議
1976年，著名密碼學家Diffie和Hellman提出了一個創新性的想法：我們是否可以公開地分享密鑰呢？也就是說，通信雙方都採用一個公開信道傳遞消息，但只有彼此才能夠分享一個相同的密鑰K。其他人即使獲取到了公開信道中傳遞的任何消息，都無法計算出密鑰K。密鑰交換協議擁有兩個演算法：

密鑰生成演算法AGen輸出一個公鑰和私鑰對(apk, ask)，ask需要秘密地保存，apk可以公開發送給對方。
密鑰協商演算法Agree以一方的公鑰apk和自己的私鑰ask作為輸入，計算出一個密鑰K。

這樣一來，Alice和Bob就可以用這個協議在公開信道上面分享一個相同的密鑰K。隨後用這個K作為對稱加密演算法的密鑰，互相之間愉快地通信了。

我們可以注意到，密鑰交換協議的提出是早於公鑰加密的。實際上，Rivest，Shamir和Adleman三個人的是以Diffie和Hellman的工作作為啟發才提出的公鑰加密。

這種密鑰協商方法雖然很好，但仍然有一個類似的問題，攻擊者仍然可以利用公鑰公開的特性攻擊。當Bob將他的apk發送給Alice時，攻擊者可以截獲apk，自己運行AGen演算法產生一個公鑰/私鑰對，然後把他產生的公鑰發送給Alice。同理，攻擊者可以截獲Alice發送給Bob的apk，再運行AGen演算法，並把這個公鑰發送給Bob。Alice和Bob仍然可以執行協議，產生一個密鑰K。但實際上，Alice產生的密鑰K實際上是和攻擊者協商的；Bob產生的密鑰K也是和攻擊者協商的。

描述起來有點複雜，我們上圖。一個小惡魔Eve，可以按照下圖的方法實現這一攻擊：

因為這種方法，小惡魔Eve處於Alice和Bob中間的位置，因此這種攻擊方法叫作中間人攻擊（man in the middle attack）。

=============================
4. 終極解決方法：密鑰協商+簽名
Rivest，Shamir和Adleman三個人還提出了一個更為創新性的想法：既然我們可以用公鑰加密數據，私鑰解密數據，那麼我們是否可以用私鑰「加密」數據，公鑰「解密」數據呢？這看起來毫無意義，既然公鑰可以「解密」數據，那豈不是任何人都能夠解密了？這個方法的奇妙之處在於，數據只能用私鑰「加密」，那麼我們把加密結果作為一種認證方式。如果公鑰可以「解密」，就認為這個數據只能由擁有私鑰的一方「加密的」，這就可以確認，這個數據是由擁有私鑰的人發送出來的。

這種方式由於和人們簽字的方法很像，因此這種方法被稱為數字簽名（Digital Signature）。數字簽名有三個演算法：

密鑰生成演算法SGen輸出一個公鑰和私鑰對(spk, ssk)，ssk需要秘密地保存，spk可以公開。
簽名演算法Sign以私鑰ssk和要簽名的數據data作為輸入，輸出一個簽名Sigma。
驗證演算法Verify以公鑰spk和簽名Sigma作為輸入，驗證通過則輸出1，否則輸出0。

簽名演算法與密鑰協商演算法的結合可以解決上述攻擊方法。雙方密鑰協商時，再分別運行簽名演算法對自己發出的公鑰apk進行簽名。收到信息後，首先驗證簽名，如果簽名正確，則繼續進行密鑰協商。注意到，由於簽名演算法中的公鑰spk是一直公開的，攻擊者沒有辦法阻止別人獲取公鑰，除非完全掐斷髮送方的通信。這樣一來，中間人攻擊就不存在了，因為Eve無法偽造簽名。具體過程如圖所示：

題主的問題，實際上就是將Diffie-Hellman密鑰協商協議作為上述過程中的密鑰協商協議；將RSA簽名作為上述過程中的簽名。以此，RSA和Diffie-Hellman進行了結合，完成了整個密鑰協商過程，同時避免了中間人攻擊。

DH和RSA等公鑰演算法都可以用來交換對稱密鑰，但不能抵抗中間人攻擊，所以可以選擇用DH交換密鑰，用RSA對交換過程中的數據進行簽名以驗證通信雙方的身份、抵抗中間人攻擊。。

我覺得有一句話不嚴謹，RSA不能防止中間人攻擊。應該說無論你用什麼當前的什麼秘鑰交換演算法，都存在中間人攻擊，除非你加上數字簽名進行身份認證。而RSA既可以用於秘鑰交換又可以用於數字簽名。所以如果我只用RSA做秘鑰交換是防不住中間人攻擊的，但是同時也用RSA做數字簽名，兩種都用RSA，那我也可以說RSA是不怕中間人攻擊的。而DH可是不能進行數字簽名的，只能藉助其他的簽名演算法了。

你可以發現在tls握手的cipher suite有這兩種

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) #需要藉助另一種簽名演算法來實現數字簽名

Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) #RSA既用於數字簽名，又用於秘鑰交換

A和B保密通信，當然兩者的密鑰產生器是夠安全的。 A可以產生一個會話密鑰K，
E(PRb, E(PRa,K)),即對k先簽名，再用B的公鑰加密，再發送給B， B可以解密並驗證簽名，就知道K是A發過來的。由於加密了，攻擊者沒有B的私鑰，也就得不到K。 B可以認證A。可是A如何認證B呢？

DH能夠在不安全信道進行密鑰交換（對稱演算法的密鑰），但不能抵禦中間人攻擊。

A、B利用DH演算法交換密鑰後，通常還需要雙方對過程數據進行簽名驗證已防禦中間人攻擊。（ssl）

A直接生成密鑰發給B的方案存在下面問題：
1.B不參與密鑰生成，必須信任A的密鑰發生器足夠安全；
2.中間人攻擊，C偽裝成A發送密鑰，B傻傻分不清。
3.服務端為了節約成本，密鑰不每次隨機生成，而是使用密鑰池。

網路密碼體制不光需要考慮數據的安全，還需要抵禦黑客攻擊、均衡計算負載並考慮人性。分析密碼體制的時候要有黑客精神，分析其攻擊的可利用點。