使用 XOR 導出 ECIES 的數據密鑰
我一直在考慮對 (EC)IES / RSA-KEM 進行相當簡單的增強。該方案將允許您加密數據，而會話/數據密鑰的計算可以在之後或併行執行。它還允許您為多個收件人加密。
無論如何，該計劃只是：
生成（隨機）對稱密鑰： $ K_d $ ;
使用密鑰加密數據 $ K_d $ 使用對稱密碼，導致 $ C $ ;
使用公鑰生成一個臨時密鑰對 $ \widetilde{P} $ ;
對於由以下列舉的每個收件人 $ i $ :
計算會話密鑰 $ K_i $ 通過與接收者的靜態公鑰（後跟 KDF）執行密鑰協商；
履行 $ A_i = K_i \oplus K_d $ ;
消息由一個四邊形組成 $ (i, A_i, \widetilde{P}, C) $ 在哪裡 $ i $ 只是用來表示收件人。
要解密，您只需再次執行密鑰協商，然後 $ K_d = K_i \oplus A_i $ . 對於 RSA-KEM，不需要臨時密鑰對派生，並且 $ \widetilde{P} $ 被 RSA-KEM 操作的結果替換為接收者的公鑰。
這似乎是使用秘密共享與 (EC)IES 或 RSA-KEM 相結合的簡單多接收者對稱加密方案的特定版本。顯然你必須儲存 $ A_i $ 密文的值，因此與正常的 ECIES 方法相比，這是一個缺點。
上述方法有什麼特別的問題嗎？是否有更安全/靈活/高效的方案來做同樣的事情？
正如所寫，它對對稱密碼做了一個額外的安全假設；攻擊者無法翻轉密鑰中的位（並修改密文）以獲得一些優勢。對於我們在實踐中使用的大多數密碼來說，這可能是正確的，但這仍然是一個額外的假設。
這不難解決；我們不選擇隨機對稱密鑰 $ K_d $ , 相反，我們生成一個隨機值 $ J $ , 並設置 $ K_d = \text{Hash}(J) $ . 然後，在步驟 4.2 中，我們改為設置 $ A_i = K_i \oplus J $ .
Conrado的評論告訴我，我可以將 XOR 視為一個簡單的密鑰包裝操作，它基本上只是另一種加密。在這種情況下，很明顯該方案是保密的；它只是增加了另一層加密。
當然，加密本身並不能提供完整性/真實性。ECIES 本身無法提供真實性，因為任何對手都可以使用公鑰進行加密。然而，正如雨披指出的那樣，使用 XOR 會加劇問題，因為攻擊者現在可以翻轉加密密鑰中的任何位。這可以例如啟用對密碼的相關密鑰攻擊。
出於這個原因，對密鑰的輸出進行散列可能是一個好主意，以便位翻轉平均將輸出位的 50%（雨披的解決方案）。另一種方法是使案例如 AES-SIV 而不是 XOR 來確保加密密鑰的所有位都是相關的。包裝後的密鑰將是 $ A_i $ 價值。
最後，如果該方案的輸出都使用簽名進行了身份驗證，那麼位翻轉的問題也被消除了。但是，這確實假設了一個先加密後簽名方案，它有自己的缺點（主要是簽名可以被刪除或被另一個簽名替換）。