Linus on Git and SHA-1
Linus's transition plan seems to involve truncating SHA-256 to 160-bits. This is bad for several reasons:- 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- Post-quantum, this means there will only be 80-bits of preimage resistance(Also: if he's going to truncate a hash, he use SHA-512, which will be faster on 64-bit platforms)Do either of these weak security levels impact Git?Preimage resistance does matter if we're worried about attackers reversing commit hashes back into their contents. Linus doesn't seem to care about this one, but I think he should.Collision resistance absolutely matters for the commit signing case, and once again Linus is downplaying this. He starts off talking about how they're not doing that, then halfway through adding a "oh wait but some people do that", then trying to downplay it again by talking about how an attacker would need to influence the original commit.Of course, this happens all the time: it'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)Linus just doesn't take this stuff seriously. I really wish he would, though.