ECIES/ECDHE/EC-ElGamal加密比較
我需要選擇一個加密系統，所以我試圖了解現有選項之間的差異。我總是發現人們將 ECIES（橢圓曲線集成加密方案）與 RSA 或 ElGamal 進行比較。很明顯，基於橢圓曲線的加密方案比 RSA 和 ElGamal 更健壯。所以，我決定使用基於 EC 的解決方案。
現在的問題是存在不同的基於 EC 的加密——ECIES、ECDHE（橢圓曲線 Diffie-Hellman 加密）、EC-ElGamal——但我一直無法清楚地解釋它們的共同特徵和差異。
有人可以為我提供這些基於 EC 的加密解決方案的參考/研究/比較嗎？或者有人可以向我解釋他們的基本區別嗎？特別是在資源消耗方面，哪一個是最好的？
修復組 $ G $ 有秩序的 $ q $ 其中離散對數較難，並固定一個標準基點 $ g \in G $ . 修復經過身份驗證的密碼 $ E_k $ 位串。
在**(EC)IES**中，大致為：公鑰是一個點 $ h \in G $ .
加密消息 $ m $ ， 發件人：
- 選擇一個指數 $ y \in \mathbb Z/q\mathbb Z $ 均勻隨機，
- 計算一個臨時公鑰 $ t = g^y $ ,
- 計算一個短暫的共享秘密 $ s = h^y $ ， 和
- 發送 $ t $ 旁邊 $ c = E_k(m) $ 在哪裡 $ k = H(s) $ 是共享密鑰的雜湊值。注意：總計算成本是兩次冪；總密文成本是一個組元素。實際上，我們正在生成一個短暫的 Diffie-Hellman 密鑰對 $ (y, t) $ 並與它達成 Diffie-Hellman 關鍵協議。
知道秘密指數的接收者 $ x \in \mathbb Z/q\mathbb Z $ 這樣 $ h = g^x $ , 計算 $ k = H(t^x) $ 並解密 $ c $ 和 $ k $ .
注意：總計算成本是一次冪。
在**(EC-)Elgamal**中：公鑰是一個點 $ h \in G $ .
加密消息 $ m $ ， 發件人：
- 選擇一個指數 $ y \in \mathbb Z/q\mathbb Z $ 均勻隨機，
- 計算一個臨時公鑰 $ t = g^y $ ,
- 計算一個短暫的共享秘密 $ s = h^y $ ,
- 精選 $ k $ 從某個子集中均勻隨機地 $ G $ ,
- **計算產品 $ z = k \cdot s $ ,**和
- 發送 $ t $ ,和 $ z $ ,旁邊 $ c = E_k(m) $ .注：總成本為二乘一*乘*；總的密文成本是兩個組元素。
知道秘密指數的接收者 $ x \in \mathbb Z/q\mathbb Z $ 這樣 $ h = g^x $ , 計算 $ k = z\cdot t^{-x} $ 並解密 $ c $ 和 $ k $ .
注意：總成本是一次取冪和一次乘法。
當您閱讀時，您可能會在這裡看到相似之處！Elgamal 基本上完成了 IES 所做的一切，*加上一些不增加安全性的額外工作，*我用粗體寫了這些工作。
在橢圓曲線的情況下，Elgamal 更加棘手。為什麼？
- 在有限域的情況下 $ G = \mathbb Z/p\mathbb Z $ , 整數模素數 $ p $ （或在哪裡 $ G = \operatorname{GF}(2^n) $ ), $ k $ 可以是（比如說）一個 256 位字元串，它作為 AES 密鑰具有雙重用途，並且解釋為 little-endian 中的整數，作為 $ G $ .
- 在橢圓曲線的情況下，位串和元素之間沒有自然映射 $ G $ ，所以你需要選擇一些隨機元素之間的對應關係 $ G $ 和（比如說）AES 密鑰——就像一個雜湊函式 $ H(k) $ . 但是如果你要散列一個元素 $ G $ 反正變成鑰匙，你還不如剛剛用過ECIES！
更糟糕的是，Elgamal 需要計算乘法 $ G $ ，不只是求冪 $ G $ ，這意味著你不能利用像 X25519 這樣的 DH 函式，它只支持等價的取冪 (’ $ x $ -Curve25519’ 上的受限標量乘法，使用快速恆定時間蒙哥馬利階梯）但不等同於乘法（‘Curve25519 上的點加法’）。
使用 Elgamal 的唯一原因是需要專家指導的特殊應用程序，例如投票系統，其中消息 $ m $ 被直接隱藏，而不是一些關鍵 $ k $ 用於經過身份驗證的密碼；僅當您利用 Elgamal 的同態屬性時才會發生這種情況，並且不適用於任意位字元串消息，而是要求您非常明智地了解消息是什麼以及如何選擇它們。
**如果你想要公鑰匿名加密，你應該使用 libsodium crypto_box_seal，這在概念上與 ECIES 相同（我所涉及的所有細節都不同）。當然，請注意，公鑰匿名加密是一種奇怪的事情，大多數應用程序（接受洩密的外部記者）不需要這樣做。 更有可能的是，如果您對知道彼此的公鑰並想要交換不可偽造的秘密消息的發送者和接收者有明確的概念，則您應該使用 NaCl/libsodium crypto_box_curve25519xsalsa20poly1305 來進行公鑰認證加密。