使用 ECDHE 和 AES-GCM 的公鑰加密
以教科書為例，Alice 和 Bob 希望通過不安全的通道（網際網路）使用加密消息進行安全通信。Alice 和 Bob 決定使用 ECDH（使用每個會話生成的臨時密鑰）並開始使用曲線 P-256 生成一個公鑰/私鑰對 - 使用 SHA1PRNG 隨機性。Alice 將她的公鑰發送給 Bob，Bob 使用 Alice 的公鑰和他的私鑰生成一個秘密密鑰。Alice 使用 Bob 的公鑰和她的私鑰做同樣的事情。
可能坐在中間的 Eve 無法解決 EC 要求的離散對數問題，因此無法計算密鑰。如果夏娃真的在正確的時間坐在中間，她本可以將她的公鑰發送給愛麗絲和鮑勃。我不確定 ECDSA 是否在這裡發揮作用，但我假設 Alice 和 Bob 會通過另一種方法比較他們的公鑰指紋來驗證他們是否正在相互交談。Alice 和 Bob 現在擁有相同的 256 位密鑰，可用於對稱 AES-GCM 加密。
問題 1 - AES-128 需要 128 位密鑰，而 AES-256 建議使用比 P-256 更強的 ECDH 曲線 - 這意味著 ECDH 生成的密鑰總是比加密算法所需的長。我認為推薦的方法是使用像 HKDF 這樣的 KDF 函式，但是採用 SHA-256 雜湊並將其直接用於 AES-256 或將其截斷以用於 AES-128 的安全含義是什麼（Alice 和 Bob 正在使用 Java沒有 HKDF 的本機實現，我認為嘗試編寫自己的實現不是一個好主意）。
使用經過批准的方法，他們設法獲得了相同的 128 位加密密鑰。Alice 首先向 Bob 發送一條消息——她生成一個 96 位隨機 IV（她確認她不會再使用相同的 IV 和相同的密鑰）。她指定 128 位的身份驗證標籤長度並加密消息（她不包括任何其他經過身份驗證的數據）。她在密文前面加上 IV 並發送給 Bob。Bob 然後恢復 IV 並解密消息 - 他知道消息沒有被修改，否則身份驗證標籤將不正確。
問題 2 - ECDSA 在這種情況下提供什麼優勢，還是我把事情搞混了？假設 Alice 和 Bob 已經驗證了公鑰指紋屬於彼此，只有 Bob 擁有他的私鑰（在會話期間儲存在記憶體中） - Eve 無法使用正確的密鑰加密消息，因為她沒有所需的私鑰？為了讓 Alice 能夠解密消息，它必須由 Bob 加密。
我認為推薦的方法是使用像 HKDF 這樣的 KDF 函式，但是採用 SHA-256 雜湊並將其直接用於 AES-256 或將其截斷以用於 AES-128 的安全含義是什麼（Alice 和 Bob 正在使用 Java沒有 HKDF 的本機實現，我認為嘗試編寫自己的實現不是一個好主意）。
如果您可以訪問 HMAC，HKDF(-Expand) 很容易實現，因為對於短密鑰來說，它只是
HMAC(s, 0x01)共享s密鑰；一個可選的上下文字元串可以附加到 1 字節。但是，只是一個雜湊也可以。ECDSA 在這種情況下提供什麼優勢，還是我把事情搞混了？
如果您只需要保證隱私和真實性，則無需將 ECDSA 添加到混合中。具有來自 ECDH 交換的共享密鑰的 AES-GCM 就足夠了。但是，還有其他兩種情況可能使 ECDSA 在這裡有用：
- 首先，ECDSA 是 Alice 和 Bob 驗證密鑰交換中使用的臨時密鑰的一種方式，就像您在評論中建議的那樣。如果他們已經知道彼此的 ECDSA 密鑰，他們可以使用它們來簽署和驗證臨時密鑰。
- 如果他們需要不可否認性，他們可以在加密之前使用 ECDSA 對消息進行簽名。僅使用 ECDH 和 AES-GCM 無法證明 Alice 或 Bob 是否編寫了特定消息，因為兩者都可以在相同的共享密鑰下進行加密。簽名將允許 Alice 向其他人證明 Bob 說了些什麼。（您是想要不可否認還是要避免它取決於案例。）