From: Paolo Bonzini <bonzini@gnu.org>
To: git@vger.kernel.org
Cc: sverre@rabbelier.nl, Russ Dill <russ.dill@gmail.com>,
Henrik Austad <henrikau@orakel.ntnu.no>,
Daniel Barkalow <barkalow@iabervon.org>,
git@vger.kernel.org
Subject: Re: About git and the use of SHA-1
Date: Tue, 29 Apr 2008 15:05:40 +0200 [thread overview]
Message-ID: <48171D24.9000104@gnu.org> (raw)
In-Reply-To: <48171442.4050707@op5.se>
> I can think of one way to make git a lot more resilient to hash
> collisions, regardless of which hash is used, namely: Add the length
> of the hashed object to the hash.
Not really, because most attacks are about collisions, not second
preimages. They produce two 64-byte blocks (hence, same length) with
the same hash value.
As such, they allow to change a blob that *the attacker* injected in the
repository. The way the more "spectacular" attacks are devised requires
a "language" with conditional expressions -- for documents, for example,
Postscript is used. If you prepare a postscript file whose code is
if (AAAA == BBBB)
typeset document 1
else
typeset document 2
where AAAA and BBBB are collisions, and you change it to "if (BBBB ==
BBBB) the hash will be the same, but the outcome will be document 1
instead of document 2.
The fact that this requires having the two "behaviors" in the blob is
not a big deal for source code, going in the wrong branch of an "if" can
be an attack. On the other hand, it makes adding the length useless for
collision attacks. True, it wouldn't be useless for second preimage
attacks, but SHA-1 is still secure with respect to those.
Paolo
next prev parent reply other threads:[~2008-04-29 13:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-28 16:29 About git and the use of SHA-1 Henrik Austad
2008-04-28 19:34 ` Daniel Barkalow
2008-04-28 21:29 ` Henrik Austad
2008-04-28 22:15 ` Daniel Barkalow
2008-04-29 6:38 ` Andreas Ericsson
2008-04-29 7:09 ` Russ Dill
2008-04-29 7:21 ` Andreas Ericsson
2008-04-29 11:05 ` Sverre Rabbelier
2008-04-29 12:27 ` Andreas Ericsson
2008-04-29 13:05 ` Paolo Bonzini [this message]
2008-04-29 14:37 ` Andreas Ericsson
2008-04-29 14:52 ` Paolo Bonzini
2008-04-29 16:24 ` Russ Dill
2008-04-29 12:46 ` Jurko Gospodnetić
2008-04-29 16:21 ` Russ Dill
2008-04-29 15:34 ` Geoffrey Irving
2008-04-29 16:27 ` Daniel Barkalow
2008-04-29 12:41 ` Dmitry Potapov
2008-04-29 14:41 ` Andreas Ericsson
2008-04-29 15:42 ` Nicolas Pitre
2008-04-29 15:59 ` Geoffrey Irving
2008-04-29 16:39 ` Nicolas Pitre
2008-04-29 17:48 ` Geoffrey Irving
2008-04-29 17:55 ` Nicolas Pitre
2008-04-29 18:02 ` Geoffrey Irving
2008-04-29 18:41 ` Daniel Barkalow
2008-04-29 20:31 ` Geoffrey Irving
2008-04-29 20:50 ` Fredrik Skolmli
2008-04-29 21:39 ` Geoffrey Irving
2008-04-29 21:52 ` Fredrik Skolmli
2008-04-30 2:58 ` Martin Langhoff
2008-04-30 5:18 ` Geoffrey Irving
2008-04-30 5:47 ` David Brown
2008-04-30 5:56 ` Martin Langhoff
2008-04-29 18:17 ` Matthieu Moy
2008-04-29 18:23 ` Fredrik Skolmli
2008-04-29 15:02 ` Tom Widmer
2008-04-29 17:08 ` Tom Widmer
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=48171D24.9000104@gnu.org \
--to=bonzini@gnu.org \
--cc=barkalow@iabervon.org \
--cc=git@vger.kernel.org \
--cc=henrikau@orakel.ntnu.no \
--cc=russ.dill@gmail.com \
--cc=sverre@rabbelier.nl \
/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).