> Truncated hashes also of course have the great property that they mitigate the length extension in Merkle-Damgard To be fair, this is totally irrelevant to g

> Truncated hashes also of course have the great property that they mitigate the length extension in Merkle-Damgard To be fair, this is totally irrelevant to git, since the attacker knows the whole message and can just recompute the extra bits themselves. That said: > I was surprise that no one suggested truncating SHA-256 to 160 bits (same as for SHA2-256/224, or SHA2-512/256). The attacks on SHA-1 are not directly based on the length of the hash, they are based on weaknesses in the algorithm. Very seconded. You could even shove the extra 96 bits in a optional metadata field and have new versions of git throw up a giant air-raid-siren-level error if they don't match (since that will never happen by accident[0]) and still have the full 256-bit-hash worth of security for most purposes. Git already allows (arguably encourages) people to truncate hashes to 28 bits or so at the UI level, so there's precendent for that already. 0: You do not have anywhere near 2^80 commits in the world, much less in the same repo.