3 ms·
Does someone know why SHA-3 isn't considered instead? Wouldn't its sponge construction—that allows outputting ("squeezing") any amount of data[0]—allow git to m
by boramalper 4y ago
Does someone know why SHA-3 isn't considered instead? Wouldn't its sponge construction—that allows outputting ("squeezing") any amount of data[0]—allow git to maintain backward-compatibility with existing tooling by continuing to use the same 20-byte output?
Is it that for d:=160, min(d/2,256) = 80 bits of collision resistance too low to justify the change?
[0] https://en.wikipedia.org/wiki/SHA-3 https://en.wikipedia.org/wiki/SHA-3
- nmadden 4y agoYou could just truncate SHA-256 to 20 bytes for that matter.
- boramalper 4y agoIndeed, it's discussed here 6 months ago: https://news.ycombinator.com/item?id=31852651 https://news.ycombinator.com/item?id=31852651 edit: I've assumed that using SHA-3 would be somehow better but their security guarantees seem to be the same (yet).
- newpavlov 4y agoOne issue with SHA-3 is that it currently (unfortunately) lacks hardware acceleration support, while SHA-256 can be ridiculously fast on modern x86 and ARM chips. BLAKE3 is another potential alternative, it can be used as XOF and can be very fast without hardware support.
- jillesvangurp 4y agoBlake3 would be a good choice. Having a fast hashing algorithm is not a bad thing. Integrity checks involve a lot of hash calculations. That's perhaps a reason Git has stuck with sha1 hashes. They are fast enough and good enough.