From: Tkil <tkil@scrye.com>
To: Paul Jackson <pj@sgi.com>
Cc: omb@bluewin.ch, david.lang@digitalinsight.com, mingo@elte.hu,
git@vger.kernel.org
Subject: Re: SHA1 hash safety
Date: Sat, 16 Apr 2005 22:43:42 -0600 [thread overview]
Message-ID: <gacny8135.fsf@brand.scrye.com> (raw)
In-Reply-To: <20050416210934.11a27387.pj@sgi.com> (Paul Jackson's message of "Sat, 16 Apr 2005 21:09:34 -0700")
>>>>> "Tkil" == Tkil <tkil@scrye.com> writes:
Tkil> but the chance of any collision at all wigs me out.
>>>>> "Paul" == Paul Jackson <pj@sgi.com> writes:
Paul> Guess you're just going to get wigged out then.
Wig wig. :)
I didn't mean "wigs me out to the point I won't use it" but more of
"wigs me out so that I'm curious whether there are backup schemes
worth considering".
In particular, the comparisons between hash collisions and hardware
failure seem contrived -- if I have bad RAM, or a bad block on my HD,
I can recover it from known good sources. But if the actual known
good source is structured in such a way that a particular set of data
cannot be represented, that bothers me.
In this case, the fact that it has to be the same length, same SHA-1,
correct C, and functionally similar C at that, makes for a comforting
cushion. Further, git wouldn't be the only representation; there
would be periodic tarballs, different trees, etc.
On the other paw, if "effectively random" MS Word docs gave true MD5
collisions (when we have a proper MD5 hash computed over the entire
document) in a "mere" 1e7 space, that is interesting/scary.
(I was also trying to add a few factoids to the MSW comment, as their
structure could lead to collisions if (say) only the first 512 bytes
were considered -- it's possible that nothing but size and date might
change in that, and /those/ I can see colliding in 1e7 documents.)
Finally, I apologize for taking your time. I'm just watching this
from the sidelines, and the questions above are just intellectual
curiosity. :-/
(The only other thread I'm really following is people trying to chunk
files in a way that would increase storage efficiency; reading the
Venti paper, I was wondering how efficient it would be if a one-byte
addition at the top of the file would generate all-new blocks, while
the rsync-ish protocol seems to offer substantial relief. But if the
"interesting history" fits in 10USD worth of HD, that might be enough.
Babble.)
Thanks,
t.
next prev parent reply other threads:[~2005-04-17 4:40 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-16 12:24 SHA1 hash safety David Lang
2005-04-16 12:31 ` Ingo Molnar
2005-04-16 12:48 ` David Lang
2005-04-16 13:29 ` Brian O'Mahoney
2005-04-16 14:58 ` C. Scott Ananian
2005-04-16 15:11 ` Petr Baudis
2005-04-16 15:36 ` C. Scott Ananian
2005-04-16 22:56 ` David Lang
2005-04-16 23:11 ` Paul Jackson
2005-04-16 23:18 ` Martin Mares
2005-04-17 4:38 ` David A. Wheeler
2005-04-18 0:09 ` Theodore Ts'o
2005-04-16 15:49 ` ross
2005-04-17 6:35 ` Horst von Brand
2005-04-18 2:07 ` Brian O'Mahoney
2005-04-18 16:50 ` C. Scott Ananian
2005-04-16 19:16 ` Paul Jackson
2005-04-16 21:35 ` Brian O'Mahoney
2005-04-18 7:43 ` Andy Isaacson
2005-04-18 17:04 ` C. Scott Ananian
2005-04-19 22:30 ` David Meybohm
2005-04-19 22:48 ` C. Scott Ananian
2005-04-20 18:56 ` David Meybohm
2005-04-16 22:46 ` David Lang
2005-04-16 23:14 ` Paul Jackson
2005-04-16 22:33 ` David Lang
2005-04-17 3:23 ` Tkil
2005-04-17 4:09 ` Paul Jackson
2005-04-17 4:43 ` Tkil [this message]
2005-04-17 5:09 ` Paul Jackson
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=gacny8135.fsf@brand.scrye.com \
--to=tkil@scrye.com \
--cc=david.lang@digitalinsight.com \
--cc=git@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=omb@bluewin.ch \
--cc=pj@sgi.com \
/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.