Re: SHA1 collisions found

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 24, 2017, 18:14 UTC
Message-ID: <xmqqk28f4fti.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <nycvar.QRO.7.75.62.1702240943540.6590@qynat-yncgbc>

David Lang <david@lang.hm> writes:

Show 17 quoted lines

> On Fri, 24 Feb 2017, Junio C Hamano wrote:
>
>> *1* In the above toy example, length being 40 vs 64 is used as a
>>    sign between SHA-1 and the new hash, and careful readers may
>>    wonder if we should use sha-3,20769079d22... or something like
>>    that that more explicity identifies what hash is used, so that
>>    we can pick a hash whose length is 64 when we transition again.
>>
>>    I personally do not think such a prefix is necessary during the
>>    first transition; we will likely to adopt a new hash again, and
>>    at that point that third one can have a prefix to differenciate
>>    it from the second one.
>
> as the saying goes "in computer science the interesting numbers are 0,
> 1, and many", does it really simplify things much to support 2 hashes
> vs supporting more so that this issue doesn't have to be revisited?
> (other than selecting new hashes over time)

It seems that I wasn't clear enough, perhaps? The scheme I outlined does not have to revisit this issue at all. It already declares what you need to do when you add the third one.

If it is not 40 or 64 bytes long, you just write it out. If it is one of these length, then you add some identifying prefix or postfix. IOW, if the second one is sha-3 and the third one is blake (both used at 256-bit), then we would have three kinds of names, written like so:

    20769079d22a9f8010232bdf6131918c33a1bf69
    20769079d22a9f8010232bdf6131918c33a1bf6910232bdf6131918c33a1bf69
    3,20769079d22a9f8010232bdf6131918c33a1bf6910232bdf6131918c33a1bf69

and the readers can well tell that the first one, being 40-chars long, is SHA-1, the second one, being 64-chars long, is SHA-3, and the last one, with the prefix '3' (only because that is the third one officially supported by Git) and being 64-chars long, is blake, for example.

I do not particularly care if it is prefix or postfix or something else. A not-so-well-hidden agenda is to avoid inviting people into thinking that they can use their choice of random hash functions and and claim that their hacked version is still a Git, as long as they follow the object naming convention. IOW, if you said something like:

 * 40-hex is SHA-1 for historical reasons;
 * Others use hash-name, colon, and then N-hex.

you are inviting people to start using

    md5,54ddf8d47340e048166c45f439ce65fd

as object names.