Subject: Re: [PATCH 2/4] hash.h: scaffolding for _fast hashing variants

From: Junio C Hamano <[email-masked]>
Date: Tue, 03 Sep 2024 13:47:09 -0700

Taylor Blau <[email-masked]> writes:

> I discussed this with brian in the sub-thread where I am talking to
> them, but I think this is already the case. The pack is read in
> index-pack and the checksum is verified without using the _fast hash
> functions, so we would detect:
>
>   - either half of a colliding pair of objects, when reading individual
>     objects' contents to determine their SHA-1s, or
>
>   - a colliding pack checksum, when computing the whole pack's checksum
>     (which also does not use the _fast variants of these functions), and
>
>   - a mismatched pack checksum, when verifying the pack's checksum
>     against the one stored in the pack.
>
>>  (2) devise a transition plan to use a hash function that computes a
>>      value that is different from SHA-1 (or SHA-256 for that
>>      matter); and
>>
>>  (3) pick a hash function that computes a lot faster but is insecure
>>      and transition to it.
>
> So I do not think that either of these two steps are necessary.

I suspect that it is a wrong conclusion, as I meant (1) to be
prerequisite for doing (2) and (3), that gives us the real benefit
of being able to go faster than SHA1DC or even SHA-256.  If (1) is
unnecessary (because it is already covered), that is great---we can
directly jump to (2) and (3).