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?


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


1 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).

  • $\begingroup$ Wow. After reading this I realize I had a whole lot more to learn! :) $\endgroup$ May 10, 2017 at 14:11
  • $\begingroup$ The alternatives to random CBC IVs given here look questionable. It's certainly possible to generate CBC IVs by encrypting a nonce, but it requires the use of an independent key for the nonce, otherwise it's trivially CPA-insecure; see, e.g., section 4 of this paper, the scheme Rogaway calls "CBC1." I haven't checked the fixed IV and prepended nonce suggestion that you describe as equivalent, but indeed its similarity to the aforementioned CBC1 scheme should give us pause. $\endgroup$ May 10, 2017 at 18:02
  • $\begingroup$ @LuisCasillas: The attack described by Rogaway seems to require that the attacker can choose the nonce, in which case using the same key is indeed insecure. I've edited my answer above (and here) to clarify that. $\endgroup$ May 10, 2017 at 19:13
  • $\begingroup$ @LuisCasillas: Ps. I went and asked a separate question about the security of the fixed-IV-and-prepended-nonce scheme. $\endgroup$ May 10, 2017 at 19:53

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.