Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question
1  
Beware that the salt for PKBDF2 should remain different between users, and preferably unpredictable to an attacker in advance of obtaining the ciphertext; the first requirement is critical (else the PKBDF2-related cost of a password guess attack is inversely proportional to the number of users), the second less so (if not met, an attacker can start working before getting the ciphertext). Also, consider scrypt instead of PKBDF2. –  fgrieu Dec 31 '12 at 15:38
1  
It is not clear if you are using a per application salt or a per user salt, could you clarify? –  jbtule Dec 31 '12 at 15:39
    
I'm using a per user salt: each password has his own salt. –  Benoit Dec 31 '12 at 15:43
add comment

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
Yeah exactly. It makes sense now. Thanks. –  Benoit Dec 31 '12 at 17:58
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.