7
$\begingroup$

Haven't found any clear cut answer in Google so its up to you guys:

DK = PBKDF2(PRF, Password, Salt, c, dkLen)

Here, what is the upper limit of password length? I tried up to 16 characters and it works. How far can I go? I read somewhere that salt has no upper limit! Is it really true?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
7
$\begingroup$

There's no practical limit to password or salt length you can use with PBKDF2.

Theoretical limit, however, is determined by the hash function used by PBKDF2: under the hood, it uses $HMAC(Password, Salt || Counter)$, which in turn will translates to a series of hash function calls:

  • $K_0 = H(Password)$ (assuming password is longer than hash block)
  • $HMAC = H((K_0 \oplus opad) || H((K_0 \oplus ipad) || Salt))$

If we assume a very long password and/or salt, then two hash function calls can potentially "overflow": $H(Password)$ and $H((K_0 \oplus ipad) || Salt)$. To avoid such "overflow" $Password$ must be smaller than maximum input size supported by the hash function, and $Salt$ must be shorter than maximum input length minus block size of the function.

TO give some perspective and show why this doesn't really matters in real world, maximum input length for e.g. SHA-1 is $2^{64}-1$ bits or $2^{61}-1$ bytes. Block size of SHA-1 is 64 bytes, so maximum $Salt$ size will be $2^{61}-65$ bytes.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Could you clear this out "e.g. SHA-1 is 2<sup>64</sup>−1 bits <b>or</b> 2<sup>61</sup>−1 bytes" here one is in bit and another in byte! I just found a similar question like mine [here] (crypto.stackexchange.com/questions/10034/hmac-sha1-input-size). It also says that maximum input length is 2<sup>64</sup>-1 ---And I have no more confusion about it. The only thing that is still not clear to me is "2<sup>61</sup>-1 bytes". $\endgroup$
    – Giliweed
    Aug 22, 2014 at 5:51
  • $\begingroup$ Sorry for the mess. I have no idea why is my comment is like this. Its true that this is my first time to add mathematical sigh and link in a comment. $\endgroup$
    – Giliweed
    Aug 22, 2014 at 5:55
  • 1
    $\begingroup$ One byte is 8=2^3 bits. Thus, 2^64 bits is 2^(64-3)=2^61 bytes. $\endgroup$
    – Andrey
    Aug 22, 2014 at 5:57
3
$\begingroup$

Andrey's answer has the correct hash function dependent upper bounds on the lengths. However, there is also a practical length limit above which you gain no security.

For the salt, it's just "long enough not to collide", which depends on the application. For deterministic salts it's just $\log_2(n)$ bits where $n$ is the number of salts used. For random ones it's $2\log(n)$ bits. In practice, 256 bits is a good choice for a random salt.

For the password, any entropy beyond the hash size is useless. The password itself may be however long is needed, but having more than 256 bits of entropy (for SHA-256) will not make it stronger. Additionally, a password longer than the blocksize is equivalent to the password $H(p)$, which some see as a theoretical weakness.

Improve this answer
$\endgroup$
2
  • $\begingroup$ otus, I'm not clear in this -"For deterministic salts it's just $log_{2}(n)$ bits where n is the number of salts used. For random ones it's 2log(n) bits. " --- why do I need more then one salt? when do I need more then one salt? when I use only one salt the value of $log_{2}(1)$ is 0 and for a random salt the value of 2log(1) is also 0! So, can you explain a little on this? $\endgroup$
    – Giliweed
    Aug 22, 2014 at 9:44
  • 1
    $\begingroup$ @Giliweed, the purpose of the salt is to make each derived key different even if passwords match, so they have to be attacked independently. You need multiple, unique salts if you have multiple users/master passwords for which your derive keys. However, in principle an attacker could attack your password together with some completely unrelated password from some other application that happened to use the same salt, so a 256- bit random number is a safe choice. $\endgroup$
    – otus
    Aug 22, 2014 at 10:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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