這是更好的 GCM 嗎？
對 GMAC 密鑰的兩個部分（初始化和加密 auth 標籤）使用來自分組密碼的密鑰流似乎比 GCM 產生更好的操作模式，因為成功的偽造和隨機數重用只會損害特定的（密鑰，隨機數）對，而不是損害使用給定密鑰加密的每條消息的完整性。
我可以改進一個眾所周知且廣泛使用的算法作為 GCM，這似乎令人驚訝，所以我想知道這種方法是否存在缺陷。
如果我理解您的建議，您建議通過不使用固定密鑰來修改 GCM $ H $ , 但是你卻把它變成了 nonce 的一個秘密函式 $ f_{key}(nonce) $ .
如果是這樣，我認為這實際上不會提高安全性。
對於 GCM 完整性的攻擊，攻擊者需要恢復 $ H $ . 現在，由於我們最後如何對依賴於隨機數的值進行異或，使用具有不同隨機數的不同密文並不能真正幫助攻擊者。相反，攻擊者需要做的是：
- 等待加密器出錯並使用相同的隨機數加密兩條不同的消息，或者
- 設法使用加密器也使用的隨機數生成有效的偽造（即解密器接受的偽造）。
使用 GCM，這些事件中的任何一個都允許他計算一些可能的值 $ H $ （並且產生更多的偽造品將使他能夠消除不正確的值）。
現在，根據您的建議，這些事件中的任何一個都可以讓攻擊者恢復 $ f_{key}(nonce) $ , 對於使用的特定隨機數。這對攻擊者同樣有益；然後他可以通過翻轉任意位來修改加密的數據包，使其成為他喜歡的任何內容（假設他知道/猜測明文內容；他能夠翻轉任意位並查看解密器的反應，我們可以合理地預期這是一個可行的問題，即使攻擊者事先不知道消息內容）。
攻擊者的唯一限制是他必須使用相同的 nonce 值（因為不同的 nonce 會產生不同的 $ f_{key}(nonce) $ 價值）; 然而，攻擊者可能會發現這是一個非常小的限制。
這是更好的 GCM 嗎？並不真地。
您可以為每條消息派生一個獨立的 GHASH 密鑰，而不是像 AES-GCM 那樣為許多消息使用相同的 GHASH 密鑰。它不會降低安全性。如果沒有硬體支持，成本會更高：您不能重複使用相同的 GHASH 查找表來通過定時側通道快速洩露秘密，從而驗證多條消息。
但這在安全性方面並沒有太大的改進：差異僅在對手已經成功偽造消息並由接收者確認偽造成功（或發送者已重用隨機數，這很有效）的情況下才相關就像偽造者用相同的隨機數偽造了一個）。
- 在這種情況下，使用 AES-GCM，攻擊者可以通過恢復 GHASH 密鑰來任意偽造許多附加消息。
- 相比之下，使用crypto_secretbox_xsalsa20poly1305，如果接收者要求順序隨機數或以其他方式拒絕重複的隨機數，則偽造者不能使用它來偽造多個消息，因為接收者將期望後續隨機數的不同密鑰。
僅當單個偽造的成本很小並且您真的擔心接受多少偽造時才會有所不同，這與大多數應用程序無關 - 通常我們認為單個偽造是致命的，並努力確保它永遠不會發生。
這種方法本質上是 NaCl 在 crypto_secretbox_xsalsa20poly1305 中所做的：選擇 Poly1305 密鑰作為流密碼 XSalsa20 生成的填充的前 256 位，正如Tanja Lange 在 2006年所建議的那樣。您所描述的問題在第 10 頁的NaCl驗證論文中得到了解決。30，Dan Bernstein 指出真正的安全性來自於限定下面的偽造機率 $ 2^{-100} $ . 此方法也由 TLS 使用，其
TLS_*_WITH_CHACHA20_POLY1305_*密碼套件在RFC 7539和RFC 7905中定義，在RFC 8439中更新並包含在RFC 8446中的 TLS 1.3 中。當然，Salsa20、ChaCha 和 Poly1305 也通過避免在軟體實現中存在速度和安全性之間衝突的設計來避免洩露機密。 更多關於 AES-GCM 的背景和缺點。