Data size after AES / CBC and AES / ECB encryption

Question

I would like to know the size of the data after AES encryption, so that I can avoid buffering my data after AES (on disk or in memory), mainly for sizing.

I use 128-bit AES and javax.crypto.Cipher and javax.crypto.CipherInputStream for encryption.

Several tests performed with different input sizes show that the post-encryption size calculated as follows is correct:

 long size = input_Size_In_Bytes; long post_AES_Size = size + (16 - (size % 16)); 

But I'm not sure if this formula is applicable for all possible input sizes.

Is there a way to calculate the size of the data after applying AES encryption - in advance, without taking the encrypted data (on disk or in memory) to find out its size after encryption?

Answer 1

AES has a fixed block size of 16 bytes, regardless of key size. Assuming you are using PKCS 5/7 add-on, use this formula,

  cipherLen = (clearLen/16 + 1) * 16; 

Note that if clear text is a multiple of the block size, a whole new block is required to fill. Say you have clear text - 16 bytes. The ciphertext will occupy 32 bytes.

You might want to keep the IV (initial vector) using ciphertext. In this case, you need to add another 16 bytes for IV.

Answer 2

AES, like a block cipher, does not change size. Input size is always the output size.

But AES, being block encryption, requires that the input be a multiple of the block size (16 bytes). For this, add-on schemes such as the popular PKCS5 are used . Therefore, the answer is that the size of the encrypted data depends on the padding scheme used. But at the same time, all known add-on schemes will be rounded to the next module size 16 (AES size has a block size of 16 bytes).

Answer 3

It depends on the mode in which you use AES. What you have is accurate for most block oriented modes such as ECB and CBC. OTOH, in CFB mode (for example) you simply use AES to create a byte stream that you XOR with input bytes. In this case, the output size may remain the input size, and not rounded to the next block size, as you indicated above.

Answer 4

Generally speaking, for block encryption encryption:

CipherText = PlainText + Block - (PloneText MOD Block)

the size of the ciphertext is calculated as the size of the plaintext extended to the next block. If a supplement is used and the size of the plaintext is an exact multiple of the block size, one additional block containing the supplement information will be added.

AES uses a block size of 16 bytes, which produces:

CipherText = PlainText + 16 - (PlainText MOD 16)

Source: http://www.obviex.com/articles/CiphertextSize.pdf

Note:

• CipherText and PlainText represent the size of the encryption text and the size of the plain text.

Answer 5

The AES cipher always works on 16-byte (128-bit) blocks. If the number of input bytes is not an exact multiple of 16, it is padded. That is why 16 is the “magic number” in your calculation. What you need should work for all input sizes.

Answer 6

AES runs in 128-bit (16 bytes) blocks and converts plaintext blocks to cyphertext blocks of the same length. It builds the last block if it is shorter than 16 bytes, so your formula looks right.

Answer 7

There are approaches to storing encrypted information that eliminate the need for any addition if the data size is at least equal to the size of the block. One small difficulty is that if the data size can be smaller than the block size, and if you need to restore the exact size of the data, even for small blocks, the output must be at least one bit larger than input, [i] regardless of [/ i] data size.

To understand the problem, understand that there are 256 NN files whose length is N bytes, and the number of possible files of no more than N bytes is 256 ^ N plus the number of possible files that are not longer than N-1 bytes (there is one possible file of length 0 bytes and 257 possible files with a length of not more than one byte).

If the block size is 16 bytes, then 256 ^ 16 + 256 ^ 14 + 256 ^ 13, etc. will be available. possible input files with a length of no more than 16 bytes, but only 256 ^ 16 possible output files that are no more than 16 bytes (since the output files cannot be shorter than 16 bytes). Thus, at least some possible 16-byte input files should grow. Suppose they become 17 bytes. There are 256 ^ 17 possible seventeen byte output files; if any of them is used to process inputs of size 16 bytes or less, there will not be enough available to process all possible 17-byte input files. No matter how large the input can get, some files of this size or larger should grow.