關於使用 DES 與一位使用者進行安全通信的初學者問題
我目前正在學習加密，有人問我一個問題：
如果客戶只有 DES 系統，我怎麼能保護消息，因為 DES 不安全。
我正在研究這個，我遇到了一個混合密碼系統，其中使用了對稱密鑰密碼系統 (DES) 並且還使用了公鑰密碼系統。
這是一個可行的選擇，還是雙方都需要使用這兩個系統？
任何幫助將非常感激。
是的，問題類似於“客戶想要保護他們與 <company> 的通信，但客戶只能使用 DES 加密系統並且沒有與 <company> 共享的 DES 密鑰。他們如何在沒有幫助的情況下安全地通信來自第三方？”
那麼，客戶可以致電公司並安排與代表會面。在與代表會面並確認他們確實在為公司工作後，客戶應交給代表一張便條（或拇指驅動器），上面有隨機選擇的 DES 密鑰，並說“這裡，用這個與我進行安全通信。”
（實際上，他們應該交給代表的兩個或三個DES 密鑰，並告訴他們使用三重 DES，因為現在單個 DES 密鑰太短，無法抵抗暴力攻擊。）
如果客戶和公司代表不能實際見面，他們也許可以使案例如Diffie-Hellman 密鑰交換協議來獲取共享的秘密值，然後將其提供給密鑰派生函式以將其轉換為共享（三重）DES鑰匙。然而，單獨的 Diffie-Hellman 並不能安全地抵禦主動中間人攻擊——如果沒有某種先前共享的秘密，客戶和公司代表就無法確定他們確實交換了密鑰彼此之間，而不是他們每個人都與攔截原始 Diffie-Hellman 交換的某個第三方交換了密鑰（並不斷攔截他們隨後的通信以解密、讀取、重新加密和中繼任何消息）。
如果客戶和公司確實有某種共享秘密——比如密碼——那麼他們就有可能使用經過密碼驗證的密鑰交換來將密碼“升級”為共享（三重）DES 密鑰。一種相當簡單的方法是，他們首先進行正常的匿名 D-H 密鑰交換，然後將生成的共享秘密值與密碼連接起來，並通過故意緩慢的密鑰派生函式將其輸入（三重）DES鍵。這樣可以確保，如果不知道密碼的中間人試圖攔截密鑰交換，他們將無法與任何一方推導出匹配的 DES 密鑰。
（這個簡單的協議確實有一個弱點，中間人欺騙了 D-H 密鑰交換並使用正確派生的密鑰截獲了至少一個 DES 加密的消息，現在有足夠的資訊來對密碼。因此該方案的安全性完全取決於密碼的強度和 KDF 的緩慢性。至少，客戶和公司應盡量減少攻擊面，僅使用該協議一次，交換適當的共享密鑰，以後不再重複；更好的是，他們應該使用更高級的 PAKE 協議，該協議使用互動式零知識證明來說服認證方他們都具有相同的密碼和 D-H 密鑰。）
根據我們可能做出的額外假設，也可能有其他選擇。例如，如果公司有一個私有的非對稱加密密鑰，而客戶知道對應的公鑰，那麼客戶可以簡單地生成一個隨機（三重）DES 密鑰，使用公鑰對其進行加密，並將加密後的密鑰發送給公司知道，即使它被截獲，也只有正確的接收者才能解密它。
（當然，這只會讓客戶知道他們正在與正確的公司交談；它並不能幫助公司知道客戶真的是他們所說的那個人，因為公開的公鑰可能是任何人都可以使用。此外，它假定客戶以某種方式已經知道他們擁有的公鑰確實屬於公司，而不是攻擊者。）
即使公司只有一個用於數字簽名算法的私鑰，仍然可以使用它來安全地建立共享（三重）DES 密鑰。例如，客戶和公司可以從 D-H 密鑰交換開始，如上所述，然後公司可以簽署他們的 D-H 秘密值（最好在散列之後，以確保簽名不會洩露有關密鑰的資訊）和將簽名（通過 DES 加密通道）發送給客戶，客戶使用公司簽名密鑰的公共部分對其進行驗證。
無論如何，我的觀點是這個問題實際上與 DES 無關。這實際上是一個密鑰協議問題，解決方案取決於客戶和公司擁有什麼樣的現有共享資訊（以及他們許多使用的除了 DES 之外的其他工具類型）。如果他們真的對對方一無所知，攻擊者無法欺騙，那麼問題嚴格來說是無法解決的：如果客戶**無法判斷他們是否在與正確的公司交談，攻擊者可以攔截客戶的消息並回复他們，假裝是公司。