From: Theodore Ts'o <tytso@mit.edu>
To: Jeff King <peff@peff.net>
Cc: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Elia Pinto" <gitter.spiros@gmail.com>,
git@vger.kernel.org, "Scott Chacon" <schacon@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)
Date: Tue, 16 Oct 2012 13:58:06 -0400 [thread overview]
Message-ID: <20121016175806.GB26650@thunk.org> (raw)
In-Reply-To: <20121016173254.GD27243@sigill.intra.peff.net>
I seem to recall that there was at least some discussion at one point
about adding some extra fields to the commit object in a backwards
compatible way by adding it after the trailing NUL. We didn't end up
doing it, but I could see it being a useful thing nonetheless (for
example, we could potentially put the backup SHA-2/SHA-3 pointer there).
What if we explicitly allow a length plus SHA-2/3 hash of the commit
plus the fields after the SHA-2/3 hash as an extension? This would
allow a secure way of adding an extension, including perhaps adding
backup SHA-2/3 parent pointers, which is something that would be
useful to do from a security perspective if we really are worried
about a catastrophic hash failure.
The one reason why we *might* want to use SHA-3, BTW, is that it is a
radically different design from SHA-1 and SHA-2. And if there is a
crypto hash failure which is bad enough that the security of git would
be affected, there's a chance that the same attack could significantly
affect SHA-2 as well. The fact that SHA-3 is fundamentally different
from a cryptographic design perspective means that an attack that
impacts SHA-1/SHA-2 will not likely impact SHA-3, and vice versa.
- Ted
next prev parent reply other threads:[~2012-10-16 17:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-15 16:42 When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier) Elia Pinto
2012-10-15 17:47 ` Ævar Arnfjörð Bjarmason
2012-10-15 18:09 ` Elia Pinto
2012-10-15 18:34 ` Jeff King
2012-10-15 19:09 ` Elia Pinto
2012-10-15 19:14 ` Jeff King
2012-10-16 11:34 ` René Scharfe
2012-10-16 17:32 ` Jeff King
2012-10-16 17:58 ` Theodore Ts'o [this message]
2012-10-16 18:27 ` Jeff King
2012-10-16 18:32 ` david
2012-10-16 18:54 ` Jeff King
2012-10-16 20:09 ` Junio C Hamano
2012-10-17 8:05 ` Peter Todd
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=20121016175806.GB26650@thunk.org \
--to=tytso@mit.edu \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitter.spiros@gmail.com \
--cc=peff@peff.net \
--cc=rene.scharfe@lsrfire.ath.cx \
--cc=schacon@gmail.com \
--cc=torvalds@linux-foundation.org \
/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).