Sun JCE 實施的 AES-GCM 模式的純文字大小限制為 2GB？

GCM 的 Sun JCE 實現被硬編碼為拒絕編碼超過 2 Gb，通過返回錯誤消息的函式 GaloisCounterMode.checkDataLength()：“SunJCE 提供程序僅支持高達 2147483647 字節的輸入大小”（消息聽起來 API 通用，但實現顯示該檢查是專門針對 GCM 的，而其他一些算法則沒有該限制）。

據記載，GCM 的純文字限制為 64 Gb，但該實現中使用的某些參數是否證明限制為 2 Gb 是合理的？

Bouncy Castle 實施不限於此大小，這是預期的嗎？

引用關於極限值的評論：

   // In NIST SP 800-38D, GCM input size is limited to be no longer
   // than (2^36 - 32) bytes. Otherwise, the counter will wrap
   // around and lead to a leak of plaintext.
   // However, given the current GCM spec requirement that recovered
   // text can only be returned after successful tag verification,
   // we are bound by limiting the data size to the size limit of
   // java byte array, e.g. Integer.MAX_VALUE, since all data
   // can only be returned by the doFinal(...) call.
   private static final int MAX_BUF_SIZE = Integer.MAX_VALUE;

換句話說，解密必須緩衝update它在 Java 字節數組中所做的整個密文（即使你分段傳遞），並且根據長期建立的 JVM 規範，Java 數組不能超過 2^31-1 個元素（或可用堆空間，如果更少，但您通常無法提前確定）。這實際上只是解密的問題，但他們顯然添加了加密檢查，因此您無法加密數據，然後無法解密它，從而永久失去您認為有價值的所有數據，一些使用者認為這是不受歡迎的。（儘管您可以使用不強制 800-36D 限制的 BouncyCastle 來解決它 - 或 OpenSSL，同上，但在 Java 中不太容易使用。）

請參閱以前

使用 AES/GCM 對 Java 中的大文件進行加密

https://stackoverflow.com/questions/23864440/aes-gcm-implementation-with-authentication-tag-in-java

https://stackoverflow.com/questions/26920906 /how-come-putting-the-gcm-authentication-tag-at-the-end-of-a-cipher-stream-require-internal-buffering-

引用自：https://crypto.stackexchange.com/questions/71712