3

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!)

Improve this question

4 Answers 4

Reset to default
7

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.

Improve this answer
5
  • 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, 2013 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, 2013 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, 2013 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, 2013 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, 2013 at 11:55
4

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.

Improve this answer
4
  • 1
    I'd assume that a different salt is used for each encryption.
    – CodesInChaos
    Feb 26, 2013 at 7:35
  • @CodesInChaos You are indeed right. The salt is generated randomly every time.
    – user21203
    Feb 26, 2013 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, 2013 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, 2013 at 6:55
1

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.

Improve this answer
1

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:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .