chaining multiple key derivation functions together

[Maricel Gregoraschko]

I was looking at PBKDF2, bcrypt and scrypt as options for key derivation; and would like to try using them all together in order to get the cryptographic strength of the strongest one (which seems to be scrypt so far unless something novel is discovered, but the assumption is that it is not known which one is the strongest).

 My first thought was to apply the first kdf to the password, then apply the second kdf to the obtained key (using it as the second password), and then the third. Is there something inherently wrong with this?

I saw a different approach posted by user perseids here:

http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html

I quote: "Derive p_1 = HMAC(Salt1+"PBKDF2") with key sha256(p), p_2 = HMAC(Salt2+"bcrypt") with key sha1(p) and p_3 = HMAC(Salt3+ "scrypt") with key sha1(p). Derive key k1, k2 and k3 by using the key derivation function PBKDF2, bcrypt and scrypt respectively, each of them using 1/30 seconds CPU time with input p_1, p_2 and p_3 respectively. Compute the key (or database reference entry) as sha256(k1+k2+k3). Here "+" designates the concatenation of byte arrays. "

So basically the 3 kdfs are applied in parallel, and the resulting keys are concatenated and then hashed together. What do you guys think about this one? Is this obviously superior to just applying the multiple kdf "in series"?

Also, what are considered the most reliable and well scrutinized C or C++ implementations of bcrypt and scrypt (I found pbkdf2 in crypto++ and botan). I guess if they produce the right results, then they are reliable, so one point would be that they are well tested, but also what would be important is that they are implemented reasonably efficiently, so they don't give you a false sense of security (e.g. taking long time to compute, when in fact an attacker could take much less time to compute the same with a better algorithm, even without specialized hardware).

Thank you!

[Mouse]

I think you're overcomplicating it unnecessarily.

--
--
You received this message because you are subscribed to the "Crypto++ Users" Google Group.
To unsubscribe, send an email to cryptopp-user...@googlegroups.com.
More information about Crypto++ and this group is available at http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups "Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cryptopp-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,
Mouse

[Jeffrey Walton]

> My first thought was to apply the first kdf to the password,

> then apply the second kdf to the obtained key (using it as

> the second password), and then the third. Is there something

> inherently wrong with this?

I seem to recall a similar discussion on the Crypto mailing list recenty. See "Mixing multiple password hashing: Crypto Blasphemy or Useful approach?", http://lists.randombit.net/pipermail/cryptography/2015-March/007130.html.

> What do you guys think about this one? Is this obviously superior

> to just applying the multiple kdf "in series"?

For password storage, it seems to me you want something that is *not* parallelizable. Otherwise, it makes the attacker's job easier. (Or maybe the attacker's job is not as hard as it could be).

> Also, what are considered the most reliable and well scrutinized C

> or C++ implementations of bcrypt and scrypt (I found pbkdf2 in

> crypto++ and botan).

I don't think Crypto++ has either bcrypt or scrypt.

Jeff

[Jean-Pierre Münch]

Am Montag, 23. März 2015 20:07:26 UTC+1 schrieb Jeffrey Walton:

> My first thought was to apply the first kdf to the password,

> then apply the second kdf to the obtained key (using it as

> the second password), and then the third. Is there something

> inherently wrong with this?

I seem to recall a similar discussion on the Crypto mailing list recenty. See "Mixing multiple password hashing: Crypto Blasphemy or Useful approach?", http://lists.randombit.net/pipermail/cryptography/2015-March/007130.html.

> What do you guys think about this one? Is this obviously superior

> to just applying the multiple kdf "in series"?

For password storage, it seems to me you want something that is *not* parallelizable. Otherwise, it makes the attacker's job easier. (Or maybe the attacker's job is not as hard as it could be).

> Also, what are considered the most reliable and well scrutinized C

> or C++ implementations of bcrypt and scrypt (I found pbkdf2 in

> crypto++ and botan).

I don't think Crypto++ has either bcrypt or scrypt.

Crypto++ neither has scrypt nor bcrypt.
However, if you don't need fast scrypt, CryptoJPM, does have scrypt. (SSE code seems to be broken, but I don't know the reason....)

The only reason I could imagine to use multiple PBKDF schemes is to protect until several classes of enemies until PHC is finished.
f.ex. One could argue that bcrypt is highly GPU resistant, whereas scrypt is anti-ASIC and anti-FPGA and maybe PBKDF2 as additional line of defense and you'd know why to use multiple PBKDFs.

 BR

JPM

[Jeffrey Walton]

On Tuesday, March 24, 2015 at 10:23:08 AM UTC-4, Jean-Pierre Münch wrote:

The only reason I could imagine to use multiple PBKDF schemes is to protect until several classes of enemies until PHC is finished.

You also have compliance. For example, you might make the thrust of the hardening bcrypt or scrypt for their memory hard-ness, while chaining to SHA to satisfy FIPS 140 requirements.

Jeff

[Christopher Head]

Seems to me there’s a possible problem with the series chain option: if
any one of the PBKDFs is flawed in that it fails to incorporate all the
entropy in the original password, then the other PBKDFs can’t rescue
it—the entropy is gone forever when the password or intermediate key
passes through that PBKDF. As an extreme example, consider a PBKDF
which outputs zero for all possible inputs—any series chain containing
it is utterly useless, no matter how good the PBKDFs before and after
it are!
--
Christopher Head