Rsa
為什麼在簽名中配對時 ECDHE 是安全的？
我想要幾個 Computerphile 關於橢圓曲線 Diffie-Hellman、數字簽名和 TLS 的影片。
在大多數情況下，我什麼都懂，但有些事情困擾著我。Computerphile 製作了一段影片，解釋如何將 RSA 與 ECDHE 結合使用，以確保沒有人在中間弄亂消息。該影片的標題為密鑰交換問題。我不明白如何引入可以用公鑰解密的加密簽名的 Diffie-Hellman 參數確保沒有人在中間？
是什麼阻止了中間人用公鑰解密參數，就像客戶端用他們的私鑰重新簽名並將其發送給客戶端一樣？簽名也是如此。如果有人在進行數字簽名，他們不能欺騙驗證者嗎？
例如：
- A（簽名者）通過B（B在中間；B將doc轉發給C）將要驗證的文件發送給C（驗證者）。
- A 通過 B 將加密的 doc 發送給 C。
這意味著如果 B 用他們的私鑰對文件進行簽名，那麼當 C 將驗證它是用 C 的公鑰簽名時。
使用靜態密鑰對的想法確實是密鑰交換中的數據得到簽名。簽署什麼並不重要，只要對手不能執行密鑰交換即可。
為了驗證簽名，簽名者的公鑰需要被信任。這是您在描述中缺少的內容。如果驗證者只接受一個密鑰或一組密鑰，那麼攻擊者的簽名將被拒絕，簽名驗證失敗並且密鑰不會被建立或使用。
那麼如何信任公鑰就成了下一個問題。這不是密鑰協商協議的一部分。一種方法是明確信任一個公鑰，例如通過電話驗證公鑰的指紋。也可能是密鑰是通過受信任的渠道上傳的；例如，這是經常使用 SSH 公鑰執行的操作。
對於 TLS，信任是通過信任證書頒發機構的（根）證書來建立的。然後，它們只負責為可以表明它們控制某個域的實體創建證書。這些證書都包含該域以及用於驗證的公鑰。此結構稱為 PKIX：使用 X.509 證書和證書撤銷列表的公鑰基礎結構。
一些注意事項：
- 我已經刪除了對密鑰協議或簽名生成/驗證算法的任何提及——使用的算法對這個問題並不重要。
- 也可以信任（靜態）Diffie-Hellman 公鑰，但您會失去前向保密性- 如果該密鑰對的長期私鑰洩露，對手可以重播密鑰協議並解密所有消息（並且它也使 PKI 複雜化）。
- 簽名生成與簽署消息或消息雜湊不同，驗證與“使用公鑰解密”不同 - Diffie-Hellman 公鑰將與簽名一起以明文形式發送。
- 建立會話後可能需要額外的訪問控制——這就是為什麼用於創建連接的證書通常被傳遞到後端並用於某種訪問控制系統的原因。