Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blake3 is 10 times faster than SHA-2

nextjournal.com

Post reply on HN
Print view View original

131–140 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#131

Post by throwaway838475 »

kragen wrote: post #114
jaytaylor wrote: post #109

Earlier quoted context omitted.

I didn't think hashing the hash would be helpful here, and couldn't think of a way to mitigate against this attack. After reading more it seems the only mitigation is Layers of Security. https://en.m.wikipedia.org/wiki/Pass_the_hash#Mitigations

No, hashing the hash solves the problem.

Almost. That construction is still vulnerable to chosen input attacks without inner and outer padding, which is basically rediscovering HMAC, which also isn’t suitable for storing passwords. Don’t roll your own crypto if you don’t know what you’re doing. Use a PBKDF like argon2, scrypt, bcrypt or PBKDF2 as they are intended because they are far, far stronger than hashing a couple of times.

Re: Blake3 is 10 times faster than SHA-2

#132

Post by [deleted] »

espadrine wrote: post #62
lucb1e wrote: post #49

Earlier quoted context omitted.

Compared to? MD2, MD4, MD5, SHA-1, etc.: There are collisions known, so yes. SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that.

> SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that. There are important differences; some of those primitives are definitely more trustworthy than others. SHA-2 and Whirlpool use the old Merkle–Damgård construction, which has fallen out of favor because of unfortunate properties. They are vulnerable to length extension attacks, such that it…

[deleted]

Re: Blake3 is 10 times faster than SHA-2

#133

Post by pnako »

nneonneo wrote: post #128
jaytaylor wrote: post #119

Earlier quoted context omitted.

My take away was that the server relief comes from reducing the ability of clients to trigger disproportionate amounts of server resource consumption.

I don’t see how that follows. If HSrv is expensive or slow, a malicious client could just submit nonsense hashes that only look like they might have come from HCli - the server shouldn’t be able to tell the difference. Requiring client-side JavaScript for your login system seems fraught. I would much rather have an approach that does server side hashing exclusively, but gates it behind some kind of DDoS protection or…

You do the slow (bcrypt, argon2 or whatever) hash in the browser, and then the server can do the hyper-fast hash (SHA256).

You can still flood the server, but you're flooding it with things that take microseconds to compute, instead of 50ms.

Re: Blake3 is 10 times faster than SHA-2

#134

Post by nayuki »

lucb1e wrote: post #85
espadrine wrote: post #62

Earlier quoted context omitted.

> SHA-2, SHA-3, BLAKE2b, Skein, Whirlpool, etc.: We don't have any collisions for these, so it doesn't get any better than that. There are important differences; some of those primitives are definitely more trustworthy than others. SHA-2 and Whirlpool use the old Merkle–Damgård construction, which has fallen out of favor because of unfortunate properties. They are vulnerable to length extension attacks, such that it…

That was informative, thanks! It matched my gut feeling about the algorithms and I knew some of these things, but not everything :) > a safe bet is still SHA-512/256, which is safe against length extension attacks. I would like to add here that this does not mean "SHA-512 or SHA-256" (I remembered that SHA-256 was not length-extension resistant and looked up the details). Instead, it means the version of SHA-512 that…

The hash function "SHA-512/256" has different initial constants than "SHA-512", so it is not equivalent to truncating a "SHA-512" hash value.

SHA-224 and SHA-384 are somewhat resistant to length-extension attacks because they output a truncated state.

Yeah, the slash in the names are an unfortunate choice that hurts clarity.

Re: Blake3 is 10 times faster than SHA-2

#135

Post by SkyMarshal »

nneonneo wrote: post #71

A lot of people in the comments are wondering about using SHA-2 vs Blake3 for password hashing. The answer is, neither of these is suitable by itself for password hashing. Sadly there’s still a lot of advice on the internet (and, sadly, real systems) which do things like store md5(password) in a database and call it a day. Blake2/3, SHA-2/3, and other cryptographic hash functions are meant to be fast , while also eff…

>For low-entropy data, you want a hash function that is slow and hard to parallelize. Use a specialized password hashing algorithm like bcrypt, scrypt or Argon2, and tune it so it’s slow enough without impacting overall usability (e.g. takes 50ms on your server).

