AES/GCM/PKCS5Padding giving issues while AES/CBC/PKCS5Padding works fine for my use case I have a requirement to read-encypt-save plus its reverse i.e. read-decypt-save files through chunk/block mechanism (single operation not feasible because of huge(GBs) file sizes).
So essentially the two functionalities should work as below :

loop (read-plain-text-block-from-external-source -&gt; encrypt -&gt; save-encrypted-text-block-to-external-target)
loop (read-encrypted-text-block-from-external-source -&gt; decrypt -&gt; save-plain-text-block-to-external-target)

Also requirement is to have flexibility to use different chunk/block sizes while encryption / decryption. so either party (Encrypter or Decrypter) does not know other's size at all.
Now we have successfully implemented this functionality using AES/CBC/PKCS5Padding but we are facing issues while trying the same using AES/GCM/PKCS5Padding. Decryption was returning blank plain chunks and we finally received aggregated plain chunks at loop completion. this stops us from saving individual decrypted-chunks to external target during single iteration of the loop.
Any idea if AES/GCM/PKCS5Padding is even an option for our use case ? what must be causing above issue ?
AES-GCM uses AES-CTR to create confidentiality internally. Counter mode turns AES into a stream cipher, where the plaintext is XOR'ed with a generated key stream. This key stream can be applied bit by bit or - practically speaking - byte by byte (with the leftover key stream bytes after encrypting the last counter simply being discarded). Specifying any padding at all is a waste of effort for a stream cipher. Instead you should be using &quot;AES/GCM/NoPadding&quot; for Java.
I would not bet that other implementations allow GCM with PKCS#5 padding. Furthermore, it is the question if that mode would always be using no padding (as it isn't required), 1 byte of padding (since a stream cipher works with &quot;blocks&quot; of a single byte) or up to 16 bytes of padding (because the block size of AES is 16 bytes).
GMAC, the internal MAC operation of GCM also requires padding as it operates on 128 bit values. But as common with MAC algorithms, only one particular padding is used, so it doesn't need to be specified - it is not a configuration option.