1
$\begingroup$

I have a my own PBKDF2 automated implementation that automatically salts the hash. The output looks like this:

xxxxxxxxxxxxxxxxxxxxxxxx.xxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
\-- 24 byte salt ------/ \data/ \-- 48 byte output hash --------------/
  • Salt is a random byte array
  • Interations are stored in data
  • Output hash is a derived key
  • Everything is encoded using Base64Url, not including dots

I'm a newbie in cryptography, so I'm not sure, what to choose (SHA-256 or SHA-384). SHA-384 is resistant to length-extension attacks, while SHA-256 is not. I'm not sure, which one to use.

Also, I'm not sure about a derived key and salt lengths.

My question is: What hash to use (SHA-256 or SHA-384), when using PBKDF2? Also, what derived key size is the best?

Improve this question
$\endgroup$
6
  • 5
    $\begingroup$ Two things. 1) PBKDF2 does not use a hash, but a keyed PRF, the most common of which is HMAC with a hash. 2) PBKDF2 is at best obsolete for key stretching; use Argon2 instead. $\endgroup$
    – fgrieu ♦
    Commented Oct 24, 2022 at 20:50
  • 4
    $\begingroup$ @fgrieu Argon2 is not usable if one requires FIPS 140 compliance, in that case PBKDF2 is the only approved function to derive a key from a string. $\endgroup$
    – Swashbuckler
    Commented Oct 24, 2022 at 21:28
  • 1
    $\begingroup$ @Swashbuckler: This reinforces my feeling that the stance of NIST on PBKDF2 is consistent with their former push for Dual_EC_DRBG. More bluntly said: some of FIPS 140(-2) (e.g. prescriptions on RNGs and key generation) looks to me as a way to sneak a backdoor for those with the right knowledge or hardware. Call me traumatized by that very experience with French authorities once forcing me to backdoor the encryption equipment I was tasked to build. $\endgroup$
    – fgrieu ♦
    Commented Oct 25, 2022 at 6:41
  • 3
    $\begingroup$ "I have a my own PBKDF2 implementation" - which you will never use in any real system, right? $\endgroup$
    – OrangeDog
    Commented Oct 25, 2022 at 7:31
  • 1
    $\begingroup$ The sentences "I have a my own PBKDF2 implementation" and "I'm a newbie in cryptography" don't really match. Is it possible that you meant to write "I have my own password hashing method which uses a standard library PBKDF2 implementation"? $\endgroup$
    – Heinzi
    Commented Oct 25, 2022 at 13:24

1 Answer 1

Reset to default
5
$\begingroup$

I'am a newbie in cryptography, so I'm not sure, what to choose (sha256 or sha384). Sha384 is resistant to length-extension attacks, while sha256 is not. I'm not sure, which one to use.

With length extension you can create another valid value for a keyed hash, even though you don't know the key. PBKDF2 actually uses HMAC though, and that is not vulnerable to length extension attacks. The reason why you only see the hash is that HMAC has just one configuration parameter: the hash function used. PBKDF2 is not unique in this by the way, TLS also shows a hash at the end of the cipher suite name while it is actually used for a PRF.

In short, what hash to use (sha256 or sha384), when using Pbkdf2? Also, what derived key size is the best?

In principle SHA-256 can already provide 256 bit security within PBKDF2 as collision resistance is not required. However, PBKDF2 has the nasty habit of requiring the user to perform all the iterations once again for each block of 256 bit output. So if more than 256 bits are required then it makes sense to use SHA-512.

In my opinion SHA-384 doesn't make any sense for these kind of functions. Basically it is the same algorithm as SHA-512, while you then toss away bits that could provide meaningful security, or at least enables a larger output size. As already indicated, the protection against length extension is not really a problem here.

To be honest though, the whole discussion is moot. The hash function used is a configuration parameter. It is up to the implementer of the protocol to choose which hash function and iteration count to use. As provider of a PBKDF2 implementation you should enable all possible hashes - or at least SHA-1 and the SHA-2 family of hashes. If you are the sole user of your own implementation then I would suggest that the output size requirement is known, and you can select your hash based on that.

Generally you don't transmit password hashes within URL's, so I'm not sure why you are trying to use base64url. I would suggest you use an already existing scheme such as PHC, defined here for PBKDF2.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I don't think that length extension attacks are particularly useful against password hashes, but as HMAC is not vulnerable anyway I though I might as well take a shortcut :) $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 24, 2022 at 23:27

Your Answer

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

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