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

151–160 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#151

Post by ris »

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.

Unless any of your users ever try and use a >72 character password.

Re: Blake3 is 10 times faster than SHA-2

#152

Post by masklinn »

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 official Blake3 site / repo actually covers this itself:

> NOTE: BLAKE3 is not a password hashing algorithm, because it's designed to be fast, whereas password hashing should not be fast. If you hash passwords to store the hashes or if you derive keys from passwords, we recommend Argon2.

Re: Blake3 is 10 times faster than SHA-2

#153

Post by masklinn »

aaronmdjones wrote: post #136
SkyMarshal wrote: post #135

Earlier quoted context omitted.

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

Also PBKDF2 is really easy to implement if you have a cryptographic hash (even more so with a ready-made HMAC), which is useful if you can't or don't want to pull in dependencies.

Re: Blake3 is 10 times faster than SHA-2

#154

Post by masklinn »

ris wrote: post #151
stevefan1999 wrote: post #121

Earlier quoted context omitted.

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.

Unless any of your users ever try and use a >72 character password.

TBF that's super easy to work around: just prehash the key.

In fact, an other risk of bcrypt is that any nul byte will truncate the key, so you probably want to hash the password with something else (SHA384 or SHA512/256 for instance) then base64/base85-encode it before passing it to bcrypt.

Re: Blake3 is 10 times faster than SHA-2

#155

Post by masklinn »

throwaway838475 wrote: post #129
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

The correct term is KDF, PBKDF is a specific KDF algorithm.

Re: Blake3 is 10 times faster than SHA-2

#156

Post by mbar84 »

lucb1e wrote: post #16

Speed comparison from the BLAKE3 authors: https://github.com/BLAKE3-team/BLAKE3/ I hadn't heard of BLAKE3 before (I thought BLAKE2b was the latest and greatest), judging by commits from the repositories of that user it's about half a year old now. Paper's abstract starts with: > BLAKE3 [is] an evolution of the BLAKE2 cryptographic hash that is both faster and also more consistently fast across different platforms and…

An A4 booklet of the paper, if you're into printing out the interwebs: https://mbarkhau.keybase.pub/pdfs/blake3_a4_booklet.pdf?dl=1

Re: Blake3 is 10 times faster than SHA-2

#157

Post by rhn_mk1 »

lucb1e wrote: post #147
rhn_mk1 wrote: post #142

Earlier quoted context omitted.

> Heck, if anything in this comment is new to you, you'll want to steer clear of such low-level decisions and just use a library that makes the decision for you. This reads very condescending: I posed the question to learn something, not be told off.

I'm sorry, I hate it when others do that and don't notice when I do it myself apparently. It was really just meant to be read in the literal sense and not as that such a person is of less value or stupid. It can easily (and has) lead to security breaches if assumptions are made about this. I'm not saying you don't know the difference between md5 and crc32, but if anyone doesn't yet know that, then it's risky to make…

> Cryptographers commonly advise non-experts to use a library to do things for you

On the high level, the problem is that libraries are usually "CRC32", "MD5", "SHA256", etc. There's no guiding resource that I have found that matches use cases to libraries, which is where the initial question comes from.

That is, unless you meant a library that covers the entire use case, but there isn't always one.

Re: Blake3 is 10 times faster than SHA-2

#158

Post by JdeBP »

oconnor663 wrote: post #127
JdeBP wrote: post #115

Earlier quoted context omitted.

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

Straight talk, should I watch this show? :)

Are you prepared to cope with the idea that, more than 7 centuries from now, a tetchy oblong plastic computer will be able to easily find collisions in any hash algorithm that you can come up with and take over any system that strikes its fancy?

... and that it is in the hands of Kerr Avon?

Re: Blake3 is 10 times faster than SHA-2

#159

Post by fanf2 »

oconnor663 wrote: post #127
JdeBP wrote: post #115

Earlier quoted context omitted.

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

Straight talk, should I watch this show? :)

A friend recently wrote a re-watch review: https://nwhyte.livejournal.com/tag/tv:%20blakes%207

Re: Blake3 is 10 times faster than SHA-2

#160

Post by SlowRobotAhead »

garmaine wrote: post #145
bscphil wrote: post #126

Earlier quoted context omitted.

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.)

He's talking about 12 to 16 byte outputs though, which is 96-128 bits of preimage resistance, and only 48-64 bits of collision resistance.. which would be very broken today.

Mostly.

There are 12-16 byte hash or hash-like results are plenty secure. They’re keyed though.

The output from HMAC and AEAD ciphers with no encryption (think the additional data portion of ChaCha20-Poly1305 in a Nonce-MAC mode)... or maybe I’m wrong because these require nonces and keys.

Post reply on HN