From: Jeff King <peff@peff.net>
To: Stefan Beller <sbeller@google.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Migrating away from SHA-1?
Date: Tue, 12 Apr 2016 19:15:19 -0400 [thread overview]
Message-ID: <20160412231518.GA2210@sigill.intra.peff.net> (raw)
In-Reply-To: <CAGZ79kaUN0G7i0GNZgWU7ZzJvWY=k=Rc6tqWvJsTu8gcRhP5bA@mail.gmail.com>
On Tue, Apr 12, 2016 at 04:00:18PM -0700, Stefan Beller wrote:
> On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > OK, I'm going to open this can of worms...
> >
> > At what point do we migrate from SHA-1? At this point the cryptoanalysis of
> > SHA-1 is most likely a matter of time.
>
> And I thought the cryptographic properties of SHA1 did not matter for
> Gits use case.
> We could employ broken md5 or such as well.
> ( see http://stackoverflow.com/questions/28792784/why-does-git-use-a-cryptographic-hash-function
> )
> That is because security goes on top via gpg signing of tags/commits.
>
> I am not sure if anyone came up with
> a counter argument to Linus reasoning there?
I have never understood that reasoning at all, nor why it is so often
repeated.
The GPG signature is over a single object, that mentions other objects
by their sha1 ids. But users don't care that v1.0 is securely mapped to
tree 1234abcd. They care which files are in 1234abcd, and if sha1 is
broken, it means you can't credibly verify the content down to the blob
level.
There's some additional protection in that git generally prefers objects
it already has to new ones. So it's hard to reliably distribute your
evil colliding object, depending on where people might have fetched
from first. But:
1. I know there's at least once race[1] where a colliding object can
still enter the repository. There may be more that have either
existed all along, or that have grown over the years. I don't think
this is something we've paid attention to and tested.
2. That helps some people, I guess, but it's little consolation to
somebody who runs "git clone" followed by verifying the tag.
-Peff
[1] The race I am thinking of is that for performance reasons, we don't
re-scan the pack directory when index-pack checks has_sha1_file()
on an incoming object and it comes up negative. So if somebody else
is repacking, we might skip the collision check in such a case. At
least that race is not under control of an attacker, though.
next prev parent reply other threads:[~2016-04-12 23:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-12 22:38 Migrating away from SHA-1? H. Peter Anvin
2016-04-12 23:00 ` Stefan Beller
2016-04-12 23:06 ` H. Peter Anvin
2016-04-12 23:15 ` Jeff King [this message]
2016-04-12 23:15 ` David Turner
2016-04-12 23:44 ` Jeff King
2016-04-14 1:53 ` Theodore Ts'o
2016-04-14 16:47 ` Joey Hess
2016-04-14 17:23 ` David Turner
2016-04-14 17:28 ` H. Peter Anvin
2016-04-14 22:40 ` Theodore Ts'o
2016-04-15 2:13 ` Jeff King
2016-04-15 2:18 ` Junio C Hamano
2016-04-15 2:22 ` Jeff King
2016-04-12 23:42 ` Jeff King
2016-04-13 1:03 ` Junio C Hamano
2016-04-13 1:36 ` Jeff King
2016-04-13 1:38 ` H. Peter Anvin
2016-04-13 1:51 ` Duy Nguyen
2016-04-13 1:58 ` H. Peter Anvin
2016-04-15 1:50 ` brian m. carlson
-- strict thread matches above, loose matches on Subject: below --
2016-06-18 2:10 Leo Gaspard
2016-06-18 3:30 ` Eric Wong
2016-06-24 18:17 ` brian m. carlson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160412231518.GA2210@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=hpa@zytor.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).