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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux