RSA做密鑰協商(密鑰交換)時，是否可以防範中間人攻擊？

如果可以，那麼他和使用了消息認證的Diffie-Hellman密鑰協商的區別在哪裡？

是速度？傳輸信息的大小？

另外，現在實際中的密鑰協商主要使用哪些演算法？

---

部分同意 @武傑的觀點。題主需要定義清楚使用兩個演算法的環境。

RSA和DH兩種演算法都被用於密鑰協商。密鑰協商(key establishment)包括「密鑰傳輸」(key transmission)和「密鑰交換」(key exchange)。

TLS是廣泛用於日常生活中的https協議的一部分。以下答案針對這兩個演算法在TLS ciphersuite中的應用，即TLS_RSA_XXX 以及 TLS_DHE_XXX，此處的key指的是接下來在實際傳輸數據時使用的session key,安全性的結論在答案末尾。

區別：

在TLS_RSA_XX里，RSA起的作用是Key Transmission，也就是說，用於產生Session Key的「種子」是由客戶端決定，用伺服器的公鑰加密並再次傳輸到伺服器端。（見下圖的C,最下方的德語的意思是TLS Record Layer: 用密鑰k進行加密）

而在TLS_DHE_XX里，DH起的作用是key exchange，也就是說，用於產生session key的「種子」，是客戶端和伺服器都參與了的。(見下圖的和)

從兩張圖可以看出，使用TLS_RSA_XX的話，handshake中需要傳輸的信息數量比用TLS_DHE_XX的少。

TLS_RSA_XX的安全性可以參考這個paper。結論是在一定前提下，針對主動攻擊，比如中間人等，此密鑰傳輸協議是安全的。

On the security of RSA encryption in TLS_百度文庫

TLS_DHE_XX的安全性可以參考這個paper,結論類似。

Cryptology ePrint Archive: Report 2011/219

TLS中其他的密鑰協商方案大多是這兩種方案的變體，比如TLS_ECDHE，與DHE不同的地方在於使用的群是基於橢圓曲線的，但這個並非是有別於廣義的DH的新演算法。

---

1. RSA做密鑰協商時，可以防範中間人攻擊。

2. 最大區別在於RSA做密鑰協商不提供PFS（Perfect Forward Secrecy）特性，而DH提供PFS特性。還有，DH要多發送一個DH公鑰。

3.現在實際使用中，優先選擇 ECDHE&>DHE&> DH,RSA ...等 (這主要是由於 ECDHE和DHE是PFS的演算法，自從斯諾登事件之後，開始流行)

可以參考Mozilla的這個文檔：

https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

詳解：

TLS中的演算法分為4類，

authentication (認證)演算法

key exchange(密鑰交換)演算法

encryption(加密)演算法

message authentication code (消息認證碼 簡稱MAC)演算法

DH是密鑰交換演算法的一種。

RSA比較特殊，主要當作 authentication (認證)演算法 來用，但是也可以當作 密鑰交換演算法 來用，一身二任。

中間人攻擊的問題，是通過 authentication (認證)演算法 ，配合pki證書體系(體現在客戶端內置的root證書)，來解決的，和密鑰協商演算法無關。

當密鑰協商演算法選擇RSA時， authentication (認證)演算法 一般也選擇RSA (作為認證演算法的RSA解決了中間人攻擊的問題)。

tls1.2 定義在 rfc5246：

https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

其中對RSA做密鑰協商和認證的解釋：

F.1.1.2. RSA Key Exchange and Authentication

With RSA, key exchange and server authentication are combined. The

public key is contained in the server"s certificate. Note that

compromise of the server"s static RSA key results in a loss of

confidentiality for all sessions protected under that static key.

TLS users desiring Perfect Forward Secrecy should use DHE cipher

suites. The damage done by exposure of a private key can be limited

by changing one"s private key (and certificate) frequently.

After verifying the server"s certificate, the client encrypts a

pre_master_secret with the server"s public key. By successfully

decoding the pre_master_secret and producing a correct Finished

message, the server demonstrates that it knows the private key

corresponding to the server certificate.

When RSA is used for key exchange, clients are authenticated using

the certificate verify message (see Section 7.4.8). The client signs

a value derived from all preceding handshake messages. These

handshake messages include the server certificate, which binds the

signature to the server, and ServerHello.random, which binds the

signature to the current handshake process.

如有錯誤，歡迎指出。

---

第一個問題：

RSA做密鑰協商(密鑰交換)時，是否可以防範中間人攻擊？

答：

單就RSA本身而言，是無法防範中間人攻擊的。

和其它加密過程一樣，對RSA來說分配公鑰的過程是非常重要的。分配公鑰的過程必須能夠抵擋中間人攻擊。假設Eve交給Bob一個公鑰，並使Bob相信這是Alice的公鑰，並且她可以截下Alice和Bob之間的信息傳遞，那麼她可以將她自己的公鑰傳給Bob，Bob以為這是Alice的公鑰。Eve可以將所有Bob傳遞給Alice的消息截下來，將這個消息用她自己的密鑰解密，讀這個消息，然後將這個消息再用Alice的公鑰加密後傳給Alice。理論上Alice和Bob都不會發現Eve在偷聽他們的消息。今天人們一般用數字認證來防止這樣的攻擊。

