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'm new in the crypto world and I've just discovered PBKDF (I used to use typed passeword as symmetric key).

When using some crypto mode, you're required to generate an IV which must be completely random and not predictable, the best length is the length of a block size. PBKDF (and hashing functions in general) needs a salt which must also be random, I don't know the best length for a salt.

I'm thinking that an IV and a salt seems to be exactly the same but with a different name, they're random and are made to avoid getting the same output for the same input(s).

So I wonder if it would be secured to generate an IV, derive the password with this IV as salt, and use these to encrypt data?

share|improve this question
If you use a new PBKDF2 salt for each message, you don't need an IV for the actual cipher. But an IV for the cipher can't offer everything you gain from salting PBKDF2. But often it's useful to not compute PBKDF2 per message, in which case a per message IV is needed again. –  CodesInChaos Dec 15 '13 at 14:37
Even though accepted answer below being "No.", I am happy this was asked. I think while different in the bigger picture, the function of either the salt and the iv can sometimes conflate. In both cases the added randomness allows that two copies of the same original data yield different outcomes. I wished this aspect was answered a bit more. I guess the answer should be "No. not the same, but Yes similar purpose". –  humanityANDpeace Mar 18 at 8:34
It's exactly what I've concluded. In theory they're different, but I've understood that you can use an IV generator to generate a salt, for instance. –  Max13 Mar 19 at 0:50

1 Answer 1

up vote 1 down vote accepted


A salt for a PBKDF is to prevent a bruteforce search to be able to target multiple passwords at once. You generally choose one salt for a password per user, and store it. So you do not keep generating salts, only when the password is set/changed.

The role of an IV depends strongly on the mode. In some modes it is only required for semantic encryption (the same message encrypted twice is still different). For other modes such as CTR it's absolutely required for security. In general the IV should change for every message, which is the most important difference.

Note that "generate an IV which must be completely random and not predictable" is not always true. For example the IV, or nonce, for the ChaCha cipher does not need to be random nor predictable - just always different.

share|improve this answer
Hey! Thanks for the "correction". "No" means it's not secure to generate and use the same IV to derive a password and to give it to the encryption algorithm? –  Max13 Dec 15 '13 at 9:17
@Max13 I may be secure but it's almost surely wrong in the grand scheme of things. –  orlp Dec 15 '13 at 14:31
Ok, but I don't get why an IV wouldn't be random/unpredictible enough for a salt (Assuming that for a symmetric encryption, the salt have to be included in the cipher text, as is the IV, isn't it ?) –  Max13 Dec 15 '13 at 15:04
@Max13 The randomness quality is not the problem. The problem is that if you are using a PBKDF on the password with a salt you are probably not changing the salt. This means that the IV doesn't change, which is detrimental to security. See this question as well: crypto.stackexchange.com/questions/5868/… –  orlp Dec 15 '13 at 15:21
@Max13 If you're using a per-file salt I'd suggest you to feed that into PBKDF. Since then you have an unique key for each file that's only used once you don't need to have an unpredictable IV at all (which is only relevant when encrypting multiple messages). I'd suggest you to use an IV of 0 instead in that scenario. –  orlp Dec 15 '13 at 15:47

Your Answer


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.