為什麼在執行 DH 時使用數字簽名？
假設伺服器有一個每個人都知道與之關聯的公鑰，它可能被硬編碼到瀏覽器中或由某個 CA 簽名。
您在任何時候都不需要伺服器用它簽署任何東西，客戶端生成一個臨時密鑰對，使用伺服器的公鑰執行 DH 並發送他的臨時公鑰，然後是對稱加密的消息。
現在只有伺服器和客戶端擁有共享密鑰。客戶端可以拒絕任何不包含使用對稱密鑰加密的內容的回复。
如果需要前向保密，則伺服器的臨時密鑰可以在它回复時包含在加密消息中。那麼為什麼所有的方案都在密鑰交換中使用數字簽名呢？
tldr：如果你能夠驗證一個簽名，你就有一個可以使用的公鑰，如果你有，那為什麼不直接用它做 DH 呢？
原則上，如果伺服器有一個長期的秘密指數 $ s $ ，和一個長期的公共點 $ S = g^s $ 客戶端願意相信，那麼這足以讓客戶端向伺服器發送經過身份驗證的機密消息：客戶端選擇 $ c $ 隨機計算 $ C = g^s $ , 計算 $ k = H(S^c) = H(g^{sc}) $ , 並使用 $ k $ 作為對稱認證加密的密鑰。
與簽名不同，沒有第三方可驗證性；任何可以驗證對話身份驗證器的人也可以偽造它們。如果您想要快速擦除密鑰，那麼您可以使用此經過身份驗證的通道來執行臨時Diffie-Hellman 密鑰協商，例如Signal 協議（技術文件）所做的那樣。
為什麼我們*不在例如*SSH 和 TLS 中這樣做？** 主要是為了歇斯底里的葡萄乾，我想。TLS 中籤名的使用可以追溯到最初的 SSL，我猜想它是從帶有 x.509 證書的 x.400 電子郵件中使用簽名派生的。
對於證書鏈，您需要簽名，因為您需要第三方可驗證性，而當您已經擁有認證錘時，為什麼還要設計另一種公鑰認證機制呢？對稱驗證器，即MAC，是使用 DH 的公鑰驗證器所需要的，直到 90 年代中期開發 HMAC 時才真正流行，儘管該概念於 1974 年首次發布。
為什麼我們現在*不在例如SSH 和 TLS 中使用已經部署的證書中的公鑰來執行此操作？** 其中許多是 RSA 密鑰，僅適用於簽名或（非臨時）密鑰協議，如 RSA 密鑰協議，不適用於臨時 Diffie-Hellman 密鑰協議。 從技術上講，靜態 Diffie–Hellman 公鑰的 x.509 證書有標準，但這些標準很少使用。
為什麼*我們不在任何*協議中使用它？** 好吧，我們做到了。直到2004 年 OTR之前，沒有不可否認性的公鑰身份驗證才流行起來，儘管它取代電子郵件簽名的提議可以追溯到 2000 年。dnscurve協議旨在將伺服器的長期 X25519 公鑰安裝在標記的 DNS 標籤中，以便您可以將其兼容地放入標準 NS 記錄中。Signal 協議廣泛使用長期 DH 密鑰進行身份驗證。Noise 協議框架目前根本不使用簽名；所有身份驗證都是通過長期 DH 密鑰進行的。
為什麼我們不將它用於已經為簽名部署了 Ed25519 密鑰的協議？** 我們可以，例如使用XEdDSA，但需要有人實現它才能實現。我不能代表所有協議！您是否會將更新檔發送到 OpenSSH 以使用 XEdDSA 為已部署的 X25519 密鑰實施公鑰驗證器，並在郵件列表上爭論以證明額外的複雜性是合理的，當簽名已經工作時？當你設計一個新協議時，你會使用長期的 DH 密鑰而不是簽名嗎？
當然，請注意，僅使用長期 DH 密鑰進行身份驗證不允許密鑰擦除，因為密鑰是長期的。因此，對於快速密鑰擦除，您仍然必須使用臨時 DH 密鑰來組合它，正如我在最近一篇關於 WhatsApp 工作原理的理想化的文章中所總結的那樣。
這裡的短暫意味著密鑰可以在會話之後被擦除，並且它的所有恢復令牌都已被擦除，因此伺服器的長期身份密鑰的洩露不會啟用對過去會話的追溯解密。這個屬性有時被稱為前向保密，這個術語在擦除發生時*會很模糊，這對於使用 TLS 恢復令牌特別重要。