5
$\begingroup$

In order to complicate rainbow table attacks, salt must be provided as input to PBKDF2 when a key is derived from a low-entropy password.

I have decided on my algorithms and key lengths to achieve certain bit strength. How long salt should I use for PBKDF2?

Improve this question
$\endgroup$
4
$\begingroup$

PBKDF2 defines, that the salt is concatenated with the numbers of iterations (in 32 bit big endian) as 2nd input to the PRF. If you use HMAC as PRF (as suggested in the wiki article), the 2nd argument can be of arbitrary length.

On other SE sites, you can find these questions and answers to cryptographic salts in general:

The main aspect of salts is that they are unique. So it comes down to how many different keys you want to derive with your KDF. As a rule of thumb, 32 or 64 random bits should be enough and you will most likely never exhaust those numbers. If you just want to derive a couple of keys from the master secret, you can get away with an even shorter salt, e.g. 2 byte. Even if you set the salt length "too short" and want to derive more keys later, you can always use the same salt and a different number of iterations. That will also result in different derived keys, because the number of iterations is embedded in the input of the first iteration of the PRF already.

Improve this answer
$\endgroup$
4
  • 2
    $\begingroup$ I'd consider 64-bit random salts the bare minimum and would go with 128-bit salts as long as there is no strong pressure to minimize its size. 32-bit salts start colliding once you get around 65k hashes. $\endgroup$ – CodesInChaos Sep 27 '16 at 10:13
  • $\begingroup$ Thank you for relevant links! But I emphasized in the question that I'm concerned about precomputation attacks. So, for me it is not enough that the salts are unique - I need them also to be of high enough entropy. $\endgroup$ – Konstantin Shemyak Sep 27 '16 at 10:35
  • $\begingroup$ Sorry, removed that sentence. You can of course build a rainbow table when the salt is non-random - you'd need to include a statically selected random value or unique magic value in front of a "unique" number to make sure you can thwart them. In the end each password should be generated with a unique salt, but for that the salt itself should be unique over all possible domains. So starting to count at 1 is not a good idea. $\endgroup$ – Maarten Bodewes♦ Sep 27 '16 at 11:29
  • $\begingroup$ A salt has a similar task like the IV in modes of operation or a nonce in a protocol: The value is not considered secret and security should not depend on it. The only requirement is that it is not re-used. Considering the length: The birthday problem can be disregarded, if you can look up which salts have been used already. Since salts are public knowledge, this might be possible - depending on the exact setup. In that case 32 bits might be enough - again depending on how many different salts are actually required. On the other hand: Longer salts don't really hurt performance. $\endgroup$ – tylo Sep 27 '16 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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