如果 AES GCM 隨機數溢出並與 GHASH 隨機數 (0^128) 衝突怎麼辦？
在 GCM 模式下使用 AES 時，GHASH 函式使用 E(0^128) 作為身份驗證密鑰 H 的初始值。IV，對於底層 CTR 模式，初始化為：
$$ prefix (application nonce) $$ $$ initial_counter (4 byte counter) $$ 這個初始計數器從 …02 開始，就像這裡解釋的那樣。我猜這是為了防止與 GHASH 函式發生衝突。
眾所周知，讓 nonce 溢出是非常非常糟糕的，因為重複 nonce 會完全破壞 GCM 模式。但是如果前綴全為零，並且計數器只溢出到 0xffffff+1 (0^128) 怎麼辦？您將擁有一個與身份驗證密鑰具有相同值的異或塊。這會破壞 GCM 嗎？
這是不允許的。一個 AES-GCM 實現，接受的消息長於 $ 2^{39} - 256 $ 位，即 $ 2^{32} - 2 $ 塊，壞了。一種根據 AES-GCM 定義的協議，消息長度超過 $ 2^{39} - 256 $ 位是無意義的。
無論如何，協議都不應該用很長的消息來定義，因為對手可能會通過發送一個非常長的消息來浪費*接收者的資源。*如果您允許 TB 長的消息，對手可能會在您意識到它是偽造的並將其丟在地板上之前浪費 TB 的記憶體。
取而代之的是，您應該將消息分解成單元，不要超過您希望在記憶體中緩衝的時間，然後才能決定將偽造品丟棄在地板上，例如 1500 字節用於 IP 數據包，或 64 KB 用於 TCP 段，或者可能是兆字節（如果適合您的應用程序）。
但是讓我們假設您確實有一個違反 AES-GCM 規則的損壞的協議和一個讓它發生的損壞的實現。如果你這樣做會發生什麼——加密一條消息 $ {>}2^{32} - 2 $ 塊，計數器被截斷為 32 位並環繞？然後：
- 知道第一個明文塊的對手可以解決 GHASH 身份驗證密鑰並任意偽造許多附加消息。
- 知道第三個明文塊的對手可以解密塊號 $ 2^{32} $ 的明文。
如果計數器進入隨機數，而不是被截斷為 32 位，那麼它是一種稍微不同的已知明文攻擊——例如，啟用對下一條消息的第一個塊的解密，假設隨機數的消息編號是連續的，而不是堵塞 $ 2^{32} $ 相同的消息。
簡而言之，不要這樣做！