在需要重新生成密鑰或 NONCE 之前使用 AES-GCM 將文件加密到磁碟時，安全的最大消息大小限制是多少
NIST 建議的一般限制如下：
最大加密明文大小 ≤ 2 39 - 256 位；
最大處理的附加認證數據 ≤ 2 64 - 1 位；
這個堆棧溢出答案 ( https://crypto.stackexchange.com/a/20340/44337 ) 暗示 2 39 - 256 位加密明文的最大呼叫量太大，“應該建議你遠離那些限制。” 在這種情況下，什麼樣的限制才有意義，我可以優化生成密鑰的使用，但又不會降低密文的安全性？達到 2 32 個操作的加密操作的最大呼叫被認為太危險了嗎？我應該繼續將呼叫次數限制為 2 31嗎？或者可能是 2 16的一半? 我有能力隨時為任何文件生成新密鑰。所以問題是什麼是最大密鑰使用和安全性之間的良好權衡。顯然，我不能使用相同的密鑰處理超過 2 39 - 256 位。
一些關於堆棧交換的評論提到與同一密鑰一起使用的 96 位 NONCE 的最大數量是 2 28.9，這將使安全性保持在 2 64以上 （是每個密鑰或每個（密鑰，隨機數）的 AES-GCM 的長度限制對？）。在需要重新生成密鑰或更改 NONCE 之前，我嚴格地試圖弄清楚具有相同密鑰/NONCE 的已處理消息的最大安全大小是多少。
另一個堆棧交換問題直接處理加密消息的大小，但沒有給出安全最大大小的建議（AES-GCM 模式的純文字大小限制僅為 64GB？）。相反，它表明安全性取決於標籤和加密消息塊的數量。關係是n - k，其中n是標籤長度，k是加密塊的數量。因此，對於處理大小為 2 32塊的消息的 96 位標籤，這給了我們 96 - 32 = 64 或 2 64的安全性。這是相當低的。其他評論者說，以每塊大約 10GB 的速度對加密進行分塊。但是我們要實現什麼樣的安全呢？
似乎 AES-GCM 不太適合加密大文件，除非在某些安全限制（例如 1 GB 或 10 GB 等）下適當地對文件進行分塊時增加更多複雜性。使用 ChaCha20/Poly1305 可能是更好的解決方案，但這超出了這個問題的範圍。在決定更改密碼之前，我想看看 AES-GCM 的目前限制是多少。
AES-GCM 的安全性分析以最大限度地使用密鑰
注意：我不是密碼學家。因此，我的分析中可能存在錯誤。請幫助我糾正我的錯誤並建立在這個答案之上，這樣我們就可以共同得出正確的結論。
AES-GCM 設置
- 密鑰：256 位
- IV 96 位（確定性構造）
- 標籤：128位
分析
GCM的內部實現使用 CTR 操作模式，計數器為 32 位整數，將加密操作的呼叫次數硬限制為 2 32 個塊。前兩個計數器值是保留的，所以這給了我們 2 32 - 2 次呼叫。這對應於 NIST 標准設置的第一個限制，即可以使用單個密鑰/IV 對處理的最大2 39 - 256 位。
IV 建議為 96 位，因此我將在分析中使用它。在一般確定性構造中，IV 由一個 64 位（呼叫欄位）計數器和一個固定的 32 位欄位組成。32 位欄位在我們的討論中並不重要。包裝 64 位計數器將進行 2 64次操作，遠遠超過底層 CTR 操作模式的實際最大值：2 32 - 2。因此，兩者中的最小值是 GCM 模式允許使用的：2 32 - 2。
GCM 模式的最後一個安全參數是認證標籤長度。我假設標籤長度為 128 位，因為它是大多數人推薦的。從理論上講，所有安全散列函式至少有一個從生日悖論中定義的弱點。它指出，為了獲得 50% 的碰撞機會，您需要執行一半的雜湊輸出長度操作數。對於我們的 128 位雜湊，這為我們提供了 2 64的安全性，有 50% 的碰撞機會。這與我們期望的 2 128安全性相矛盾，但這是我們必須處理的。由於雜湊操作的次數仍然受限於實際內部 CTR 操作模式為 2 32 - 2，因此認證安全性為 2 96- 2 對於 128 位標籤來說相當高。目前，這是任何攻擊者都無法企及的。
Niels Ferguson 對 GCM 的消息偽造攻擊進一步限制了身份驗證標籤。它主要針對標記的截斷版本，但我們將查看完整的 128 位標記。攻擊使用大約 2 t（n 位）塊來成功，其中 t 是標籤長度。這是來自Rogaway的攻擊的解釋
攻擊者要求具有 2 (t / 2 + 1)個塊的單個消息的 MAC，然後在大約 2 (t / 2)次預期嘗試後再次偽造 2 (t / 2 + 1)個塊的消息。例如，針對 32 位標籤的情況，攻擊首先要求 2 個17塊的單個消息的 MAC。之後，它需要大約 2 16 個驗證消息，每個驗證消息又是 2 17個塊，直到預計第一次偽造。
這不是 128 位身份驗證標籤的問題，因為為了成功，您需要以大小為 2 (128 / 2) 128 位塊的消息的標籤開頭。這是不可能的，因為內部 CTR 限制是 2 32 - 2, 128 位塊。
然而，雜湊的理論研究偏離了底層 GHASH 算法的實際實現。它具有已確定的問題，這些問題通常會在一定程度上降低其安全性。因此，我們最好遠離相同密鑰 H 的 2 64次操作的理論生日界限。但由於我們的底層 CTR 構造只有 2 32 次操作的上限，這將我們的安全參數從 2 64提高到 128 - 32 = 96 或 2 96對於同一個鍵 H。
結論
在考慮了以上所有因素之後，限制安全因素似乎是 AES-CTR 的內部 CTR 操作模式，它最多處理 2 32 - 2 個塊。如果我們處理該數量的塊，我們仍然應該實現高安全邊際，並且不需要進一步的數據分塊。因此，在使用 128 位標籤和 96 位 IV 時，可以安全地使用全系列 AES-GCM 加密並使用相同的密鑰處理 2 39 - 256 位純文字數據。
更新
我在一篇博文中總結了我對如何正確使用 AES-GCM的研究。