All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.