Re: Git and SHA-1 security (again)

Hi Duy,

On Mon, 18 Jul 2016, Duy Nguyen wrote:

On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin
[off-list ref] wrote:

quoted

On Mon, 18 Jul 2016, Herczeg Zsolt wrote:

quoted

quoted

quoted

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