Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

kerkour.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#11

Post by robobully »

scatbot wrote: post #10

Honestly, I'm skeptical of the whole Keccak-derived ecosystem. The reduced-rounds variants like K12 and TurboShake are trading a conservative security margin for speed, which kinda feels odd when compared to BLAKE3. Meanwhile, BLAKE3 covers everything for real-world use. It's super fast on any input, fully parallelizable and has a built-in key mode. The only real advantage Keccak-based functions seem to have is stand…

> trading a conservative security margin for speed

That's what precisely happened to BLAKE with BLAKE2/3, isn't it?

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#12

Post by 15155 »

scatbot wrote: post #10

Honestly, I'm skeptical of the whole Keccak-derived ecosystem. The reduced-rounds variants like K12 and TurboShake are trading a conservative security margin for speed, which kinda feels odd when compared to BLAKE3. Meanwhile, BLAKE3 covers everything for real-world use. It's super fast on any input, fully parallelizable and has a built-in key mode. The only real advantage Keccak-based functions seem to have is stand…

Keccak is substantially more simple/elegant from a hardware design standpoint because it has no addition operations - there's no comparison. fMax is way, way easier to obtain, and it's way easier to implement and understand.

On legacy hardware, BLAKE performs well because ALUs perform well.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#13

Post by scatbot »

robobully wrote: post #11
scatbot wrote: post #10

Honestly, I'm skeptical of the whole Keccak-derived ecosystem. The reduced-rounds variants like K12 and TurboShake are trading a conservative security margin for speed, which kinda feels odd when compared to BLAKE3. Meanwhile, BLAKE3 covers everything for real-world use. It's super fast on any input, fully parallelizable and has a built-in key mode. The only real advantage Keccak-based functions seem to have is stand…

> trading a conservative security margin for speed That's what precisely happened to BLAKE with BLAKE2/3, isn't it?

Not really. BLAKE3 isn’t a reduced-round tweak of BLAKE2 like K12 is for Keccak. It's a different construction that still meets its full security target. K12 and TurboSHAKE on the other hand are literally the same permutation with fewer rounds, which actually reduces Keccak's security margin. The situations are not really comparable.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#14

Post by UltraSane »

amluto wrote: post #3

> We will evaluate these functions on 3 points: 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…

Isn't the hash of multipart uploads just the hash of all the hashes of each part? I have actually replicated the multipart hash locally.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#15

Post by oconnor663 »

EnPissant wrote: post #9
amluto wrote: post #3

> We will evaluate these functions on 3 points: 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…

> 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 This seems wrong to me? I would expect you could only verify the entire file.

This is a difference between BLAKE3 and most other hash functions. In the usual arrangement ("Merkle–Damgård"), each block depends on the previous one, so the only way to verify some "slice" of the input is to re-hash the whole thing. But when you arrange the input into a tree shape (a "Merkle tree") instead, suddenly the right half of the tree does not depend on the left half until the very last step at the very top. If you give me the input to that last step, I can verify that it matches the root hash that I know, now I have the hashes ("chaining values") I'd need to verify either the left half or the right half without the other. Then I do our favorite trick in computer science, which is to recursively apply that same procedure all the way down, until I have an efficient "path" to whatever part of the tree I actually care about.

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

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#16

Post by oconnor663 »

scatbot wrote: post #13
robobully wrote: post #11

Earlier quoted context omitted.

> trading a conservative security margin for speed That's what precisely happened to BLAKE with BLAKE2/3, isn't it?

Not really. BLAKE3 isn’t a reduced-round tweak of BLAKE2 like K12 is for Keccak. It's a different construction that still meets its full security target. K12 and TurboSHAKE on the other hand are literally the same permutation with fewer rounds, which actually reduces Keccak's security margin. The situations are not really comparable.

BLAKE3 does reduce the round count relative to BLAKE2, and the underlying compression functions are similar enough that it is an apples-to-apples comparison. Our rationale for doing that was described in https://eprint.iacr.org/2019/1492.pdf, which also argued that Keccak could reduce their round count even farther than they did.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#17

Post by amluto »

UltraSane wrote: post #14
amluto wrote: post #3

> We will evaluate these functions on 3 points: 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…

Isn't the hash of multipart uploads just the hash of all the hashes of each part? I have actually replicated the multipart hash locally.

Something vaguely along those lines, and not the same thing on Google vs AWS.

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.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#18

Post by robobully »

scatbot wrote: post #13
robobully wrote: post #11

Earlier quoted context omitted.

> trading a conservative security margin for speed That's what precisely happened to BLAKE with BLAKE2/3, isn't it?

Not really. BLAKE3 isn’t a reduced-round tweak of BLAKE2 like K12 is for Keccak. It's a different construction that still meets its full security target. K12 and TurboSHAKE on the other hand are literally the same permutation with fewer rounds, which actually reduces Keccak's security margin. The situations are not really comparable.

> BLAKE3 isn’t a reduced-round tweak of BLAKE2 It's a different construction

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.

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#19

Post by [deleted] »

amluto wrote: post #17
UltraSane wrote: post #14

Earlier quoted context omitted.

Isn't the hash of multipart uploads just the hash of all the hashes of each part? I have actually replicated the multipart hash locally.

Something vaguely along those lines, and not the same thing on Google vs AWS. 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.

[deleted]

Re: Choosing a hash function for 2030 and beyond: SHA-2 vs. SHA-3 vs. BLAKE3

#20

Post by [deleted] »

oconnor663 wrote: post #15
EnPissant wrote: post #9

Earlier quoted context omitted.

> 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 This seems wrong to me? I would expect you could only verify the entire file.

This is a difference between BLAKE3 and most other hash functions. In the usual arrangement ("Merkle–Damgård"), each block depends on the previous one, so the only way to verify some "slice" of the input is to re-hash the whole thing. But when you arrange the input into a tree shape (a "Merkle tree") instead, suddenly the right half of the tree does not depend on the left half until the very last step at the very top…

[deleted]
Post reply on HN