[cryptography] any reason PBKDF2 shouldn't be used for storing hashed passwords?

Patrick Mylund Nielsen cryptography at patrickmylund.com
Wed Aug 15 22:33:53 EDT 2012


>  On current GPUs, that's "a lot", not "slightly".  GPUs currently deliver CPU-like
speeds for bcrypt, but a lot higher speeds for PBKDF2-HMAC-SHA*

Yeah, I realized that was a bit unfair. I guess I was thinking mostly in
relation to scrypt -- bcrypt is certainly not inexpensive.

> The limit is actually at 72 chars.  55 was an error in the paper.

Oh, interesting. Then it seems like less of an issue.

Thanks for the clarification!

On Thu, Aug 16, 2012 at 4:27 AM, Solar Designer <solar at openwall.com> wrote:

> On Thu, Aug 16, 2012 at 02:25:34AM +0200, Patrick Mylund Nielsen wrote:
> > PBKDF2 is certainly decent, and often the easiest choice if you intend to
> > comply with e.g. FIPS 140-2/ISO 27001, but the biggest argument against
> it
> > is that it _isn't_ difficult to parallelize, since it is just e.g.
> > HMAC-SHA256. Each guess might require sequential iteration, but you can
> > still compute many guesses simultaneously.
>
> Exactly.
>
> > bcrypt is slightly more computationally expensive
>
> On current GPUs, that's "a lot", not "slightly".  GPUs currently deliver
> CPU-like speeds for bcrypt, but a lot higher speeds for PBKDF2-HMAC-SHA*.
>
> (I expect that we'll get faster attacks on bcrypt using general-purpose
> hardware with AVX2 and Intel MIC, though.)
>
> > (although its 55-byte input limit is often ignored,)
>
> The limit is actually at 72 chars.  55 was an error in the paper.
>
> > > PBKDF2-HMAC-SHA1 significantly weaker than PBKDF2-HMAC-SHA512?
> >
> > SHA-1 is still safe in an HMAC construction, however there's no
> convincing
> > reason not to use at least PBKDF2-HMAC-SHA256 that I can think of. You
> > don't need it to be fast. Going beyond that won't really give you much
> > security compared to using a memory-hard function.
>
> There's a lot of difference between SHA-1 and SHA-512 in terms of
> friendliness to current GPUs.  SHA-512 is a lot less GPU-friendly.
>
> SHA-256 is inbetween.  This is related to SHA-512 making more complete
> use of 64-bit CPUs.  If you use more of the available resources and do
> so wisely, then the attacker will similarly have to use more resources.
> This alone accounts for a 2x difference between SHA-256 and SHA-512 when
> we consider attackers' GPU implementations.  Further difference comes
> from SHA-512's increased register pressure (on GPU's 32-bit registers).
>
> Overall, SHA-256 is 2-3 times slower than SHA-1, and SHA-512 is a
> further 4-14 times slower than SHA-256 on current GPUs with currently
> available implementations.  SHA-512 is 10 to 30 times slower than SHA-1
> on current GPUs with currently available implementations.
>
> Still PBKDF2-HMAC-SHA-512 is a lot more susceptible to attacks with
> current GPUs than bcrypt, let alone scrypt.
>
> Alexander
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20120816/08c45ff4/attachment.html>


More information about the cryptography mailing list