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

101–110 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#101

Post by nneonneo »

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.

If you’re going to do this, make sure you still hash the client’s hash output on the server (you can use SHA-2 in this case since the client’s hash output will effectively be high-entropy if salted). Otherwise you will be vulnerable to a “pass the hash” attack where an attacker in possession of your stored password hashes simply passes the hash to login.

Re: Blake3 is 10 times faster than SHA-2

#102

Post by bigcohoneypot »

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…

I get md5 is pretty weak now, but what's wrong with sha-256 and a salt?

Re: Blake3 is 10 times faster than SHA-2

#103

Post by microcolonel »

diegocg wrote: post #96
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…

I don't know what his arguments are, and I don't have much of a clue about crypto, but perhaps his argument could go along the lines of "a secure algorithm shouldn't be secured just by increasing the number of rounds too much"?

His argument is that since a cryptosystem has a set of different algorithms, each of which could compromise the whole system, the number of rounds should be chosen to match the margins across the primitives used, since strengthening one primitive does not improve the overall margins of the system.

Specifically at the end of the paper he argues that the choice of AES rounds is close to reasonable (and warrants little round reduction), and that ChaCha8 matches a reasonable number of rounds on AES (yielding a substantial 2.5x improvement in throughput vs. ChaCha20).

Following from these conclusions, I guess you could say that ChaCha12 is already quite ludicrously good, so ChaCha20 is downright wasteful. Not totally sure I agree yet with the specific numbers, but he makes a good point.

The paper also includes some helpful advice for those attempting to read cryptanalysis papers.

Re: Blake3 is 10 times faster than SHA-2

#104

Post by basilgohar »

bigcohoneypot wrote: post #102
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…

I get md5 is pretty weak now, but what's wrong with sha-256 and a salt?

Salting only protects against rainbow tables, but does next to nothing against brute force attacks because the salt is usually stored adjacent or even as part of the stored password hash.

Re: Blake3 is 10 times faster than SHA-2

#105

Post by temac »

espadrine wrote: post #84
antpls wrote: post #61

Earlier quoted context omitted.

Not sure why you are downvoted. Your table looks more factual than the blake3's github.

RE: the downvotes; while I didn't partake, I know there is history between the BLAKE/BLAKE2/BLAKE3 author, JP Aumasson, and Rurban, in particular related to differing opinions over the publication of SipHash. Differing opinions here means that most of the cryptographic community agree that SipHash clears its claims as a PRF, while Rurban indicated he has found undisclosed vulnerabilities that he wishes not to publish…

Comparing single threaded speeds is also very valid for tons of contexts. Of course if one algo can't be multithreaded, maybe it will be better to use one that can instead, if that's interesting for a particular application, but it won't be necessarily interesting for all applications. So there is no single ordering about which is faster, in this case. If you sometimes needs to compute hashes on a computer that would have multiple unused cores at that moment, the multithreaded hash will have an advantage. If you are always loaded, you better consider the total amount of work; and maybe likewise if you want to prioritize energy efficiency (although it will not be completely linear)

Re: Blake3 is 10 times faster than SHA-2

#107

Post by bawolff »

bigcohoneypot wrote: post #102
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…

I get md5 is pretty weak now, but what's wrong with sha-256 and a salt?

The md5 weakness (that everyone talks about) is about collision resistance, which isn't relavent to password hashing.

Generally you want slow, high cpu & memory hash functions for password hashing. This is the opposite of what md5/sha/blake aim for, as they want to be fast as possible. A fast hash allows the attacker to make many guesses very quickly (i think you can get something like 2 billion sha256 hashes a second with high end gpus). A slow hash makes it harder for the attacker to take lots of guesses (adding high mem usage helps protect against using alternate architectures like fpgas to speed things up).

Anyways, for passwords use something like argon2.

Re: Blake3 is 10 times faster than SHA-2

#108

Post by nneonneo »

bigcohoneypot wrote: post #102
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…

I get md5 is pretty weak now, but what's wrong with sha-256 and a salt?

The Bitcoin network can perform some 10^20 SHA-256 hashes per second. That’s one 11-character upper/lowercase alphanumeric password PER SECOND.

A practical password cracking rig can probably do upwards of 10^11 hashes per second. The same rig can only do 10^5 bcrypt hashes per second.

Re: Blake3 is 10 times faster than SHA-2

#109

Post by jaytaylor »

nneonneo wrote: post #101
kragen wrote: post #76

Earlier quoted context omitted.

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.

If you’re going to do this, make sure you still hash the client’s hash output on the server (you can use SHA-2 in this case since the client’s hash output will effectively be high-entropy if salted). Otherwise you will be vulnerable to a “pass the hash” attack where an attacker in possession of your stored password hashes simply passes the hash to login.

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

Re: Blake3 is 10 times faster than SHA-2

#110

Post by bawolff »

dathinab wrote: post #64
baby wrote: post #58

JP Aumasson just announced Blake3 at Real World Crypto a few days ago during the lightning talks. This was also right after he presented on "Too Much Crypto"[1] 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 construc…

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

> This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly.

He does actually address this counterargument in his paper. In fact most of his paper is a rebuttal to this argument (the status quo wisdom, so to speak).

Post reply on HN