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

111–120 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#111

Post by bawolff »

ganzuul wrote: post #82
tylersmith wrote: post #73

Earlier quoted context omitted.

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

I don't know a reason for why they are acceptable. AES256 is considered quantum-proof, but there exists another theoretical quantum computer design which seems to raise the bar again. I don't know if there exists a theoretical limit for how powerful quantum computers can get.

What other theoretical quantum design?

AES256 is considered quantum proof because grover's algorithm can in theory basically half they key size, and aes128 is secure on normal computers [we are still very very very very far away from a quantum computer that can use grover's algorithm to bruteforce aes128].

I'm not an expert on the subject but i believe a new quantum algorithm that could break aes256 would be a very major breakthrough in designing quantum algorithms.

Re: Blake3 is 10 times faster than SHA-2

#112

Post by jaytaylor »

kragen wrote: post #94
tgb wrote: post #79

Earlier quoted context omitted.

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

It is indeed surprising; it took me a long time to be sure it was safe. Google “server relief”.

Interesting read:

http://ithare.com/client-plus-server-password-hashing-as-a-p...

Re: Blake3 is 10 times faster than SHA-2

#113

Post by garmaine »

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

Re: Blake3 is 10 times faster than SHA-2

#114

Post by kragen »

jaytaylor wrote: post #109
nneonneo wrote: post #101

Earlier quoted context omitted.

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

No, hashing the hash solves the problem.

Re: Blake3 is 10 times faster than SHA-2

#116

Post by jaytaylor »

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.

I see, clever. Thanks!

Re: Blake3 is 10 times faster than SHA-2

#117

Post by pitaj »

jaytaylor wrote: post #112
kragen wrote: post #94

Earlier quoted context omitted.

It is indeed surprising; it took me a long time to be sure it was safe. Google “server relief”.

Interesting read: http://ithare.com/client-plus-server-password-hashing-as-a-p...

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.

Re: Blake3 is 10 times faster than SHA-2

#118

Post by eyegor »

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…

> are they slow because they are computationally intensive...

In general, no. Most "slow" hashing schemes are designed to be memory-hard and highly serial (more threads = more contention, not throughput). Some of the earlier approaches just try to maximize computational requirements, but modern research acknowledges the march of computing power makes that an inherently poor choice for long term sensitive data. Argon2 is just one of the more advanced versions of a memory-hard scheme, building on prior research. I could try to give a poor explanation, but instead I'll link you the spec which is very readable: https://github.com/P-H-C/phc-winner-argon2/blob/master/argon...

Re: Blake3 is 10 times faster than SHA-2

#119

Post by jaytaylor »

pitaj wrote: post #117
jaytaylor wrote: post #112

Earlier quoted context omitted.

Interesting read: http://ithare.com/client-plus-server-password-hashing-as-a-p...

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.

Re: Blake3 is 10 times faster than SHA-2

#120

Post by im3w1l »

pvg wrote: post #70
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…

This seems a quite dangerous way of thinking. New attacks, methods to attack crypto are discovered regularly. It's not, really, because there is obviously some security margin that is too high. It makes a lot of sense to consider and try to quantify what that is. If all we have is some vague 'well, there are always new attacks' then how do we know the current margins are enough? Why not double the rounds, crank up th…

1. As a community: Because you have to balance cost and security. Maybe we could increase them a bit without it stinging too much. But we can't do it boundlessly.

2. As an individual: Because I'd probably mess it up and pick a number of rounds that is e.g. divisible by 23 which weakens the system for some number theoretical reason that's far beyond my understanding.

Post reply on HN