Please document collision-resistance properties of BLAKE3 with less than 256 bits

[joshtriplett]

I'm interested in the collision-resistance and safety of BLAKE3 with less than 256 bits (either via XOF or truncation), for use in applications storing a very large number of hash values and sensitive to storage size.

Would BLAKE3 with 224 bits be considered as safe as SHA-224, SHA-512/224, or SHA3-224? Is that likely to be reasonably safe for years to come?

Would any shorter number of bits be acceptably secure?

If so, what would be the preferred method of obtaining such hashes? XOF, or truncation?

Would those answers vary for other BLAKE-family hashes, which use a larger number of rounds?

(I entirely understand that hash length is a tradeoff. I'm trying to find an acceptable balance between degree of future-proofing and usability in storage-size-sensitive applications.)

[oconnor663]

Would BLAKE3 with 224 bits be considered as safe as SHA-224, SHA-512/224, or SHA3-224?

Yes, the safety considerations are similar across all of those. In the case of SHA-3 only I think there's also a performance benefit to using a shorter output, but for SHA-2 and the BLAKE family there isn't.

Is that likely to be reasonably safe for years to come?

Yes I think so. I can't imagine any practical attack on 224-bit BLAKE3 that wouldn't also be catastrophic for BLAKE3 in general. But I should also ask @sneves or @veorq to weigh in here.

Would any shorter number of bits be acceptably secure?

Yes, the expected relationship between output length and collision resistance should hold all the way down. So if you only needed 4 bits of collision resistance, you could use an 8-bit output.

If so, what would be the preferred method of obtaining such hashes? XOF, or truncation?

In BLAKE3, shorter XOF outputs are prefixes of longer ones, and truncating the regular 256-bit output is equivalent to getting a shorter output from the XOF. Note that this was not the case for BLAKE2, nor is it the case for SHA-2.

Would those answers vary for other BLAKE-family hashes, which use a larger number of rounds?

I think you have the same relationship between hash length and collision resistance across the board. But since BLAKE2 (unlike BLAKE3) does domain separates shorter outputs, using the "native" BLAKE2 length parameter is preferable to truncation if possible, just as a common convention.

Where this sort of distinction matters a lot more is if you have a design that requires multiple independent hash functions. Let me know if that's the case for you, but I'm assuming it's not.

[oconnor663]

Btw, if you happen to be working on tracking build artifacts, that's right up my alley. I was on the Buck team at Facebook back in the day, and a friend and I still maintain a tool called peru that's kind of in the same space.

[sneves]

Any better-than-generic attack that works for n-t-bit output will also apply to the full n-bit output, as you're only giving the attacker more information to work with in that case.

[joshtriplett]

Thanks for the explanation!

Would you consider documenting those details somewhere in the BLAKE3 documentation? Most notably, that BLAKE3 at N bits is collision-resistant to N/2 bits, and that XOF and truncation are equivalent?

[oconnor663]

@joshtriplett I just opened #169 with some proposed doc changes. Let me know what you think.

[joshtriplett]

That looks great! Thank you very much.

[oconnor663]

Merged.