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

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.