Score:1

Best hash for PBKDF2?

sv flag

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?

fgrieu avatar
ng flag
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.
Swashbuckler avatar
mc flag
@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.
fgrieu avatar
ng flag
@Swashbuckler: This reinforces my feeling that the [stance of NIST on PBKDF2](https://pages.nist.gov/800-63-FAQ/#q-b17) is consistent with their former push for [Dual_EC_DRBG](https://en.wikipedia.org/wiki/Salt_(cryptography)). 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](https://crypto.stackexchange.com/a/79768/555) with French authorities once forcing me to backdoor the encryption equipment I was tasked to build.
OrangeDog avatar
dz flag
If you actually want PBKDF2 then you don't get to choose. You have to do what the spec says.
OrangeDog avatar
dz flag
"I have a my own PBKDF2 implementation" - which you will never use in any real system, right?
Heinzi avatar
de flag
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"?
Score:5
in flag

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.

Maarten Bodewes avatar
in flag
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 :)
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.