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

51–60 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#51

Post by lucb1e »

doomrobo wrote: post #45
lucb1e wrote: post #34

Earlier quoted context omitted.

The only author of BLAKE3 that spoke there was JP (@veorq). The day matches but the title of his talk is "Too Much Crypto". Is that where it was announced? (Quick link to program: https://rwc.iacr.org/2020/program.html#day-2020-01-09 )

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.

Re: Blake3 is 10 times faster than SHA-2

#52

Post by baby »

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.

yup, Blake3 is 1-day old (released yesterday).

Re: Blake3 is 10 times faster than SHA-2

#53

Post by baby »

diego_moita wrote: post #2

Is "faster" always a good thing in hashing algorithms? Suppose a hashed password database falls into wrong hands. If they're hashed with a faster algorithm wouldn't it be easier to try a dictionary attack to discover the real passwords?

you are not supposed to use a hash to store a password (because hash functions are super fast), but a password hashing function instead like Argon2.

Re: Blake3 is 10 times faster than SHA-2

#54

Post by yarg »

nneonneo wrote: post #11
diego_moita wrote: post #5

Earlier quoted context omitted.

Ok, thank you. I understand that it is for implementing things like dictionaries/hash tables.

No, Blake3 is a cryptographic hash algorithm, not for dictionaries or hash tables. It is intended for cryptographic signatures, file/data integrity, message authentication codes, etc. For dictionaries/hash tables you'd typically use a very fast hash algorithm like xxHash, murmurHash, etc. Those are tuned for speed but can have collisions (typically they have very short outputs - 32 or 64 bits - so that they're easy t…

In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way).

With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure.

With user defined data there's even the possibility of maliciously crafted input attempting to force collisions as part of a DOS attack.

You can salt your input, and pretty much eliminate the issue - but as far as I can tell, you'll just end up rolling your own crypto.

Re: Blake3 is 10 times faster than SHA-2

#55

Post by yarg »

yarg wrote: post #54
nneonneo wrote: post #11

Earlier quoted context omitted.

No, Blake3 is a cryptographic hash algorithm, not for dictionaries or hash tables. It is intended for cryptographic signatures, file/data integrity, message authentication codes, etc. For dictionaries/hash tables you'd typically use a very fast hash algorithm like xxHash, murmurHash, etc. Those are tuned for speed but can have collisions (typically they have very short outputs - 32 or 64 bits - so that they're easy t…

In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…

Actually, a counter-point: there might be situations where you want an anti-cryptographic hash function - where similar inputs produce generally similar hashes.

It could have some application as a preprocessing step in clustering (if it could be done efficiently).

Re: Blake3 is 10 times faster than SHA-2

#56

Post by geofft »

ilvez wrote: post #43
TheDong wrote: post #23

Earlier quoted context omitted.

You're being pointlessly pedantic. The commenter above obviously meant "slow to brute-force". You're pedantically interpreting it to mean "slow for a given implementation, even if there are some scenarios under which it would be faster to brute force". What the parent comment meant is clear enough I think, and it's accurate in that context. The whole point of modern hashing algorithms that require memory and have sca…

Wow, so offensive. Didn't mean it that way, but if it turned out that, what a heck then. What I wanted to say was that slowness is not necessary attribute, unless we really seek it. If we could get very good and quick algorithm without being it slow, we would use it. Thanks for misinterpreting my smiley too. Have a good evening there.

> If we could get very good and quick algorithm without being it slow, we would use it.

No, that's simply not true, and that's what the person you replied to was trying to say. For a password hashing algorithm, you actively want it to be slow - to have a mathematically guaranteed minimum amount of time that each attempt takes, regardless of implementation. This is a security property of a password-hashing algorithm. It is a necessary attribute - you can't have a "good" password-hashing algorithm whose output can be computed arbitrarily quickly.

What you might be saying is that if an inefficient implementation is slow, we'd like to speed it up. Sure. The requirement of a good algorithm is that the most efficient implementation possible is slow.

Re: Blake3 is 10 times faster than SHA-2

#57

Post by isopede »

diego_moita wrote: post #2

Is "faster" always a good thing in hashing algorithms? Suppose a hashed password database falls into wrong hands. If they're hashed with a faster algorithm wouldn't it be easier to try a dictionary attack to discover the real passwords?

Another way of making it "slower" is to require more memory to compute your algorithms. The idea being that lots of memory is expensive no matter how clever you are with the computation.

Re: Blake3 is 10 times faster than SHA-2

#58

Post by baby »

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 constructions like AES, SHA-3, Blake2, etc.

[1]: https://eprint.iacr.org/2019/1492.pdf

Blake3 is in part a reduction of number of rounds (so it's faster), it's also a bit of a design change (the round function, and the parallelization), and it's now just one multi-purpose function (instead of several instances) that takes an arbitrary-length input and gives an arbitrary-length output.

My questions are:

* what are standards using Blake2 (like Noise) going to do?

* what do cryptanalysts think?

* is it really that fast? (I'll have to benchmark this for my own use-case.)

Re: Blake3 is 10 times faster than SHA-2

#60

Post by earenndil »

yarg wrote: post #55
yarg wrote: post #54

Earlier quoted context omitted.

In any situation where a hashcode is cacheable (which seems to me to cover all situations where a hashcode even makes sense) a cryptographic hash function might not be such a bad idea (especially if you're IO bound in any way). With a bad hash function you can end up with a high level of bucket utilisation, significantly reducing the efficiency of the structure. With user defined data there's even the possibility of…

Actually, a counter-point: there might be situations where you want an anti-cryptographic hash function - where similar inputs produce generally similar hashes. It could have some application as a preprocessing step in clustering (if it could be done efficiently).

Easy: for n-byte output, separate input into n equally-sized chunks (pad with zeroes if not enough). For each chunk, XOR all the bytes together.
Post reply on HN