Live data from Hacker News

Blake3 is 10 times faster than SHA-2

nextjournal.com

11–20 of 171 posts

Re: Blake3 is 10 times faster than SHA-2

#11
post #3

Earlier quoted context omitted.

Blake3 is not for use in a password hashing algorithm; those have different goals. Check out Argon2 or bcrypt for that.

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 to compare and compute with).

For cryptographic purposes (authenticity, integrity) you'd use a medium speed algorithm like SHA2/3, Blake2/3, etc. which are reasonably fast and essentially guarantee there won't be collisions (i.e. it's computationally hard to come up with collisions). These are meant to be computed quickly and potentially in parallel because you want to be able to verify data fast.

For password hashing you'd use a slow algorithm like bcrypt/scrypt or Argon2. These are designed specifically to be slow; some also use lots of memory specifically to slow down parallel attackers. You want password hashing to be relatively slow because you need to protect low-entropy data (a typical password only has a few dozen bits of security). By making the algorithm deliberately slow you would ensure that an attacker can't quickly guess the password, even if they have the hash.

These are the three major categories of hash; knowing which one to use in which application is pretty important. Don't mix them up!

Re: Blake3 is 10 times faster than SHA-2

#12

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?

I guess Most would use rainbow tables so it wouldn't matter.

Re: Blake3 is 10 times faster than SHA-2

#13
post #6

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?

For general purpose algorithms yes. Blake3 is not a password hashing algorithm it’s a general purpose one, used for checksums or verifying 2 files are the same etc. For password hashing you’re correct they should be slow, bcrypt for example.

> For password hashing you’re correct they should be slow, bcrypt for example.

Slowness is not the quality of a hashing algorithm that guarantees anything :)

Re: Blake3 is 10 times faster than SHA-2

#14

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 can always make a fast hashing algorithm into a slow-enough password hashing algorithm by repeating it multiple times (as with PBKDF2) or better yet using a construction that also uses a minimum amount of memory, not just computational time. For most cryptographic applications (signing data in transit, signing data at rest, computing things like Merkle trees for applications like git and dm-verity), you want a hash that is fast to compute. It's basically only password hashing and cryptocurrency mining that needs to be slow.

BLAKE3's readme says: (https://github.com/BLAKE3-team/BLAKE3)

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.

Argon2 (https://github.com/P-H-C/phc-winner-argon2/blob/master/argon...) is based on BLAKE2b.

Re: Blake3 is 10 times faster than SHA-2

#15

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?

Faster is always a good thing for a hashing primitive.

For hashing passwords, you should not directly use a hashing primitive but instead stretch/iterate it through a higher-level algorithm, such as Argon2, that will (1) slow it down and (2) salt it.

Re: Blake3 is 10 times faster than SHA-2

#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 input sizes. BLAKE3 supports an unbounded degree of parallelism, using a tree structure that scales up to any number of SIMD lanes and CPU cores. On Intel Cascade Lake-SP, peak single-threaded throughput is 4× that of BLAKE2b, 8× that of SHA-512, and 12× that of SHA-256, and it can scale further using multiple threads. BLAKE3 is also efficient on smaller architectures [like] 32-bit ARM1176

In the introduction, the reason for BLAKE3 is described:

> A drawback of BLAKE2 has been its large number of incompatible variants. The performance tradeoffs between different variants are subtle, and library support is uneven. BLAKE2b is the most widely supported, but it is not the fastest on most platforms. BLAKE2bp and BLAKE2sp are more than twice as fast on modern x86 processors, but they are sparsely supported and rarely adopted. BLAKE3 eliminates this drawback. It is a single algorithm with no variants

Paper: https://github.com/BLAKE3-team/BLAKE3-specs/ (By the way, the download doesn't work for me in the latest Firefox on Linux and GitHub's rendering is plain awful. Not sure if anyone else can reproduce that or if my Firefox is broken.)

Re: Blake3 is 10 times faster than SHA-2

#18

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?

Different hashing functions have different purposes. More specifically a hashing function used for authenticating data must be fast, so should never be used for password hashing.

Password hashing should always be performed using a hashing function designed specifically to prevent high speed execution - for that reason modern password hashing functions are both computationally slow (because of course), but also use large amounts of memory (to inhibit parallel execution).

Re: Blake3 is 10 times faster than SHA-2

#19
This is a bit pointless, since it does not say on which platform the comparison is made.

In any case, KangarooTwelve [1][2] (on AVX-512) is also 10x faster than SHA-256.

KangarooTwelve is a fast hash function of the Keccak family (from which the SHA-3 derives from), and it is clearly what BLAKE3 tries to catch up with.

However, KangarooTwelve probably benefits from the more extensive scrutiny that SHA-3 has received and will receive, and (from a performance standpoint) from future HW extensions that will speed it up even more (the first one appeared on ARMv8.2).

[1] https://keccak.team/files/KangarooTwelve.pdf

[2] https://www.cryptologie.net/article/393/kangarootwelve/

Post reply on HN