8
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Did you find a solution to your problem? If so, could you update us about it? $\endgroup$ – Paŭlo Ebermann Oct 30 '11 at 17:24
  • 1
    $\begingroup$ 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. $\endgroup$ – Ilmari Karonen Nov 4 '11 at 16:12
8
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ so how about the question And my question is: Is it normal that AES produces encrypted blocks of varying lengths or am I overlooking something? Is it possible that an encrypted block contains \0 (i,e, null-terminating byte)? If not, am I correct if I say that the encrypted block has to be always 16-byte long? $\endgroup$ – 2523fewqf23f Nov 11 '17 at 5:39
  • $\begingroup$ @2523fewqf23f the encryption result can contain zero bytes, yes. (On average, 1/256 of all output bytes would be 0.) So using null-terminated strings for storing encrypted strings is not a good idea. $\endgroup$ – Paŭlo Ebermann Nov 13 '17 at 12:38
5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ yes, i am using ECB mode, i will check using CBC mode then. $\endgroup$ – midhunhk Jul 17 '11 at 3:52

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.