Implementing AES encryption for firmware distribution system

Question

I need to implement an AES encryption for firmware distribution system. I have a bootloader that can decrypt various AES variants (ECB,CBC,CTR).

When I approached this I found few issues that aren't clear to me.

1. First, there's the IV vector, which is strange to me. This vector has to be known to the encryptor and also the decryptor, does it makes sense?

2. On the decryptor side (source code) I need to input the IV vector, however, on the encryptor side (software encryptor) I can't choose IV vector. (NCrypt, AES Crypter lite, Kryptel). I know that ECB doesn't need one, but how can the software encryptor do CBC or CTR without it, is it randomly generated? If so, how the decryptor will know it?

3. Another question is regarding the actual size of the encrypted file. It must be divisible by the block size, right? So if my block size is 128, why the output of AES Crypter lite for instance produces a file size which is not divisible by 128?

Answer 1

1. Yes, the IV (not "IV vector" because IV = "initialization vector" :p) is public and is only used to introduce randomness in the encryption process to prevent it being fully deterministic, while still preserving entropy in the key material.

2. You normally send the IV along with the ciphertext (yes, it is safe if you do it right), and how it is generated depends on the mode of operation (some, such as CBC, require unpredictable IV's, while others like CTR require only uniqueness). If you have no entropy source on the encryption machine, you can keep a permanent 64-bit counter and use that with CTR, but this has a lot of gotchas and is prone to error in general, randomness is usually the safest thing to do.

3. No, only pure block modes such as ECB or CBC "require" the plaintext to be a multiple of 128 bits long, but this can be fixed through padding (adding some extra bytes to complete the final block, adding enough information in it so that the decrypting machine can remove the extra padding without confusion) - note this isn't completely safe either and can lead to ingenious attacks.

Other modes of operation don't actually work on the plaintext directly, but generate a bitstream of any length from the key (there is a limit but with modern ciphers it is essentially infinite) and exclusive-or it with the plaintext - this way the plaintext can be any length you want. E.g. if you wanted to encrypt a 300-bit message in AES128 with CTR mode, this is how it would go:

• choose your 128-bit IV
• encrypt the IV with AES128 with the key
• XOR this 128-bit block with the first 128 bits of plaintext
• increase the IV (before you encrypted it) by one and encrypt it again
• XOR this 128-bit block with the next 128 bits of plaintext
• increase the IV by one and encrypt again
• you only have 44 bits of plaintext left, so XOR the first 44 bits of the 128-bit block with the remaining plaintext bits and throw away the rest

Does it make sense?