Blake3 is 10 times faster than SHA-2 • Hacker News Board

Re: Blake3 is 10 times faster than SHA-2

#121

Post by stevefan1999 » Sun, Jan 12, 2020, 2:10 AM UTC

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…

And we should all use bcrpyt to hash password. We all should have had it long long time ago, and people are still rolling out their own password hashing with salting mechanism. Biggest facepalm in the industry in my eyes.

Re: Blake3 is 10 times faster than SHA-2

#122

Post by blattimwind » Sun, Jan 12, 2020, 2:12 AM UTC

stevefan1999 wrote: post #121

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…

And we should all use bcrpyt to hash password. We all should have had it long long time ago, and people are still rolling out their own password hashing with salting mechanism. Biggest facepalm in the industry in my eyes.

not processing plaintext passwords on your server >> argon > scrypt > bcrypt > pbkdf2 >>> any hash

Re: Blake3 is 10 times faster than SHA-2

#123

Post by loeg » Sun, Jan 12, 2020, 2:17 AM UTC

zimmerfrei wrote: post #19

This is a bit pointless, since it does not say on which platform the comparison is made. In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256. KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with. However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received…

BLAKE was a SHA-3 finalist and received similar scrutiny to Keccak. Blake2 is, AFAIK, more widely adopted in software than SHA-3 and KangarooTwelve combined. Part of this is that Keccak, as specified in SHA-3, is incredibly slow in software -- NIST not only encouraged a ridiculous number of rounds, but also biased their decision-making in favor of hardware implementations.

I'm not sure to what extent we'll see significant SHA-3 adoption outside of any future FIPS software requirements. You are probably correct about the additional scrutiny SHA-3 will receive, just as a side effect of its use in future FIPS-compliant software.

Re: Blake3 is 10 times faster than SHA-2

#124

Post by loeg » Sun, Jan 12, 2020, 2:20 AM UTC

lucb1e wrote: post #51

doomrobo wrote: post #45

Earlier quoted context omitted.

It was announced in a lightning talk following that session

That doesn't sound very official. Most text in the paper seems to date from August, so it looks like this has been out for a while and was not only just announced, even if it was mentioned or officially "announced" (while being already released) in a surprise talk at that conference.

You would be mistaken.

Re: Blake3 is 10 times faster than SHA-2

#125

Post by lisper » Sun, Jan 12, 2020, 2:50 AM UTC

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.

It's important to understand why this is so: it's because the hash is big, so while it might be possible to mount a brute force preimage attack against a password, it is not practical to do so against a hash. So hashing a hash (once) is secure even though hashing a password (once) isn't.

Re: Blake3 is 10 times faster than SHA-2

#126

Post by bscphil » Sun, Jan 12, 2020, 3:09 AM UTC

garmaine wrote: post #113

SlowRobotAhead wrote: post #75

I have a project I couldn’t use SHA-2 on because of speed and because it was a 224bit or 256bit result. Is there a way to use Blake3 in a reduced hash result way? Like 12-16 byte results. (IIRC, you can not truncate hashes for smaller results)

SHA-224 is literally truncated SHA-256. There's no security proof this is safe, but only in the sense there is no proof SHA does what it claims to do at all. Hash truncation is in the design of SHA-2. There's even an appendix of one of the FIPS documents explaining how to do the truncation for arbitrary sizes. But be very careful to make sure that you only need preimage resistance...

A 224 bit output is going to be collision resistant too, though, for the foreseeable future. And when it comes to preimage resistance, even md5 is safe for the time being. (With the usual qualifier that there's absolutely no justification for using it with better hashes available.)

Re: Blake3 is 10 times faster than SHA-2

#127

Post by oconnor663 » Sun, Jan 12, 2020, 3:33 AM UTC

JdeBP wrote: post #115

oconnor663 wrote: post #106

Earlier quoted context omitted.

https://twitter.com/dchest/status/1215751501567709185

1978 isn't on the graph. (-: Hint: andybak was making a joke.

Straight talk, should I watch this show? :)

Re: Blake3 is 10 times faster than SHA-2

#128

Post by nneonneo » Sun, Jan 12, 2020, 3:59 AM UTC

jaytaylor wrote: post #119

pitaj wrote: post #117

Earlier quoted context omitted.

That is pretty interesting, but doesn't actually offer up a solution that provides server relief, unless I missed something. In every case they still require that HSrv be a slow hash function.

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 rate-limiting.

Re: Blake3 is 10 times faster than SHA-2

#129

Post by throwaway838475 » Sun, Jan 12, 2020, 4:25 AM UTC

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…

The correct term is PBKDF.

And more succinctly:

crypto hash fn != authenticated hash fn (like HMAC constructions) != PBKDF

Re: Blake3 is 10 times faster than SHA-2

#130

Post by throwaway838475 » Sun, Jan 12, 2020, 4:32 AM UTC

I always shake my head when performance is touted for new functions/constructions. It’s more important to minimize the costs of legitimate use while maximizing the costs of software and hardware attacks. Minimizing the former inevitably leads to minimization of the latter in brute force (cloud cluster, ASIC, FPGA, etc.) attacks. The fundamental impetuses of scrypt (a PBKDF rather than an unauthenticated hash function) was a righteous and necessary advance that must never be forgotten with each fashionable iteration of newness that seems to lose sight of how faster or newer isn’t always automatically better.