Diffie-Hellman是一個密鑰交換協議，但對身份驗證沒有任何作用。

有一種高級的，概念性的方式可以看到這一點。在計算機網絡和加密世界中，您所看到的實際上是零和一併通過某些線路發送的。實體只能通過零和可以發送或不發送的零來區分。因此，用戶“鮑勃”實際上僅由其計算非鮑勃無法計算的事物的能力來定義。由於每個人都可以購買同一台計算機，因此Bob只能通過Bob僅有Bob知道的某些價值的知識而成為Bob。即時生成一個隨機秘密值並使用它。每個人都可以做這樣的隨機生成。協議中沒有任何地方只有特定的Bob可以做的任何操作。因此，該協議無法實現任何形式的身份驗證-您不知道與誰交談。如果不進行身份驗證，則模擬是可行的，其中包括同時進行雙重模擬（通常稱為中間人）。最好的情況是，原始的Diffie-Hellman提供了一個較弱的功能：儘管您不知道與誰交談，但您仍然知道您在整個會話中都與同一個實體交談。

單一的加密算法不會幫助您。任何重要的通信協議都會組合幾種算法，從而實現一定的安全性。一個典型的例子是 SSL / TLS；另一個是 SSH。在SSH中，使用Diffie-Hellman密鑰交換，但是服務器的公共部分（其 g ^{b sup> mod p ）由服務器簽名。客戶端知道它正在與正確的服務器通信，因為客戶端（從先前的初始化步驟中）記住了服務器的公鑰（通常為RSA或DSA類型）；在上面解釋的模型中，合法服務器是通過其對與客戶端記住的公共密鑰相對應的簽名私有密鑰的了解來定義的，並與模仿者區分開。該簽名提供了身份驗證；然後Diffie-Hellman產生一個共享密鑰，該密鑰將用於加密和保護該連接的所有數據交換（使用一些對稱加密和MAC算法）。}

因此，Diffie-Hellman不會這樣做只需您自己需要的所有內容，它仍然提供有用的功能，即密鑰交換，您不會從數字簽名中獲得該功能，並且提供了加密實際交換的數據所需的臨時共享密鑰。 / p>

Tom對於為何Diffie-Hellman不能安全地抵制中間人提供了很好的解釋。現在，這可以回答OP的原始問題，但可能會使一些讀者有一個（合理的）後續問題：為什麼我們不僅僅使用公共密鑰（非對稱）加密來確保消息的機密性，並完全丟棄D-H？有一些原因不這樣做：

• 有些算法僅支持簽名，不支持加密消息（例如ECDSA）
• 對稱加密和解密是一種比非對稱執行快很多
• 最重要的是，我們要確保轉發保密。畢竟，您的一個通信合作夥伴的私鑰在某個時刻被洩露並非不可能。現在，如果您僅依靠非對稱加密，則攻擊者可以回想起曾經發送給該夥伴的所有消息。相反，如果我們使用Diffie-Hellman-更確切地說是短暫Diffie-Hellman ，我們將為每個通信會話生成一個新的DH密鑰對，然後將其丟棄（=不存儲）。 ，這意味著以後無法解密我們的消息。

交換DH密鑰後，雙方都知道他們計算了什麼密鑰。如果中間人沒有滲透到該連接，則雙方將具有相同的密鑰。如果連接已斷開，則它們將具有不同的密鑰。如果有一方可以詢問另一方正在使用什麼密鑰的方法，則中間人只有能夠以與合法方相同的方式做出響應，才能被發現。儘管通常使用數字簽名來回答問題，但要使模擬變得困難，它也可以通過語音通信之類的方式來提出/回答。如果語音應用程序向參與者顯示了當前的加密密鑰，並且參與者任意選擇了一個範圍和一個受歡迎的電影明星（例如Marilyn Monroe），並要求對方以他們最好的Marilyn Monroe語音讀取第15至第25位數字，擁有數字的真正參與者將能夠快速，流暢地這樣做，並且在沒有MITM攻擊的情況下，數字將與第一方看到的數字匹配。中間人攻擊者可以毫無問題地發現問題，並且在一定時間內可以偽造瑪麗蓮·夢露（Marilyn Monroe）的語音來模仿合法通訊員的語音文件，但會用適當的數字很難像真正的那樣快。

DH通常不能抵抗中間人攻擊。

如果Alice和Bob（A<-> B）可以設置共享機密。然後，Frank可以與Alice（A<-> F）設置共享密鑰。同時，Frank可以與Bob（F<-> B）設置第二個（不同的）共享密鑰。然後，Frank可以解密A-> F消息，然後重新加密並將其發送給bob F-> B &，反之亦然。

*因此，您需要某種方式來確保消息實際來自（由）愛麗絲。既可以使用先前共享的機密（通過其他渠道提供），也可以使用證書頒發機構（以代理信任）。或其他某種方法。

如果您只稍微信任CA，則Alice可以與Bob設置DH共享密鑰，並使用CA中的證書對消息進行簽名。鮑勃檢查郵件是否由CA簽名。弗蘭克無法偽造消息，因為它們沒有必需的證書。

現在，愛麗絲和鮑勃擁有一個共享的秘密。弗蘭克無法偽裝成中間人。但是，CA不參與創建共享機密（僅對沿途發送的部分進行簽名），因此CA也不能扮演壞角色。即使弗蘭克用5美元的扳手威脅他們。

*這有點簡單，但這是普遍的想法。

我必須在湯姆·里克（Tom Leek）的回答中說得更準確一點：“在SSH中，使用了Diffie-Hellman密鑰交換，但是服務器的公共部分（其g ^{b sup> mod p）已簽名由服務器。”}

實際上，整個DH密鑰交換都已簽名。僅簽名g ^{b sup> mod p是不夠的：僅通過連接SSH服務器並稍後重播[SSH-TRANS]數據包就可以欺騙SSH服務器。那不能證明對當前會話數據的了解。省略g a sup> mod p，SSH ID字符串和協議協商。}

在雙方交換SSH ID字符串和協議協商消息後，身份驗證完成，客戶端發送包含g ^{a sup> mod p的Diffie-Hellman密鑰交換消息。}

服務器計算g ^{b sup> mod p並哈希所有重要信息：H = hash（context || sig_pub || g a sup> mod p || g b sup> mod p || g ab sup> mod p）和context = SSH ID字符串||協議協商消息。}

然後它簽名握手哈希：sig = signature（sig_priv，H），然後將（sig_pub，g ^{b sup> mod p，sig）發送回客戶端。}

那樣，除非他們破壞了簽名算法，否則沒人能欺騙任何東西。

這是英語的語言描述能力失敗的地方。如果帶外第三方實體能夠幫助分配密鑰和/或驗證身份，則Diffie Helman可以抵制。您會在文獻中發現，它最主要的定義是圍繞收件人的身份或在大多數情況下，與密鑰或證書相關的人員的身份的信任網絡。