5 ms·

Honestly, I'm skeptical of the whole Keccak-derived ecosystem. The reduced-rounds variants like K12 and TurboShake are trading a conservative security margin fo

by scatbot 10mo ago

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 standardization and potential hardware acceleration. If you care about speed, security and simplicity, and you don't care about NIST compliance, BLAKE3 is hard to beat.

robobully 10mo ago
> trading a conservative security margin for speed That's what precisely happened to BLAKE with BLAKE2/3, isn't it?
- scatbot 10mo ago
  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.
  - oconnor663 10mo ago
    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 https://eprint.iacr.org/2019/1492.pdf, which also argued that Keccak could reduce their round count even farther than they did.
  - robobully 10mo ago
    > 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.
    - oconnor663 10mo ago
      > similar to what Bao encoding is used for in BLAKE3 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 https://github.com/oconnor663/bao/issues/41
15155 10mo ago
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.

by scatbot 10mo ago

robobully 10mo ago

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

scatbot 10mo ago
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.
- oconnor663 10mo ago
  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 https://eprint.iacr.org/2019/1492.pdf, which also argued that Keccak could reduce their round count even farther than they did.
- robobully 10mo ago
  > 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.
  - oconnor663 10mo ago
    > similar to what Bao encoding is used for in BLAKE3 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 https://github.com/oconnor663/bao/issues/41

15155 10mo ago

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.