Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

[Rich Freeman]

On Sat, Aug 15, 2015 at 7:24 AM, hasufell <hasufell@g.o> wrote:
>
> No one has proven that git is cryptographically insecure. Everyone
> claiming that probably refers to
> https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html and
> the fact that we don't sign blob objects.
>
> While that is something git upstream has to fix, all known SHA1
> "attacks" are NOT "preimage attacks". So the whole point is utterly and
> mathematically moot for us in practice. This is wasting our time.
>

I'd take a few issues with your wording, but not with your argument as
it applies to Gentoo.

Whether a collision attack or a preimage attack is necessary to make
something insecure depends on how the hash is being used.  In the case
of Gentoo the author is the signer, so a collision attack doesn't
really mean much.  If the signer wanted to sign something different,
they would just do it.  In another workflow where the where the signer
is somebody other than the author, then a collision attack might be
meaningful, even in the absence of a preimage attack.  That is, as the
author I can use a collision attack to generate two git trees with the
same hash.  One is a tree you would be willing to sign off on, and the
other is one that you would be unwilling to sign off on.  After
obtaining your signature I could keep your commit object and swap out
the tree resulting in a repo that has your signature but what you
signed off on is not what is in the repo.  You could see how in some
code-review scenarios that might be relevant (only if the submitted
tree is signed unmodified - any rebasing could break this, and even a
merge could break it[1]).  On the other hand, in the author-is-signer
workflow of Gentoo it isn't very relevant, since if I want to stick
something nasty in the tree I can just do it.

Overall, though, sha1's days are numbered.  I don't think that is a
reason to make an inconvenient change in our workflow just now.
However, it really is the sort of thing the git maintainers should be
thinking about and at least planning for.

This also brings up the issue of unstated assumptions made by
development teams.  They use a tool which has some cryptographic
weakness, based on the argument that the weakness is not a problem for
their intended use.  Then when somebody else comes along and uses the
application in a manner not originally intended or conceived of by the
authors, the weakness compromises the security of the application,
perhaps in a way the users aren't aware of.  Then when the problem is
exploited and publicized everybody gets to argue about whose fault it
is.

Footnotes:
1 - ...though if you could be reasonably sure that other commits being
rebased/merged wouldn't touch the part of the tree you're messing with
you could do a collision on a tree object below the root and not on
the root itself.  As long as no other commits before the merge mess
with the part of the tree you're playing games with you could swap out
just that part of the tree if you could do a collision attack and then
both the merge and your own commit will inherit the changes.

-- 
Rich