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 ?

  • 1
    $\begingroup$ Does your problem similar to this? How to securely encrypt/decrypt data with a maximum chunk size? $\endgroup$ – kelalaka Mar 25 at 11:49
  • 3
    $\begingroup$ Just a question, what do need padding for in GCM mode? $\endgroup$ – Manish Adhikari Mar 25 at 11:59
  • 1
    $\begingroup$ Manish, As also pointed by Maarten below, padding is in-fact not needed. So i must rather use AES/GCM/NoPadding. $\endgroup$ – nirmalsingh Mar 26 at 12:24
  • $\begingroup$ 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 ? $\endgroup$ – nirmalsingh Mar 26 at 12:32
  • $\begingroup$ @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. $\endgroup$ – 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.

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 "blocks" 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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.