Need for salt with IV

Question

I have mainly referred to this question. Definitely in case of using a salt, IV has a use of adding randomisation to each and every key. But isn't it redundant in case of using an IV to use a salt? (Like in case of referring to PBE with AES in CBC mode.)

(This is because in my understanding using the salt will make it not feasible to use rainbow tables or likes for brute force for each and every possible salt, and IV will further add randomisation to each and every message... But in case of using IV there will be randomisation in each and every message, so rainbow tables will not be feasible then also without using a salt.)

Answer 1

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to the KDF, given that you're encrypting every message with a unique IV.

In general, the answer is "possibly, but at least using both won't hurt."

An IV and a salt really have two completely different security goals. An IV is used as part of the encryption process, and its main purpose is to allow the same key to be securely used to encrypt multiple messages.* If the same key and IV are used to encrypt more than one message, inspecting the ciphertexts can leak some information about the plaintexts.

(The exact information leaked depends on the cipher mode: for CBC and CFB modes, it includes the length of any common prefix shared by the messages, and possibly some information about the first cipher block that differs; for CTR and OFB modes, reusing the IV leaks the bitwise XOR of the full messages!)

A salt, on the other hand, is used in the key derivation process,** and its main purpose is to slow down certain kinds of brute-force password cracking attacks by, on one hand, ensuring that two users with the same passphrase won't end up with identical keys, and on the other hand, preventing attackers from precomputing passphrase/key combinations in advance.

(Some KDFs may also use the salt to allow multiple quasi-independent keys to be derived from the same passphrase, while other KDFs have a separate parameter for that. Similarly, some cipher modes may also have additional requirements on the IV; for example, CBC mode needs an IV that is not only unique but also unpredictable to resist certain chosen-plaintext attacks.)

In particular, a password-based key derivation function should implement key stretching, i.e. it should be deliberately resource-intensive to compute in order to slow down brute force attacks. Including a unique salt in this process is important, because it prevents an attacker from gaining a significant advantage by targeting multiple users in parallel.

Without a salt, an attacker could just run the slow key-derivation process once for each password, and then quickly test the resulting key against every captured message. Salting the KDF forces the attacker to instead repeat the slow key derivation process for each user / message separately. An IV will not help here, since it's applied only during the encryption step, after the slow key derivation process is over.

IVs don't really have any effect on brute-force password guessing attacks like this; the kind of attacks prevented by proper IV usage are plaintext-recovery (not key-recovery) attacks based on reusing the same key and IV to encrypt multiple message, which can leak information about the plaintexts for those messages.

Note that, if you're only encrypting a single message with each key produced by your KDF, then you may be able to safely use a fixed IV. But in that case, you definitely need to use a per-message salt in your KDF, to guarantee that the keys will really be unique. In any case, even if not strictly necessary in this case, using a random unique IV is still the safe default choice.

Ps. In any case, you really should be using an authenticated encryption mode instead of plain CBC to protect against active tampering attacks. Among such modes, I'd like to particularly mention SIV mode (RFC 5297), which is designed to offer extra resistance against accidental IV reuse.

---

^{*) At least, that's true of the kind of IVs we're talking about here. More generally, the term "IV" really just means "initialization vector", and is used for all sorts of algorithms, like hash functions, that involve iteratively processing blocks or "vectors" of data. Alas, the terminology is probably too entrenched to change at this point.}

^{**) Salts are also used for password hashing in password-based authentication schemes. Actually, password hashing and key derivation are very similar tasks, and so the algorithms and terminology are mostly the same.}

---

Related links:

• What is the main difference between a key, an IV and a nonce?
• What is a cryptographic "salt"?
• Why should I use an Initialization Vector (IV) when I have unique keys?

Answer 2

In Password-Based Encryption (PBE) we use a randomly generated (and hopefully unique) salt to prevent dictionary attacks on the key generated from a password. Every "user" in a system should at least have a different salt.

Since key derivations can be made arbitrarily hard just by increasing the iteration count, we can have, let's say, a key derivation that lasts 5 seconds on the sender machine. If you would always generate a fresh salt and derive the encryption key for every message of your hypothetical chat protocol, then this would be very frustrating for your users, because a 10 second delay for every message (PBKDF at sender and receiver side) is not that great.

You still need to randomize every single message, so you can claim CPA-security. You can do that by using a "long-term" random salt and a fresh IV for each new message. This will incur only the previously mentioned delay for the first message and be otherwise very fast for the rest of the communication.

Of course, if you don't need low latency messages, then you can simply set the IV to some fixed value for each message and derive the encryption key with a fresh new salt each time. Then you don't need to sent the fixed IV value along with the ciphertext anymore. This is at least CPA-secure as long as the block cipher is good.

Using a random IV in addition to a random salt for each message is a little bit wasteful, but not necessarily bad.