AES-GCM 模式的純文字大小限制僅為 64GB？
根據NIST SP 800-38D第 5.2.1.1 節，明文的最大長度似乎是 2^39-256 位 ~ 64 GB。
我們有 100+GB 的基因組學文件需要 GCM 加密，所以擔心會遇到這個問題。
所以兩個問題：
- 這種相當低的限制的根源是什麼？
- 如果你超過了這個限制，會發生什麼（數學上，而不是實現方式）？
限制的根源在於 GCM 有一個使用 32 位整數的固定塊計數器。由於塊大小為 $ 2^7 $ 位，可以用 CTR 組件加密的總量為 $ 2^{39} $ 位。
將其減少 128 位的第一個限制是塊計數器從 1 而不是 0 開始，至少對於 96 位隨機數。已知 96 位以外的 Nonce 大小會降低安全性。第二個將其減少 128 位的限制是因為 CTR 組件還用於在標籤輸出之前加密最終的 GHASH。
實施方面，不應允許您越過此限制。從理論上講，安全性崩潰了。加密的數據量和生成的標籤數量有不同的安全限制。一條長消息，一個 $ n $ -bit 標籤提供 $ n-k $ 位的身份驗證安全性 $ 2^k $ 阻止消息，在您的情況下，這會將其降低到大約 $ 2^{63} $ 與 96 位標籤一起使用時，文件大小在 100 到 128 GB 之間，遠低於 $ 2^{128} $ 可以預期。最壞的情況是雜湊子鍵的恢復 $ H $ ，允許偽造具有相同密鑰的標籤。
在 ECB 模式下使用單獨的密鑰加密完整大小的 128 位標籤應該可以消除該問題，因為這些位將不再具有延展性。這可以作為 GCM 實現的包裝器來完成，只需最少的修改和幾乎 0 成本。需要修改實現以使用更大的塊計數器，並且隨機數需要更短。您將不再能夠將其稱為 GCM，但將能夠利用使 GCM 實現快速且抗時序攻擊的所有功能和程式碼。一個 32 位隨機數和一個 40 位塊計數器（沒有額外的 GHASH）將允許每個隨機數幾乎 16TB，如果您使用第二個密鑰加密標籤，則沒有更改每條消息的密鑰的限制。如果你甚至考慮這樣的事情，
該問題的其他解決方案包括不使用 GCM，而是使用 Poly1305-AES 等不同模式。OCB 模式還建議每個密鑰 64GB 的限制，CWC 模式與 GCM 具有相同的限制。