For most of the 2010s I've been under the impression that password hashing was a solved problem and that this is the solution.

And yet I still see comments online saying to hash passwords with a salt + 10,000 rounds of PBKDF2. Why bother when you can just b/scrypt it? Is there still some benefit of the former over the latter?

Re: Blake3 is 10 times faster than SHA-2

#136

Post by aaronmdjones »

SkyMarshal wrote: post #135
nneonneo wrote: post #71

A lot of people in the comments are wondering about using SHA-2 vs Blake3 for password hashing. The answer is, neither of these is suitable by itself for password hashing. Sadly there’s still a lot of advice on the internet (and, sadly, real systems) which do things like store md5(password) in a database and call it a day. Blake2/3, SHA-2/3, and other cryptographic hash functions are meant to be fast , while also eff…

>For low-entropy data, you want a hash function that is slow and hard to parallelize. Use a specialized password hashing algorithm like bcrypt, scrypt or Argon2, and tune it so it’s slow enough without impacting overall usability (e.g. takes 50ms on your server). For most of the 2010s I've been under the impression that password hashing was a solved problem and that this is the solution. And yet I still see comments…

There are two principal benefits of sticking with PBKDF2:

1) It's a NIST standard. This may be necessary in some environments, typically just to check a box. (Yeah, I know...)

2) It's necessary for SCRAM (RFCs 5802, 7677), which is a much better login method based on passwords. This is applicable if your system uses GSS-API or SASL (e.g. dovecot IMAP logins).

If neither applies, my advice is to migrate to Argon2.

Re: Blake3 is 10 times faster than SHA-2

#137

Post by nneonneo »

throwaway838475 wrote: post #131
kragen wrote: post #114

Earlier quoted context omitted.

No, hashing the hash solves the problem.

Almost. That construction is still vulnerable to chosen input attacks without inner and outer padding, which is basically rediscovering HMAC, which also isn’t suitable for storing passwords. Don’t roll your own crypto if you don’t know what you’re doing. Use a PBKDF like argon2, scrypt, bcrypt or PBKDF2 as they are intended because they are far, far stronger than hashing a couple of times.

I believe what we’re discussing is having a client compute a PBKDF of the password, and then having the server hash the PBKDF output one more time to obtain the thing that’s actually inserted into the database. The idea is that if the database leaks, the attacker gets H(PBKDF(password)) which is hard to bruteforce due to the PBKDF, and can’t be used directly as a login token because of the extra H(). I don’t see where this would be subject to a chosen input attack.

Re: Blake3 is 10 times faster than SHA-2

#139

Post by CalmStorm »

nolok wrote: post #74
nneonneo wrote: post #71

A lot of people in the comments are wondering about using SHA-2 vs Blake3 for password hashing. The answer is, neither of these is suitable by itself for password hashing. Sadly there’s still a lot of advice on the internet (and, sadly, real systems) which do things like store md5(password) in a database and call it a day. Blake2/3, SHA-2/3, and other cryptographic hash functions are meant to be fast , while also eff…

> tune it so it’s slow enough without impacting overall usability (e.g. takes 50ms on your server) I want to insist that this is a very important part. If you are 99.9% of applications or websites out there, the only time you need to run that hash is at registration, login and password change. All of these case will be fine if it's a bit slow. Don't lowball it. Also informationally I would like to add that as part of…

But you also need to be careful. The slow password hashing can be exploited for Denial of Service attack. You may want to rate-limit the APIs that use the hash algorithm.

Re: Blake3 is 10 times faster than SHA-2

#140

Post by zokier »

rurban wrote: post #7

Not really. It's even 2x slower than SHA256-NI, the builtin. b3sum is much faster than sha256sum, and blake3 is about 2x faster than blake2. http://rurban.github.io/smhasher/doc/table.html

Why doesn't sha256sum use sha-ni?

On the other hand, seems like sha-ni became widely available only with cannon lake and zen, while blake3 should be fast on any hw even if it benefits from avx512

Post reply on HN