On: Whatever happened to SHA-256 support in Git

[boramalper]

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

[newpavlov → boramalper]

One 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 → newpavlov]

Blake3 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.

[nmadden → boramalper]

You could just truncate SHA-256 to 20 bytes for that matter.

[boramalper → nmadden]

Indeed, it's discussed here 6 months ago: 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).