ECIES 需要 KDF
閱讀 ECIES 算法（以及一般的 elgamal），一般的智慧是在共享密鑰上使用 KDF 和 MAC，然後再使用它來加密密文。
然而，我懷疑這是因為使用的加密是 XOR（對於小於原始數據大小的數據）。
如果您使用帶有隨機 iv 的 AES GCM，我看不到共享密鑰上的 KDF 值。
對於某些協議，您不希望使用者使用錯誤的密鑰（選擇的密文攻擊）解密密文……所以使用密鑰可能會有所幫助。
但是對於隨機 IV，只要您遵循算法的共享秘密和對稱部分的標準，選擇的密文在這裡似乎是無用的。
而使用 GCM，ECIES 的 mac 部分似乎也沒有用。我認為，也許，推遲到經過更好測試的 AES/GCM 進行身份驗證似乎是更好的選擇。
請參閱：https ://en.wikipedia.org/wiki/Integrated_Encryption_Scheme
不要跳過 KDF 步驟。
ECIES 內部使用的 ECDH 密鑰協議的輸出是曲線上某個點的某種編碼。通常編碼是高度結構化的並且在位串之間不均勻分佈*。*例如，它可能是任何元素的編碼 $ x \in \mathbb Z/(2^{255} - 19)\mathbb Z $ 這樣 $ x^3 + 486662 x^2 + x $ 是正方形的，或者它可能是一對元素的編碼 $ x, y \in \mathbb Z/(2^{256} - 2^{32} - 977)\mathbb Z $ 這樣 $ y^2 = x^3 + 7 $ .
像 AES 這樣的偽隨機排列族的安全契約是密鑰必須在位串中均勻分佈。如果您違反該契約，您可能會與我們的朋友 Alex Biryukov 和 Dmitry Khovratovich 惹上麻煩。
您正在使用的曲線上的點的特定編碼結構是否會讓您在使用 AES 時遇到麻煩？我不知道，但即使我是一隻賭鳥，我也不會打賭——它會使安全契約無效，並使你進入幾乎沒有密碼學家涉足的未知領域，並且預計不會找到任何回報。
如果您通過在密鑰上使用非均勻分佈而使 AES 契約無效，則不要期望安全性。