Re: Git and SHA-1 security (again)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Duy,

On Mon, 18 Jul 2016, Duy Nguyen wrote:

> On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 18 Jul 2016, Herczeg Zsolt wrote:
> >
> >> >> I think converting is a much better option. Use a single-hash
> >> >> storage, and convert everything to that on import/clone/pull.
> >> >
> >> > That ignores two very important issues that I already had mentioned:
> >>
> >> That's not true. If you double-check the next part of my message, you I
> >> just showed that an automatic two-way mapping could solve these
> >> problems! (I even give briefs explanation how to handle referencing and
> >> signature verification in those cases.)
> >>
> >> My point is not to throw out old hashes and break signatures. My point
> >> is to convert the data storage, and use mapping to resolve problems
> >> with those old hashes and signatures.
> >
> > If you convert the data storage, then the SHA-1s listed in the commit
> > objects will have to be rewritten, and then the GPG signature will not
> > match anymore.
> 
> But we can recreate SHA-1 from the same content and verify GPG, right?
> I know it's super expensive, but it feels safer to not carry SHA-1
> around when it's not secure anymore (I recall something about
> exploiting the weakest link when you have both sha1 and sha256 in the
> object content). Rehashing would be done locally and is better
> controlled.

You could. But how would you determine whether to recreate the commit
object from a SHA-1-ified version of the commit buffer? Fall back if the
original did not match the signature? That would pose at least these two
problems:

1. The point of a signature is trust. If all of a sudden the signature
does not match what is supposedly signed, that trust is broken.

2. The point of going to a stronger hash is to increase the trust. If
any developer could decide to sign the SHA-1-ified version of any future
commit, and Git validating it, it would be even worse than not switching
to a new hash: it would leave us open to collision attacks *and* pretend
that we prevented such attacks.

The more I think about it, the more I am convinced that we have no choice
but allow mixed hashes (i.e. both 160-bit SHA-1 and 256-bit new hash,
whatever we settle on). Otherwise there would be no reliable and
trustworthy upgrade path.

But maybe there is a clever strategy I failed to think of?

Ciao,
Dscho