Re: Suggestion on hashing

[Bill Zaumen <bill.zaumen@gmail.com>]

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

> > 
> > 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.

> 
> 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.