Encrypted text length in AES

I have created an application that will be able to read any file and encrypt it using AES Encryption. For efficiency, I am reading a block of data, encrypting it and so on. So for decrypting, I just have to read each block and decrypt using the same key to get the data back. This was what I had in mind.

But it turns out that the size of each encrypted block varies, so I am currently saving the encrypted block size before each block into my encrypted file.

And my question is: Is it normal that AES produces encrypted blocks of varying lengths or am I overlooking something?

(I'm using a padding, as my input block size is not always a multiple of the AES block size.)

I faced the same issue when I had used C++ a few years back, and now as3crypto library for an AIR application while implementing the same application.

-
Did you find a solution to your problem? If so, could you update us about it? –  Paŭlo Ebermann Oct 30 '11 at 17:24
Are you perhaps treating the encrypted blocks as null-terminated strings? If so, there's your problem: it's quite possible for the output of AES (or, indeed, pretty much any other modern encryption algorithm) to contain null bytes. –  Ilmari Karonen Nov 4 '11 at 16:12

AES should always take in and return 128 bit block sizes. On a different point, it sounds like you are using ECB mode and should consider changing to use a stronger block cipher mode, like CBC.

-
yes, i am using ECB mode, i will check using CBC mode then. –  silverback Jul 17 '11 at 3:52

Plain AES is a block cipher, which can only encrypt 128-bit blocks (i.e. 16 bytes at once).

To encrypt longer pieces of data, one would normally create a stream cipher from the block cipher, by using one of several modes of operation. The simplest (and most insecure) one is the electronic code book mode (ECB), which (for the same key) always produces the same ciphertext for the same plaintext block. Normally one thus would use one of the other modes (like CBC, CTR, ...), each having different advantages.

If you need only sequential access to the whole file, any of these modes will do, as you can always decrypt the file sequentially.

If you need some kind of random access to specific parts of the file, you would break it down into parts which each could be accessed individually. Each of them would then be encrypted as essentially a separate stream, i.e. starting with the initialization vector, and including (if necessary) the padding to fill the last 128-block.

You would also want an index to the parts, so you know which part to access.

Alternatively, you could use CTR mode, which essentially allows random access to the file, only knowing the nonce and the block index, without the need to read or decrypt the blocks before or after the desired block.

-