Question about IV/initialization vectors

Question

I found some code to get crypto-js to encrypt data in the browser, and with a pointer from someone on SO, it now decodes data as well.

My next question is about the use of an IV; is an IV like a salt where it needs to be generated from a cryptographically secure RNG, or will any data do like, a timestamp?

And from my reading, an IV does not need to be secret - if your IV is 16 bytes long, you take those 16 bytes, append the text to it that you want to encrypt, and then can publish both the IV and cipher text. Upon decrypting, you would check that the first 16 bytes of plain text match the IV, and then discard them from the resulting plain text.

Am I understanding this correctly? Will any unique data (to each cipher text) be useful for an IV, or should I be looking for a method to generate IV's (on the client side, which means it could potentially be substituted) in a secure manner?

Thanks!

PS - this is for a personal project/learning experience, not a product that's advertised as being secure :)

Answer 1

It depends on the encryption mode you're using:

• For CTR, CFB and OFB modes, the IV simply needs to be distinct for every ciphertext encrypted with the same key. (For CFB and OFB modes with less than full-block feedback, there are certain "weak IVs" that should also be avoided.)

• For CBC mode, the IV needs to be unpredictable. One way to achieve that is to generate the IVs randomly, although other methods (such as encrypting a counter with the raw AES block cipher — preferably with a separate key, if there's any chance that an attacker might be able to control the counter — and using the result as the IV) can also be used.

In any case, the IV does not need to be kept secret. If it had to be secret, it would be called a key instead.

Also note that none of the traditional encryption modes mentioned above are secure against chosen-ciphertext attacks (i.e. attacks where the attacker modifies the ciphertext, or makes up fake ciphertext out of whole cloth, and sends it to the recipient to see what happens). In particular, all of them (but especially CTR and OFB) are malleable, so that an attacker who can flip bits in the ciphertext may be able to flip corresponding bits in the plaintext. Unprotected CBC mode is also vulnerable to padding oracle attacks, unless special care is taken to prevent them (and, even then, it still remains somewhat malleable).

To protect your messages from modification and to avoid such chosen-ciphertext attacks, you'll need to either use an authenticated encryption mode, or compute a message authentication code (such as HMAC) on the ciphertext (and IV!) after encryption (and verify it before decryption).