Should I salt an AES password at each encryption?

Question

I saw a sample code where the same password is salted with a different value (using PBKDF2) for each encryption. That means that the salt must be stored for each encrypted message.

I don't understand why they do that since AES is used here in CBC mode with a random IV at each encryption, so a same plaintext will not produce the same ciphertext.

My understanding is to use a unique key for all the encryptions made with a same password. That key is produced by salting the password and I store the salt somewhere in cleartext. I though it was enough to do that because salting the password ensures the same password does not generate the same key. So the combination of the salted password and the unique IV are enough.

So my question is: is it a better behaviour to re-salt a password at each encryption?

Answer 1

I'd assume the sample (since it isn't listed) is storing a salt per encryption, because that sample assumes that only the password is variable and has no concept of users.

Using the salt per user is effective because the difficulty of using a rainbow table goes up per user (if the user table is compromised), and per your question additionally salting per message doesn't change anything in that regard because the once the password is found per user salt per one message salt and all other per user salt messages with that password are trivially compromised regardless of the per message salt.

If your application exposes ciphertexts at all, a method to increase security, would be to use an actual PRF generated key with your message and store it with the user encrypted AES-ECB by a key made with your per user salt and PBKDF2. Then the ciphertext by itself has no relation to the password at all.

Answer 2

No, it should not be necessary to derive a unique key for each message, although it certainly shouldn't do any harm, either. CBC mode is provably secure (in the IND-CPA sense, or even IND-CCA2 if combined with a MAC) even if the same key is used for multiple messages, as long as the underlying block cipher is secure (a PRP) and the IVs are distinct and unpredictable.

One potential problem with using a deliberately slow KDF like PBKDF2 to derive a new key for each message is that this needlessly consumes resources, and thus reduces the legitimate user's performance advantage over an attacker (who only needs to run PBKDF2 once to test each password). Even if one wanted to have a unique key for each message, it would be better to first derive a single intermediate key from the password with PBKDF2, and then use a faster KDF (like HKDF, or even PBKDF2 with an iteration count of 1) to derive the per-message keys from the intermediate key. Of course, this is less of a concern if messages are typically long and few rather than short and many.