Re: RFC: Another proposed hash function transition plan

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 6, 2017, 21:53 UTC
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:

Show 7 quoted lines

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

Show 8 quoted lines

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