Re: RFC v3: Another proposed hash function transition plan

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Sep 13, 2017, 22:51 UTC
Message-ID: <20170913225158.GR27425@aiede.mtv.corp.google.com>
In-Reply-To: <CANgJU+Wv1nx79DJTDmYE=O7LUNA3LuRTJhXJn+y0L0C3R+YDEA@mail.gmail.com>

Hi,

Yves wrote:

> On 13 September 2017 at 14:05, Johannes Schindelin

Show 8 quoted lines

>> For example, I am still in favor of SHA-256 over SHA3-256, after learning
>> some background details from in-house cryptographers: it provides
>> essentially the same level of security, according to my sources, while
>> hardware support seems to be coming to SHA-256 a lot sooner than to
>> SHA3-256.
>
> FWIW, and I know it is not worth much, as far as I can tell there is
> at least some security/math basis to prefer SHA3-256 to SHA-256.

Thanks for spelling this out. From my (very cursory) understanding of the math, what you are saying makes sense. I think there were some hints of this topic on-list before, but not made so explicit before.

Here's my summary of the discussion of other aspects of the choice of hash functions so far:

My understanding from asking cryptographers matches what Dscho said. One of the lessons of the history of hash functions is that some kinds of attempts to improve the security margin of a hash function do not help as much as expected once a function is broken.

In practice, what we are looking for is

- is the algorithm broken, or likely to be broken soon
- do the algorithm's guarantees match the application
- is the algorithm fast enough
- are high quality implementations widely available

On that first question, every well informed person I have asked has assured me that SHA-256, SHA-512, SHA-512/256, SHA-256x16, SHA3-256, K12, BLAKE2bp-256, etc are equally likely to be broken in the next 10 years. The main difference for the longevity question is that some of those algorithms have had more scrutiny than others, but all have had significant scrutiny. See [1] and the surrounding thread for more discussion on that.

On the second question, SHA-256 is vulnerable to length extension attacks, which means it would not be usable as a MAC directly (instead of using the HMAC construction). Fortunately Git doesn't use its hash function that way.

On the third question, SHA-256 is one of the slower ones, even with hardware accelaration, but it should be fast enough.

On the fourth question, SHA-256 shines. See [2]. That is where I had thought the conversation ended up.

For what it's worth, I'm pretty happy both with the level of scrutiny we've given to this question and SHA-256 as an answer. Luckily even if at the last minute we learn something that changes the choice of hash function, that would not significantly affect the transition plan, so we have a chance to learn more.

See also [3].

Thanks, Jonathan

[1] https://public-inbox.org/git/CAL9PXLzhPyE+geUdcLmd=pidT5P8eFEBbSgX_dS88knz2q_LSw@mail.gmail.com/#t
[2] https://public-inbox.org/git/xmqq37azy7ru.fsf@gitster.mtv.corp.google.com/
[3] https://www.imperialviolet.org/2017/05/31/skipsha3.html,
    https://news.ycombinator.com/item?id=14453622