I’m disappointed that they didn’t discuss my favorite feature of BLAKE3: it’s a tree hash. If you have a file and the BLAKE3 hash of that file, you can generate a proof that a portion of the file is correct. And you can take a file, split it into pieces (of known length and offset), hash them as you receive them, and then assemble them into the full file and efficiently calculate the full file’s hash. The other options cannot do this, although you could certainly build this on top of them.
Imagine how much better S3 would be if it used BLAKE3 instead of MD5. (Hah, S3 and its competitors don’t even manage to fully support MD5 for multipart uploads, although they could support BLAKE3 very well with multipart uploads!)
This seems wrong to me? I would expect you could only verify the entire file.
For more on this see Section 6.4 of our paper: https://docs.google.com/viewer?url=https://github.com/BLAKE3...
And the Bao repo: https://github.com/oconnor663/bao
> If you have a file and the BLAKE3 hash of that file
To me that means the final hash. If you have the full tree of hashes that is a different story!
PS. Thanks for making BLAKE3! I use it in several pieces of software.
But this isn’t the desired behavior! If you upload the same logical bytes as a single part or as multiple parts, you should get the same thing, and BLAKE3 could do this.
If you care about speed, security and simplicity, and you don't care about NIST compliance, BLAKE3 is hard to beat.
That's what precisely happened to BLAKE with BLAKE2/3, isn't it?
My initial argument was meant to highlight the difference between BLAKE and its successors. However, I have no idea what you back your statements with, BLAKE3 in fact _is_ BLAKE2s with reduced round + tree-based structure on top of it. The authors even directly mention it in the spec.
> K12 and TurboSHAKE on the other hand are literally the same permutation with fewer rounds
It's true for TurboSHAKE, but as for K12, it builds a tree-based structure on top of TurboSHAKE by the virtue of Sakura encoding (similar to what Bao encoding is used for in BLAKE3).
IANAC, so I won't make any claims about cryptographical strengths of the functions.
In my mind Sakura and Bao are doing very different things. Sakura is a general framework for defining sound hash functions, while Bao is a BLAKE3-specific interleaving of hash function input and output that let's you do partial/streaming verification.
There was an interesting issue where it turned out that the Sakura security properties (which I studied while I was working on Bao, very helpful) weren't sufficient for what Bao wanted to do. I didn't realize that until a couple colleagues pointed it out years later. Luckily it didn't turn out to be a break in practice: https://github.com/oconnor663/bao/issues/41
On legacy hardware, BLAKE performs well because ALUs perform well.
Octoth0rpe•2mo ago
> [The hash function] also should be second-preimage resistant: For a given message M1, it must be virtually impossible to find a second message M2 where M1 != M2 that produces the same hash hash(M1) == hash(M2).
> These functions should be also collision resistant: it must be virtually impossible to find two messages M1 and M2 where hash(M1) == hash(M2).
amluto•2mo ago
Some care is needed with the definitions. For any hash function, the adversary can compute a bunch of hashes, and those outputs obviously have known first preimages. And a hash function with a known collision has a known second preimage given one of the colliding inputs.
Paedor•2mo ago
coldpie•2mo ago