BLAKE3 Cryptographic Hash Implementation Preparing For v1.0 Release

[Palu Macil]

What systems? On a Zen2 SHA2-256 is over 2x faster on long messages and this increases to like 4x for very short messages,

It's slower per iteration but uses twice the block size. When hashing files, per byte matters. When calculating a merkle tree, iteration matters. I haven't seen anything like your claim for throughput, though I wish I had the time to benchmark at this moment. I will tip my hat to you and admit I cannot speak as someone whom has benchmarked this comparison myself, but I have read it multiple times. At some point I'll do some additional due diligence.

HMACs are not provably secure unlike other, proper constructions that were designed for the task instead of working around limitations of hash functions that are vulnerable to length extension.
This has nothing to do with collisions per se, but when you use another hack, namely truncation, to gain resistance to length extension you also weaken collision resistance.

HMAC is actually provably as secure as the underlying hash function and can use any hash function (SHA256, BLAKE3, etc). That property is one of the strengths of an HMAC and is exactly what it was designed for. You SHOULD use HMAC for an authenticated hash. There are valid alternatives, but if you don't know a lot about why to pick one, it is a solid choice. I'm a fan of ChaCha20-Poly1305 for some cases, but most of the time I reach for HMAC.

You don't have a length extension vulnerability with an HMAC even if the underlying hash has that vulnerability. You can read up on that if you like. From the wiki page on the vuln: "When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Since HMAC does not use this construction, HMAC hashes are not prone to length extension attacks."

In other words, it has NOTHING to do with collisions. It also does not affect any properly constructed authentication algo. If you don't try rolling your own there, you don't have to worry about it.

HMAC requires you to call the hash function twice, sequentially. A keyed hash function that is resistant to length extension does not require such a construction. BLAKE3 further optimized this in not even requiring you to hash the key because it uses they key as part of its IV so to speak.

From this, it's clear you do know what you're talking about, so I want to make sure I recognize that I see that and could be missing something. I merely have a masters in cybersecurity and work as a developer in the same field, but I admit that the math in cryptography is challenging to me, and there are concepts I need to go over several times because I start to understand the nuances. Furthermore, I am not specialized in cryptoanalysis, and my job is not to make any professional advisement on this area.

As for selling products I have to tell you that I'm not a salesman.

If it wasn't for this one point, I would be likely to be experimenting with BLAKE3 already. When you write security software for people, they require you to use certain algos. Sometimes they require that you call out to libraries that ship with the OS and/or a set of audited DLLs. You can't really sell to Fortune 500 companies without caring what is accepted by their requirements.

All that said, if I was working for a chat app like Signal, I would be making other choices. Would my choices be based upon throughput performance? No, not for a chat app. But there are plenty of other tools where BLAKE3 might be the best choice.