Re: Hash algorithm analysis

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jul 23, 2018, 18:35 UTC
Message-ID: <20180723183523.GB9285@aiede.svl.corp.google.com>
In-Reply-To: <CANgJU+X39NoEoMyLu+FX38=x19LrRqatz_dUpUAc+WFV+Uw+=A@mail.gmail.com>

Hi Yves,

demerphq wrote:

> On Sun, 22 Jul 2018 at 01:59, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:

>> I will admit that I don't love making this decision by myself, because
>> right now, whatever I pick, somebody is going to be unhappy.

[...]

Show 5 quoted lines

> I do not envy you this decision.
>
> Personally I would aim towards pushing this decision out to the git
> user base and facilitating things so we can choose whatever hash
> function (and config) we wish, including ones not invented yet.

There are two separate pieces to this.

One is configurability at compile time. So far that has definitely been a goal, because we want to be ready to start the transition to another hash, and quickly, as soon as the new hash is discovered to be weak. This also means that people can experiment with new hashes and in a controlled environment (where the users can afford to build from source), some users might prefer some bespoke hash for reasons only known to them. ;-)

Another piece is configurability at run time. This is a harder sell because it has some negative effects in the ecosystem:

 - performance impact from users having to maintain a translation table
   between the different hash functions in use

 - security impact, in the form of downgrade attacks

 - dependency bloat, from Git having to be able to compute all hash
   functions permitted in that run-time configuration

The security impact can be mitigated by keeping the list of supported hashes small (i.e. two or three instead of 10ish). Each additional hash function is a potential liability (just as in SSL), so they have to earn their keep.

The performance impact is unavoidable if we encourage Git servers to pick their favorite hash function instead of making a decision in the project. This can in turn affect security, since it would increase the switching cost away from SHA-1, with the likely effect being that most users stay on SHA-1. I don't want to go there.

So I would say, support for arbitrary hash functions at compile time and in file formats is important and I encourage you to hold us to that (when reviewing patches, etc). But in the standard Git build configuration that most people run, I believe it is best to support only SHA-1 + our chosen replacement hash.

Thanks, Jonathan