4

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?

Max13
  • 237
  • 2
  • 9
  • 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 '14 at 08: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 '14 at 00:50

1 Answers1

1

No.

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.

orlp
  • 4,230
  • 20
  • 29
  • 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 09: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: http://crypto.stackexchange.com/questions/5868/should-i-salt-an-aes-password-at-each-encryption?rq=1 – orlp Dec 15 '13 at 15:21
  • I see, but concerning files encryption, I don't have any database or any user knowledge, using the IV (or part of it) would be like having a per-file salt. I'm only interested about the strength part, if doing so adds flaws or security breach or else ? – Max13 Dec 15 '13 at 15:39
  • 1
    @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
  • I'm indeed asking if I can feed my IV into PBKDF :) . As you suggest me to use an IV of 0 (so empty IV?) if I'm already using a salt, it's like using my IV as a salt and not using the IV to feed my symmetric encryption algorithm (i.e.: AES). Did I understand correctly? – Max13 Dec 15 '13 at 16:46
  • @Max13 There's a subtle difference. You only need an IV for encryption algorithms if you encrypt multiple messages under one key. You're not doing that so you don't need one. You're not really "feeding your salt as an IV" or "feeding your IV into PBKDF", you're just generating an unique key for each file by having an unique salt - thus you don't need an IV. Hence my suggestion of setting the IV to 0. – orlp Dec 15 '13 at 16:57
  • I understand. The thing is that I'm working on a KDE's lib, an OpenSSL wrapper for Qt. We have an InitializationVector class, I was asking if using it was an issue. The answer is "no" ;) . So, as my question IS about a security issue when using a secured/random/unpredictable IV as my PBKDF salt, if I can without issue, I think you should edit your answer. The advices still apply, thx. – Max13 Dec 15 '13 at 17:14