Re: [PATCH] Remove non-SHA1dc sha1 implementations

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

 



On Mon, Feb 24, 2020 at 07:37:58AM +0900, Mike Hommey wrote:

> It is 2020, and with the weakening of SHA1 security-wise, there doesn't
> seem to be a reason to support anything else than SHA1dc, with collision
> detection.

One possible reason is that they're way faster than sha1dc (block-sha1
maybe only a little, but openssl's sha1 is over twice as fast).

To be clear, I think the slowdown is worth the extra safety, but:

 - do we still want to care about people who prefer to make the tradeoff
   differently?

 - when we first switched the default to sha1dc, the idea was raised of
   continuing to use a faster implementation for non-security checksums
   (e.g., the checksums at the end of packfiles, index files, etc). I
   don't think anybody ever implemented that, but it's not a terrible
   idea. OTOH, if nobody noticed the bottleneck enough to care, maybe
   it's not worth worrying about.

I'm not convinced the answer to those questions is "yes", but I think
it's worth at least raising them (and arguing against them in the commit
message).

One thing that compels me is the recent report that we still build with
common crypto by default on macOS, which was definitely _not_ intended.
That's a bug that can be fixed, but it wouldn't have happened in the
first place if we only supported sha1dc.

-Peff



[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