Re: Suggestion on hashing

From: Bill Zaumen <bill.zaumen@gmail.com>
Date: Dec 3, 2011, 21:21 UTC
Message-ID: <1322947314.1763.41.camel@yos>
In-Reply-To: <20111203150842.GA4442@sigill.intra.peff.net>

On Sat, 2011-12-03 at 10:08 -0500, Jeff King wrote:

Show 16 quoted lines

> > 
> > Suppose I make the digest pluggable, something I intended to do
> > eventually anyway?  Then you just use the existing SHA-1 as an
> > object identifier and the new digest in a signature chain?  What I
> > did was essentially to compute the new digest (using a CRC as the
> > trivial case) whenever an object's SHA-1 hash is computed, plus
> > using the new digest for low-cost collision checks.
> 
> If you make the digest stronger (or pluggable) and include it in the
> actual objects themselves, then you have a start on (2).
> 
> I'd drop all of the digest-exchange bits from the protocol, as the
> actual signatures are the real, trustable verification. I don't think
> you can drop the external storage of the digests, which is one of the
> ugliest bits. You'll be asking for the digests all the time to create
> new commit objects, so you need to have it at hand without rehashing.

The digest-exchange bits, including the tests and response to errors, is only 222 lines of new code, so its really a minor part. The rest takes care of what you referred to as "one of the ugliest bits," so I think it is useful to have available - you can then try various ways of improving the authentication of commit objects without having to do a lot of initial work.

I can make those changes - probably over the next couple of weeks or so (have some other non-related things to take care of) and then send a new set of patches.

Show 6 quoted lines

> 
> And I wouldn't get my hopes up that this will go into git any time soon.
> At this point, we're really guessing about how broken SHA-1 will be in
> the future, and how much we are going to want to care.
> 
> Just my two cents.

Thanks for the discussion. I might add that it is not just a question of how broken SHA-1 is. If an IT department is considering adopting Git as the company's revision control system and authentication is important to the company, an IT manager may not accept SHA-1 for authentication purposes because NIST claims SHA-1 is not adequate for authentication in general and explaining to upper management why NIST's statement is not applicable given the way SHA-1 is used in Git is much harder than saying, "Git follows the current best practices regarding authentication." That statement is a simple check-list item one can show upper management in comparing alternatives.

Such issues (making technical choices for non-technical reasons) have come up before - I once worked on a high-speed (for the time) networking project and our manager mentioned that transferring medical records such as X-ray pictures was one application - they do not accept lossy data compression because, even if it is completely adequate, in a malpractice suit, the plaintiff's lawyer would say, "And they purposely threw away data critical to my client's health," which would sound pretty damning to a typical jury. The legal risk outweighed the cost of the additional bandwidth.