3 ms·

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

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. Even attacking SHA2-256/128 would be quite difficult as I understand it, even though it's the same length as MD5. Truncated hashes also of course have the great property that they mitigate the length extension in Merkle-Damgard

duskwuff 5y ago
> I was surprise that no one suggested truncating SHA-256 to 160 bits... To do that, you have to stop generating commit hashes with SHA-1, breaking compatibility with existing git clients. And if you're going to do that, you might as well just use the whole SHA-256 hash, since compatibility is out the window already.
a1369209993 5y ago
> 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.

duskwuff 5y ago

> I was surprise that no one suggested truncating SHA-256 to 160 bits... To do that, you have to stop generating commit hashes with SHA-1, breaking compatibility with existing git clients. And if you're going to do that, you might as well just use the whole SHA-256 hash, since compatibility is out the window already.

a1369209993 5y ago

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