Elliptic-Curves
ECDH:直接還是使用臨時 ECC 密鑰對?
我正在為我的應用程序從 RSA 遷移到 ECC。
查看這些文章1 2 3,他們都建議 Alice 生成一個臨時(臨時)ECC 密鑰對eKP來向 Bob 發送消息。然後在 Alice 側生成會話密鑰 sK為 (privateKey eKP ***** publicKeyBob)。eKP 的公鑰與sK****加密消息一起傳輸。在 Bob 這邊,他可以計算出與(publicKey eKP * privateKeyBob) 相同的 sessionkey sK並解密消息。
我不明白為什麼使用臨時(臨時)密鑰對eKP比直接從 (privateKeyAlice*publicKeyBob)生成會話密鑰 sK 更好。
是因為我們每次都會重複使用相同的會話密鑰嗎?是不是因為我們必須預先同意直接生成的會話密鑰的種子或初始化向量,從而增加更多互動?還有其他原因嗎?
任何見解都非常感謝。
我不明白為什麼使用臨時(臨時)密鑰對 eKP 比直接從(publicKeyBob + privateKeyAlice)生成會話密鑰 sK 更好。
- 只有收件人才能解密消息,因為發件人的臨時私鑰已被刪除。這減輕了發件人的私鑰被洩露影響消息機密性的問題。
- 每次都會派生一個不同的共享密鑰,這有助於防止密碼磨損(過多地使用相同的密鑰)和 nonce 重用。
- 發件人的身份是隱藏的。這有時是可取的。
上述被稱為集成加密方案(IES) 的問題在於,攻擊者可能能夠用他們選擇的一種來替換消息,而接收者不會意識到這一點。
您通常希望對發件人進行身份驗證。因此,我會推薦您描述的經過身份驗證的密鑰交換的更強大版本,這樣您仍然可以在獲得好處 1 和 2 的同時對發件人進行身份驗證。它是這樣的:
- 發送者生成一個臨時密鑰對。
- 發送者使用他們的臨時私鑰和接收者的長期公鑰計算一個臨時共享密鑰。然後從記憶體中刪除臨時私鑰。
- 發送者還使用他們的長期私鑰和接收者的長期公鑰計算長期共享秘密。
- 發送者將臨時共享密鑰和長期共享密鑰連接起來,形成 KDF 的輸入密鑰材料。輸出密鑰材料用作使用 AEAD 加密消息的密鑰。
- 發件人的臨時公鑰被附加到密文中,密文被發送給收件人。
- 接收者讀取臨時公鑰,使用他們的長期私鑰和發送者的臨時公鑰計算臨時共享密鑰,使用他們的長期私鑰和發送者的長期公鑰計算長期共享密鑰,使用相同的 KDF 導出加密密鑰,並解密密文。
確保在密鑰派生中包含發件人和收件人的公鑰。否則,使用某些算法,可能會為多個公鑰派生相同的共享密鑰,這會影響發件人身份驗證並可能導致漏洞。