Re: [PATCH 4/4] csum-file.c: use fast SHA-1 implementation when available

On 2024-09-02 at 13:41:31, Patrick Steinhardt wrote:

I actually think that not adopting this approach would be a big incentive to get people to switch, honestly. We can say, "Need better performance? Use SHA-256." SHA-1 is faster than SHA-256 both when both are in software or both in hardware (because it does less work per round, which is part of why it's insecure), and thus this series actually disincentivizes people from switching because it makes SHA-256 slower by comparison.

We know many people don't care about the security because they're still using MD5 because it's fast and "it's good enough." That, by the way, is absolutely not the opinion of any reputable security or cryptographic organization. Similarly, those organizations would say that SHA-1 should also no longer be used, which is a position I would also endorse.

SHA-1 is not going to last another couple decades. As I mentioned elsewhere in the thread, someone has already built DES (2^56 work) brute force hardware for USD 250,000 and is farming it out for as low as USD 20 per crack. SHA-1 offers 2^61 collision resistance, so a brute force attack is only 32 times harder (if the operations were completely equivalent). That means that if someone built a similar machine for SHA-1 and rented it out, it would probably only cost USD 640 to wreak havoc on any hosting provider still using SHA-1.[0] That assumes the attack doesn't get better, which it probably will. Note that it took only 7 years from the first MD5 collision to an attack which runs in less than a second on a modern computer.

This series also means we have to continue to maintain non-DC versions of SHA-1, which I had hoped to get rid of.

For those reasons, I'm in general opposed to this series.

Yes, under the same conditions as colliding any other body text, as I mentioned elsewhere in the thread. It would overwrite any existing data with the same pack hash because we use rename(2). We would have to use link(2) and die if the file already existed.

[0] Remember, we die on collisions, so for a push with a colliding object or pack over HTTP the user would get a 500 error. Repeat that push a couple thousand times at 2 a.m. and it'll page the on call engineer, who I assure you will not be delighted.