Question AES know what the IV is

Krammig

Member
Joined
Jul 22, 2019
Messages
8
Location
Australia
Programming Experience
10+
A question please.

What I am not clear on is - does the Decryption side need to know what the IV is for a particular encrypted file.

By this I mean lets say a file is encrypted using - " .IV = Guid.NewGuid().ToByteArray() "

When the encrypted file is is received buy someone else, do they (their decryption app) need to know what the origin IV is, or is that just inherently buried in the encrypted data in the first block, and the AES CBC decryption algorithm handle the retrieval if the IV and this gets access to it. ?

Thanks
 
The IV in AES is a salt. Its purpose is to prevent the first block of data from being encrypted twice to the same output, because of a particularity of the algorithm. You often hear the term "salt" in hashing algorithms, but an IV is exactly the same thing, and has the same purpose, but in AES it's used to encrypt the first block, rather than being inserted as the first block of a hashed value. The ultimate purpose is to prevent the same data being encrypted with the same key twice yielding the same output. It's supposed to be unique and random(ish), be the same size as your block size (128 bits usually), but it's not secret. It has to be different for each encryption, it shouldn't be reused. You prepend it to the encrypted data before distributing the cipher text encrypted with it, and the receiver extracts it before decrypting with the key. Usually a GUID is ideal, as it is both unique and random(ish), and the correct length, and available on demand with a one liner.
 
Thanks Herman.

Yes I did read that the IV should be (and in fact must be apparently particularly for CBC) unique each time and that it was not necessary to keep that private. So thanks for confirming that.

What I was hoping (but could not understand how it could be so) is that once the IV was created it would be automatically prepended to the encrypted data (by the algo code) and that the decryption part of the algo would then strip that out and use it accordingly.
For me it sort of defeats the purpose of having to "build" the final data being sent and then having to dismantle it at the other end to derive the original IV.
 
It may not make much sense from the eyes of an outlooker, but it makes brute forcing the message if you don't have the key much more difficult, because it takes much more time to compute each password. It also protects hashing algorithms by preventing the use of "rainbow tables", where hashes are pre-computed from lists of stolen and/or generated password lists, and then directly compared to a hash list. You can also mix the IV into the output ciphertext by using reversible algorithms to obfuscate the salt. For example the salt could be reversed and encoded into odd byte positions of the output ciphertext. It's simple obfuscation, but can be relatively effective if you also keep your code secure. Anything that slows down an attacker will cause him to rethink if he really wants to spend more time trying to break it open.
 
Last edited:
Thanks Herman, that makes a whole lot of sense now. Perfect.

Out of curiosity, have you come across this - rijndaelmanaged vs aesmanaged

I've seen a few comments around discussing both but no real conclusion. Some say to use aesmanaged over rijndaelmanaged but I cannot determine what the real difference is.

Cheers
 
Back
Top