Linus on Git and SHA-1
Linus&#x27;s transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons:<p>- Truncating to 160-bits still has a birthday bound at 80-bits. That would still require a lot more brute force than the 2^63 computations involved to find this collision, but it is much weaker than is generally considered secure<p>- Post-quantum, this means there will only be 80-bits of preimage resistance<p>(Also: if he&#x27;s going to truncate a hash, he use SHA-512, which will be faster on 64-bit platforms)<p>Do either of these weak security levels impact Git?<p>Preimage resistance does matter if we&#x27;re worried about attackers reversing commit hashes back into their contents. Linus doesn&#x27;t seem to care about this one, but I think he should.<p>Collision resistance absolutely matters for the commit signing case, and once again Linus is downplaying this. He starts off talking about how they&#x27;re not doing that, then halfway through adding a &quot;oh wait but some people do that&quot;, then trying to downplay it again by talking about how an attacker would need to influence the original commit.<p>Of course, this happens all the time: it&#x27;s called a pull request. Linus insists that prior proper source code review will prevent an attacker who sends you a malicious pull request from being able to pull off a chosen prefix collision. I have doubts about that, especially in any repos containing binary blobs (and especially if those binary blobs are executables)<p>Linus just doesn&#x27;t take this stuff seriously. I really wish he would, though.