Re:Linus on Git and SHA-1
by hermitdev on Saturday February 25, 2017 @04:15PM
(#13733866)
Although, I generally defer to someone such as Linus in having far more domain knowledge such as this, but I'm concerned willingness to just drop bits of the hash like this. I mean 20-30 years ago, I could quasi understand for the sake of performance, but are we really so concerned about performance of a few clock cycles vs opening ourselves to a known vulnerable attack?
[ Parent
| on HN ]
I think the truncation is considered because a lot of software assumes git commit id has 160 bit length. It's not because of performance.
There are only 2 reasonable rationales for the 160 bit restriction: it was arbitrary because that was the length of the chosen hash, or for performance (and no one will ever need more that 640kb of RAM, or 160 bits of hash). I'm guessing it was probably the first, though, and Linus designed for the immediate now, and not for the future.
It's not even a "restriction", so much as a fragile ecosystem of tools that parse the output of git commands. A lot of them assume particular column widths.
What is this known vulnerable attack you are talking about? The birthday paradox applies to every hashing function.
While there may not be a known, direct, attack against git, WebKit's SVN repository was demonstrably attacked by the SHA-1 vulnerability, oddly by their own developers today (or yesterday?). That it took that little time from a PoC to an actual production issue leads me to believe it wouldn't take long for a dedicated individual or team to extend the vulnerability to git and it's "mitigation" involving the header.
I prefer not to take the bury my head in the sand approach to this, at least when it comes to public repositories.