From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 06 Mar 2017 21:53:39 GMT
Subject: Re: RFC: Another proposed hash function transition plan
Message-ID: <xmqqwpc2m5r0.fsf@junio-linux.mtv.corp.google.com>
In-Reply-To: <CA+55aFxj7Vtwac64RfAz_u=U4tob4Xg+2pDBDFNpJdmgaTCmxA@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So *if* the new object format uses a git header line like
>
>     "blob <size> <sha1>\0"
>
> then it would inherently contain that mapping from 256-bit hash to the
> SHA1, but it would actually also protect against attacks on the new
> hash.

This is easy for blobs as you only need to hash twice.  I am not
sure if you can do the same for trees, though.  For that <sha1> to
be useful, the hash needs to be over the tree contents whose
references are expressed in <sha1>, which in turn would mean...

... ah, you would read these <sha1> off of the object header in the
new world and you do not need to expand the whole thing.  OK, I see
how it could work.

> In fact, in particular for objects with internal format that
> differs between the two hashing models (ie trees and commits which to
> some degree are higher-value targets), it would make attacks really
> quite complicated, I suspect.
>
> And you wouldn't need those "hash" or "nohash" things at all. The old
> SHA1 would simply always be there, and cheap to look up (ie you
> wouldn't have to unpack the whole object).