git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).