# 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 :

1. loop (read-plain-text-block-from-external-source -> encrypt -> save-encrypted-text-block-to-external-target)
2. loop (read-encrypted-text-block-from-external-source -> decrypt -> 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 ?

• Does your problem similar to this? How to securely encrypt/decrypt data with a maximum chunk size? – kelalaka Mar 25 at 11:49
• Just a question, what do need padding for in GCM mode? – Manish Adhikari Mar 25 at 11:59
• Manish, As also pointed by Maarten below, padding is in-fact not needed. So i must rather use AES/GCM/NoPadding. – nirmalsingh Mar 26 at 12:24
• kelalaka, checked the other thread as suggested by you. But that solution seems to have one limitation, decryption component should always fetch/process the same individual encrypted chucks which were earlier stored by the encryption component ? mixing parts of chunks will fail the decryption , No ? – nirmalsingh Mar 26 at 12:32
• @nirmalsingh you should add @ in front of the names to poke. Decryption only chained to the previous block. Only small amount of memory is needed to keep the value. – kelalaka Mar 27 at 22:25

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 "AES/GCM/NoPadding" for Java.