Re: Hash algorithm analysis

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 18, 2018, 15:32 UTC
Message-ID: <20180918153210.GA133875@aiede.svl.corp.google.com>
In-Reply-To: <64c1fc82-8830-bd62-7cc6-ef76ad06f6d5@noekeon.org>

Hi,

A quick note.

Joan Daemen wrote:

> when going over my todo list I was confronted with the mail of Dan
> Shumow on the successor of SHA-1 for git. I know the decision was
> made and it is not my intention to change it, but please see below
> some comments on Dan's arguments.

When the time comes for the next hash change in Git, it will be useful to be able to look back over this discussion. Thanks for adding details.

[...]

> On 30/07/2018 22:01, Dan Shumow wrote:

Show 10 quoted lines

>> So, I also want to state my biases in favor of SHA2 as an employee
>> of Microsoft. [...] As such, and reflecting this bias, in the
>> internal discussions that Johannes alluded to, SHA2 and SHA3 were
>> the primary suggestions.  There was a slight preference for SHA2
>> because SHA3 is not exposed through the windows cryptographic APIs
>> (though Git does not use those, so this is a nonissue for this
>> discussion.)
>
> We find it cynical to bring up a Microsoft-internal argument that is
> actually not relevant to Git.

On the contrary, I am quite grateful that Dan was up front about where his preference comes from, *especially* when the reasons are not relevant to Git. It is useful background for better understanding his rationale and understanding the ramifications for some subset of users.

In other words, consider someone active in the Git project that disagrees with the decision to use SHA2. This explanation by Dan can help such a person understand where the disagreement is coming from and whether we are making the decision for the wrong reasons (because Git on Windows does not even use those APIs).

[...]

Show 7 quoted lines

> 3) The relatively large state in the sponge construction increases
> the generic strength against attacks when the input contains
> redundancy or has a certain form. For instance, if the input is
> restricted to be text in ASCII (such as source code), then the
> collision-resistance grows higher than the nominal 2^{c/2}. Such an
> effect does not exist with narrow-pipe Merkle-Damgård. (This may be
> what Linus had intuitively in mind.)

Interesting.

[...]

> [2] Daniel J. Bernstein, Cost analysis of hash collisions: Will
> quantum computers make SHARCS obsolete? Workshop Record of
> SHARCS'09.

I remember that paper!  Thanks for the pointer.

Sincerely, Jonathan