On 2024-09-02 at 13:41:31, Patrick Steinhardt wrote: > Neat. I knew that SHA1DC was slower, but I certainly didn't expect it to > make such a huge difference. > > I of course wish that we just moved on and switched the default to > SHA256, which should provide similar speedups. But that of course > wouldn't help all the projects out there that will use SHA1 for the next > couple decades. 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. > The only exception are of course packfiles, which get generated by the > remote. Is it possible to generate packfiles with colliding trailer > hashes? And if so, how would the client behave if it was served a > packfile with such a collision? 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. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