上面引用來自於維基百科，稍微補充的一點是防止中間人攻擊的方法實際上就是身份證認證方式，目前主流方式就是數字簽名的方式，但是也是存在利用不對稱信息、時間戳、生物信息、物理信息等其它成熟或者是不成熟，公開或不公開的解決方式。關於不對稱信息這樣的情況可以參見一下我之前的另外一個答案課堂上傳紙條如何防範中間人攻擊？

第二個問題：

RSA做密鑰協商(密鑰交換)時和DH的區別是什麼？

答：

分兩點來講

一、首先說明：RSA和DH實際上根本不是一回事

RSA是公鑰加密演算法，也就是非對稱密碼演算法，一般情況下的使用流程是這樣的：

1 A通過B公開的公鑰加密信息，加密信息，發送加密後的信息給B，B通過自己的私鑰進行解密；

2 B如果想給A發送消息，就先獲取A公開的密鑰，加密信息，發送加密後的信息給A，A通過自己的私鑰進行解密。

DH是密鑰交換協議，一般情況下的使用流程是這樣的：

1 A和B通過DH協議獲得了同一個密鑰；

2 A然後用這個密鑰採用其他的對稱密碼演算法如DES AES對通信進行加密解密，傳遞給B；

3 B使用同樣的密鑰採用其他的對稱密碼演算法如DES AES對通信進行加密解密，傳遞給A。

總結一下，區別主要是：

1 RSA是用來加密解密的，DH是用來協商創造密鑰的

RSA可以用來傳遞信息，DH是用來傳遞密鑰的，想要傳遞信息還需要藉助別的加密方式。

2 使用RSA進行信息傳輸是非對稱密碼體系，使用DH進行密鑰交換的下一步使用的一般是對稱的密碼體系

使用RSA加密和解密所使用的密鑰是不一樣的，前者叫公鑰後者叫私鑰，公鑰用於加密私鑰用於解密，並且不可逆向，也就是不能用私鑰加密公鑰解密。如果A和B想進行通信的話，需要兩套（4個）密鑰。而DH交換得到的密鑰則一般是用於對稱加密的，也就是加密和加密使用的是同一個密碼，進行通信只需要一個密鑰即可。

二、然後解釋一下，如何用RSA做密鑰協商(密鑰交換)

實際上可以模擬成下面的情況：A想和B進行密鑰交換，獲得一個新的密鑰，於是A就通過B的公鑰加密了一個密鑰K（此處的密鑰相當於原文），然後將生成的密文發給B。B接到了這個密文之後使用自己的私鑰解密獲得密鑰K。於是雙方就可以愉快的使用這個K來進行後面的加密了~

這就是最簡單的RSA密鑰交換模型了。實際上考慮到前面提到的中間人攻擊的問題，因此A往往需要同時加上自己的身份認證信息。同時有些複雜點兒的情況下可能還需要B通過A的公鑰發送一系列的確認信息。

因此RSA做密鑰協商(密鑰交換)時和DH的從原理上而言是有著非常大的差距的。

第三個問題：

實際中的密鑰協商主要使用哪些演算法？

答：

抱歉..日常生活中很少單純依靠這一兩種演算法來進行的，一般情況下都是多種演算法進行組合使用。

RSA和DH都怕中間人攻擊，因此一般需要配套數字證書。而數字證書本身就是帶了每個人的公鑰的。

數字證書是一個或一組電腦文件，內載擁有人的身份數據及一組公開密碼匙。憑著數字證書文件，擁有人可向電腦系統認證自己的身分，從而訪問或使用某一特定的電腦服務。

因此其實如果非得說密鑰協商什麼用得最多，我只能說——數字證書+RSA用得最多= =

---

這件事情Google Chrome肯定走在最前：

首先，它搞了個SPDY(目前用v3)協議，建立在TLS之上，做到在一個tcp流中復用多個HTTP流，並且加入QOS特性。

然後有TLS false start，也就是去掉了TLS三次握手的最後一步，減少30%建立握手的延遲

SPDY v4相當於HTTP 2.0草案

HSTS協議，網站可要求瀏覽器必須使用HTTPS

一年前在TLS中加入了正向安全特性，(與自家伺服器通信時的)使用TLS1.2協議，與ECDHE-RSA+AES-GCM加密套件

這招使得根證書私鑰時，無法用來破解已產生的流量

現在用QUIC協議來承載的HTTPS(ChaCha20-POLY1305)

SPDY畢竟還是在用可靠的TCP，中間有一個包斷了就得阻塞著

於是出現了建立在UDP之上的QUIC，它應該是個專門為HTTP設計的協議，負責連接可靠性，HTTP流的復用，加密工作。

ChaCha20-POLY1305的性能比ECDHE-RSA+AES-GCM好

Chrome 32 promotes Chacha20/Poly1305 suite, SSL...

看樣子是ECDHE-RSA做密鑰交換

• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x13}
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x14}
• TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 = {0xcc, 0x15}

---

推薦閱讀：