From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Jeff King <peff@peff.net>
Cc: "Æ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:34:41 +0200 [thread overview]
Message-ID: <507D4651.6080207@lsrfire.ath.cx> (raw)
In-Reply-To: <20121015183438.GB31658@sigill.intra.peff.net>
Am 15.10.2012 20:34, schrieb Jeff King:
> On Mon, Oct 15, 2012 at 07:47:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto <gitter.spiros@gmail.com> wrote:
>>> Very clear analysis. Well written. Perhaps is it the time to update
>>> http://git-scm.com/book/ch6-1.html (A SHORT NOTE ABOUT SHA-1) ?
>>>
>>> Hope useful
>>>
>>> http://www.schneier.com/crypto-gram-1210.html
>>
>> This would be concerning if the Git security model would break down if
>> someone found a SHA1 collision, but it really wouldn't.
>>
>> It's one thing to find *a* collision, it's quite another to:
>>
>> 1. Find a collision for the sha1 of harmless.c which I know you use,
>> and replace it with evil.c.
>>
>> 2. Somehow make evil.c compile so that it actually does something
>> useful and nefarious, and doesn't just make the C compiler puke.
>>
>> If finding one arbitrary collision costs $43K in 2021 dollars
>> getting past this point is going to take quite a large multiple of
>> $43K.
>
> There are easier attacks than that if you can hide arbitrary bytes
> inside a file. It's hard with C source code. The common one in hash
> collision detection circles is to put invisible cruft into binary
> document formats like PDF or Postscript. Git blobs themselves do not
> have such an invisible place to put it, but you might be storing a
> format that does.
>
> But worse, git _commits_ have such an invisible portion. We calculate
> the sha1 over the full commit, but we tend to show only the portion up
> to the first NUL byte. I used that horrible trick in my "choose your own
> sha1 prefix" patch. However, we could mitigate that by checking for
> embedded NULs in git-fsck.
FWIW, I couldn't measure a performance difference for git log with and
without the following patch, which catches commits created with your
hash collision trick, but might be too strict:
diff --git a/commit.c b/commit.c
index 213bc98..4cd1e83 100644
--- a/commit.c
+++ b/commit.c
@@ -262,6 +262,12 @@ int parse_commit_buffer(struct commit *item, const void *buffer, unsigned long s
if (item->object.parsed)
return 0;
item->object.parsed = 1;
+
+ if (memchr(buffer, '\0', size)) {
+ return error("bogus commit contains a NUL character: %s",
+ sha1_to_hex(item->object.sha1));
+ }
+
tail += size;
if (tail <= bufptr + 46 || memcmp(bufptr, "tree ", 5) || bufptr[45] != '\n')
return error("bogus commit object %s", sha1_to_hex(item->object.sha1));
next prev parent reply other threads:[~2012-10-16 11:34 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 [this message]
2012-10-16 17:32 ` Jeff King
2012-10-16 17:58 ` Theodore Ts'o
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=507D4651.6080207@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitter.spiros@gmail.com \
--cc=peff@peff.net \
--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).