# Is AES in CBC mode secure if a known and/or fixed IV is used?

I have a need to encrypt credentials for a third-party app used by a secured internal app. Over on ITSec.SE, I was helpfully shown a scheme to encrypt the third-party credentials based on a hash of the credentials for the internal app.

I picked AES as the encryption algorithm, but the problem is that the password-based scheme doesn't produce a "secret" IV. So, the IV must at least be known to an attacker (stored alongside the encrypted data). A hash value used for password verification could work, or I could just generate a pseudorandom byte array and drop it in the DB as a new column. I was further considering, for simplicity, to use a constant IV.

What adverse effect will either of these choices have on the security of the encryption? Does AES depend, as many block ciphers do, on an unpredictable IV? Does it matter if the IV is stored as unencrypted plaintext?

Do not use a fixed IV. It can have seriously negative consequences. This is especially true for CBC mode.

That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.

• If you do, keep in mind that CBC mode has extra-strict requirements for the IV. Generating it with a cryptographically secure pseudorandom number generator is best practice. – Stephen Touset Oct 18 '12 at 17:04
• Keith, I would recommend you use System.Security.Cryptography.SymmetricAlgorithm.GenerateIV() instead of trying to generate your own array of bytes and loading them into the IV yourself. First, Microsoft's implementation is available and pre-tested, so you should have little business reason to reinvent that wheel. The other is that if someone discovers a weakness involving IVs next month, Microsoft would distribute a patch, and you wouldn't have to deal with the maintenance consequences yourself. – John Deters Oct 18 '12 at 21:55
• ... Except that in my case I'm using a PBKDF, and SymmetricAlgorithm.CreateEncryptor() doesn't have an overload accepting only a key. – KeithS Dec 13 '12 at 15:59
• @KeithS I know this comment comes years later, but to anyone else reading, CreateEncryptor without any parameters uses the Key and IV that are properties of the owning SymmetricAlgorithm. – Luke Park Jan 7 '16 at 2:07
• @mikeazo, "especially true for CBC mode"? What does "especially" mean here and for which mode is it untrue then? – Pacerier Dec 26 '16 at 3:15

An initialization vector never needs to be secret. If it needed to be secret then it would be called a "key" instead of a "vector".

Generally, the initialization vector requirements are only dependent on the mode of operation, not the choice of the block cipher. The parameters of the mode of operation, such as the IV size, may however depend on the block size of the used block cipher. For CBC mode the IV is always the same size as the block size, which is 16 bytes for AES.

For CBC mode, you can use a fixed initialization vector when the same key is only ever used for one message. Note that this also means that you should not reuse the IV for multiple versions of the same message. If your key is calculated deterministically from the login credentials of the user using a hash, this will not work. You may however use a changing salt and a password hash such as PBKDF2 or Argon2. The unique salt and therefore unique key then take the security role of the initialization vector.

A changing but predictable initialization vector is bad when the attacker can choose a message to be encrypted and then observe the ciphertext. It would be possible to observe if a IV / plaintext combination would result in identical input to the block cipher, resulting in identical ciphertext. So using a predictable IV could leak information about previous plaintext having a specific value. An attacker-chosen initialization vector is equally bad, of course, even if she can't choose the message.

A cryptographically secure (pseudo-) random initialization vector - stored next to the ciphertext - is generally safe for all modes of operations.

Please note that you'll often also want to calculate a MAC over the data, to make sure it cannot changed without detection. If you don't do this then an attacker can modify the ciphertext and observe the reaction when you try to decrypt. This may allow an attacker to perform padding or other plaintext oracle attacks and retrieve the plaintext. If you stored the IV next to the ciphertext then you should also include the IV in the calculation of the MAC.

• So does the IV and the salt actually serve similar purpose? Meaning they can be interchangeable and would never both be required at the same time? – Didier A. Mar 10 '14 at 14:28
• They both fulfill the same purpose, but are usually used in different contexts. An IV is used for an encryption algorithm (like a mode of operation of a block cipher), while a salt is used in key derivation or password hashing and similar. But the word usage varies a bit, and the border is not well-defined. – Paŭlo Ebermann Mar 10 '14 at 22:03
• @PaŭloEbermann this is a great answer. I know its sometime since this post, but do you have any reference link you could provide with additional details? Would be very useful – Allyl Isocyanate Feb 2 '16 at 20:20
• @juwiley I would suggest wikipedia's Mode of Operation article as a first start, it has many more links. – Paŭlo Ebermann Feb 2 '16 at 20:27
• Hi Paulo. How are you? I've substantially rewritten your text. I hope you like it, otherwise roll back to the org. version! – Maarten Bodewes Nov 16 '18 at 13:41

If you use a fixed IV, then effectively the first block of every message you send is in ECB mode. Since it is not uncommon for the plaintext of many messages to start the same way, for example:

From: Hiram K. Sluggenheimer

then this can be a weakness if more then one message uses the same key.

In short, avoid a fixed IV, instead use a cryptographically random IV prepended to the cyphertext.