Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

If I'm using AES-256 CBC to encrypt, getting the 32 byte key using multiple iterations of the PBKDF2 function with a 16 byte salt, is it safe for me to let IV be equal to the salt?

(Edit: The salt is randomly generated each time. This would of course make the IV also randomly generated each time.)

How much security is lost when doing this? If I do this, the advantage is that I only will have to store the salt in the final encrypted file, not both the salt and IV (making the file 16 byte smaller!)

share|improve this question

4 Answers 4

up vote 6 down vote accepted

There is no known issue with reusing the salt used in PBKDF2 for the IV of CBC encryption, and it would be mildly surprising if it did have an impact because the salt enters as input to hash functions, and the output is used as key for the block cipher. Thus, there are "two layers" between the salt and the IV. However, surprises do happen sometimes. Reuse of any data element for two roles is, as a basic rule, potentially dangerous.

Since PBKDF2 is a Key Derivation Function which can produce an output of arbitrary length, it seems safer to simply make it generate the key and the IV. That's what is usually done in these matters.

Alternatively, if the key obtained from the password and salt will be used for only one file ever, then you could use a fixed, conventional IV (trouble with IV in CBC begins at the second usage of the key, so it tolerates an all-zero IV if and only if the key is used only once). It would still be better to replace CBC with an Authenticated Encryption mode like EAX or GCM, which has fewer constraints on IV (with EAX or GCM, it is "obvious" that a conventional IV is not a problem, as long as the key is used once) and will give you integrity on top of confidentiality.

share|improve this answer
    
As I said (and as you know) I use a random generator (that generates random raw bytes) to generate a 16 byte salt. (1) Why do people "usually" use (multiple) iterations of PBKDF2 to generate both the key and IV? Why not just ask PBKDF2 to generate a 16 byte key only, and use the random generator again to generate the other 16 bytes for the IV? Is there any security difference there? (2) In this "usual" scenario that you mention, in my case of AES256, this would mean asking PBKDF2 to generate a 32 byte output, using the first 16 bytes for the key and the other 16 bytes for the IV, correct? –  user21203 Feb 26 '13 at 11:38
2  
If you use AES-256, then you want a 256-bit key, and a 128-bit IV, hence 384 bits (48 bytes) in total. If you use 128 bits (16 bytes) for the key, then that's not AES-256 but AES-128 -- which is fine, but not the same thing. –  Thomas Pornin Feb 26 '13 at 11:42
2  
If the IV is generated randomly then it must be stored along with the encrypted data. If it is obtained from PBKDF2, then it needs not be stored, which saves an extra 16 bytes. That's not a big deal, but in some situations 16 saved bytes can be a life saver. –  Thomas Pornin Feb 26 '13 at 11:44
    
Ok, thanks. Makes sense! Final question (i hope): So you agree that a 16 byte salt is a good size for the salt, or would you recommend a larger (or smaller) salt? –  user21203 Feb 26 '13 at 11:46
2  
@user21203 16 bytes is a good salt size. Since you probably won't encrypt 2^64 messages, the chances if a salt collision are negligible. –  CodesInChaos Feb 26 '13 at 11:55

Both IV and salt are just required to be unique and random. So, as long as they hold these criteria, I've never seen (nor can think of) any reason why they can't be the same.

Reference:

share|improve this answer

I'd run PBKDF2 on the password+salt to get a master-key. Then derive a key and an IV from that masterkey. Thanks to the salt each masterkey will be used only once. That way you don't need to store the IV alongside the ciphertet.

share|improve this answer

The IV must be unique for each invocation of CBC. The salt to generate your key through PBKDF2 will be constant, otherwise you would be generating different keys.

So, no.

share|improve this answer
1  
I'd assume that a different salt is used for each encryption. –  CodesInChaos Feb 26 '13 at 7:35
    
@CodesInChaos You are indeed right. The salt is generated randomly every time. –  user21203 Feb 26 '13 at 9:24
    
So no, the salt is not consant. Why would it be? I generate different keys every time, storing the random salt in the encrypted file. –  user21203 Feb 26 '13 at 9:31
    
Alrighty, then! It sounded from the original wording of the post that you were using a static salt (for instance, to use PBKDF2 to turn a passphrase into a reusable key). –  Stephen Touset Feb 28 '13 at 6:55

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.