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

71–80 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#71

Post by nneonneo »

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 effectively guaranteeing no collisions or any way of reversing the hash (pre-image attack). This makes them ideal for stuff like checking file integrity, message authentication, inputs for cryptographic signatures and the like. But since they’re meant to be fast, they’re very poor choices for hashing low-entropy data such as passwords - attackers can test vast numbers of passwords (even if you salt!!) on GPU hardware.

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). These algorithms are resistant to parallelization, so attackers will only be able to test a small number of passwords per second. This slows attackers down and can prevent them from recovering passwords that might be recoverable if stored using SHA-2, etc.

Re: Blake3 is 10 times faster than SHA-2

#73

Post by tylersmith »

ganzuul wrote: post #69
dathinab wrote: post #64

Earlier quoted context omitted.

> which argues that we use too many rounds in symmetric constructions: our security margins are too high and don't match any of the best "practical" attacks. We're too paranoid for our own good. He suggests reducing the number of rounds for a number of constructions like AES, SHA-3, Blake2, etc. This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. A view years…

Agreed. We are not just securing for today, we are securing for perhaps decades into the future. If we don't know for sure what the threat is, then the right measure of paranoia is as much as we can afford. We are not just securing ourselves, but our social network too. Something you do can be used to discredit your kids and grand-kids a long time from now.

Why not increase the rounds then? What makes the current security margins acceptable but not smaller margins?

Re: Blake3 is 10 times faster than SHA-2

#74

Post by nolok »

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 their "meant to be slow" job, algorithm like bcrypt are built in a way that makes it extremely hard if not impossible to run on cheap massively parallelized hardware (eg: CUDA on GPU).

Re: Blake3 is 10 times faster than SHA-2

#76

Post by kragen »

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…

Also you can do the stretching in the browser client (“server relief”) without losing security. Historically this would have meant a big performance penalty (and thus an advantage for attackers, who don't need to use your code) but JS and wasm are fast enough now that the price is fairly low.

Re: Blake3 is 10 times faster than SHA-2

#77

Post by littlestymaar »

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…

This is a good time to ask for a question I have always wondered about these slow hash functions: are they slow because they are computationally intensive or is it that they have other tricks that makes them slow without costing too much load on your server (like needing RAM access, syscalls or anything that add latency but not much CPU load). If it's the former, isn't it a good DOS target, making your server busy hashing random crap and unable to process other requests?

Re: Blake3 is 10 times faster than SHA-2

#78

Post by dpc_pw »

littlestymaar wrote: post #77
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…

This is a good time to ask for a question I have always wondered about these slow hash functions: are they slow because they are computationally intensive or is it that they have other tricks that makes them slow without costing too much load on your server (like needing RAM access, syscalls or anything that add latency but not much CPU load). If it's the former, isn't it a good DOS target, making your server busy ha…

They are computationally slow, no tricks. The purpose is to prevent attackers from calculating the plain passwords if they actually got access to the content of your DB. They are not that slow (let's say less than a second to calculate) - fast enough for your user to not notice , slow enough so that attacker can't do gazillion tries per second with their GPU or something.

As per DOS: rate limit per ip and account, and it's not an issue.

Re: Blake3 is 10 times faster than SHA-2

#79

Post by tgb »

kragen wrote: post #76
nolok wrote: post #74

Earlier quoted context omitted.

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

Also you can do the stretching in the browser client (“server relief”) without losing security. Historically this would have meant a big performance penalty (and thus an advantage for attackers, who don't need to use your code) but JS and wasm are fast enough now that the price is fairly low.

Can you elaborate? This doesn't sound right to me but I don't know much about this.

Re: Blake3 is 10 times faster than SHA-2

#80

Post by wongarsu »

littlestymaar wrote: post #77
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…

This is a good time to ask for a question I have always wondered about these slow hash functions: are they slow because they are computationally intensive or is it that they have other tricks that makes them slow without costing too much load on your server (like needing RAM access, syscalls or anything that add latency but not much CPU load). If it's the former, isn't it a good DOS target, making your server busy ha…

They are computationally expensive. scrypt and Argon2 also depend on RAM access for their slowness, since that's much harder to parallelize (compute is easier to scale than RAM bandwidth). When your CPU can do hyperthreading that property might help recover some of that execution time.

It is a good DOS target, you should definitely rate limit logins to mitigate that. Other strategies are requiring captchas for login or letting the client execute the hash function and just doing a simple (fixed time) comparison on the server side.

Post reply on HN