Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 16, 2017, 21:12 UTC
Message-ID: <xmqqr2yjwsb6.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqq37azy7ru.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

Show 15 quoted lines

> Adam Langley <agl@google.com> writes:
>
>> However, as I'm not a git developer, I've no opinion on whether the
>> cost of carrying implementations of these functions is worth the speed
>> vs using SHA-256, which can be assumed to be supported everywhere
>> already.
>
> Thanks.
>
> My impression from this thread is that even though fast may be
> better than slow, ubiquity trumps it for our use case, as long as
> the thing is not absurdly and unusably slow, of course.  Which makes
> me lean towards something older/more established like SHA-256, and
> it would be a very nice bonus if it gets hardware acceleration more
> widely than others ;-)

Ah, I recall one thing that was mentioned but not discussed much in the thread: possible use of tree-hashing to exploit multiple cores hashing a large-ish payload. As long as it is OK to pick a sound tree hash coding on top of any (secure) underlying hash function, I do not think the use of tree-hashing should not affect which exact underlying hash function is to be used, and I also am not convinced if we really want tree hashing (some codepaths that deal with a large payload wants to stream the data in single pass from head to tail) in the context of Git, but I am not a crypto person, so ...