From: "Brian O'Mahoney" <omb@khandalf.com>
To: David Lang <david.lang@digitalinsight.com>
Cc: Ingo Molnar <mingo@elte.hu>, git@vger.kernel.org
Subject: Re: SHA1 hash safety
Date: Sat, 16 Apr 2005 15:29:14 +0200 [thread overview]
Message-ID: <4261132A.3090907@khandalf.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0504160542190.21837@qynat.qvtvafvgr.pbz>
Three points:
(1) I _have_ seen real-life collisions with MD5, in the context of
Document management systems containing ~10^6 ms-WORD documents.
(2) The HMAC (ethernet-harware-address) of any interface _should_
help to make a unique Id.
(3) While I havn't looked at the details of the plumbing, this is
the time to make sure we can, easily, drop in SHA-160, SHA-256
(or whatever comes from NIST) when needed.
David Lang wrote:
> On Sat, 16 Apr 2005, Ingo Molnar wrote:
>
>> * David Lang <david.lang@digitalinsight.com> wrote:
>>
>>> this issue was raised a few days ago in the context of someone
>>> tampering with the files and it was decided that the extra checks were
>>> good enough to prevent this (at least for now), but what about
>>> accidental collisions?
>>>
>>> if I am understanding things right the objects get saved in the
>>> filesystem in filenames that are the SHA1 hash. of two legitimate
>>> files have the same hash I don't see any way for both of them to
>>> exist.
>>>
>>> yes the risk of any two files having the same has is low, but in the
>>> earlier thread someone chimed in and said that they had two files on
>>> their system that had the same hash..
>>
>>
>> you can add -DCOLLISION_CHECK to Makefile:CFLAGS to turn on collision
>> checking (disabled currently). If there indeed exist two files that have
>> different content but the same hash, could someone send those two files?
>
>
> remember that the flap over SHA1 being 'broken' a couple weeks ago was
> not from researchers finding multiple files with the same hash, but
> finding that it was more likly then expected that files would have the
> same hash.
>
> there was qa discussion on LKML within the last year about useing MD5
> hashes for identifying unique filesystem blocks (with the idea of being
> able to merge identical blocks) and in that discussion it was pointed
> out that collisions are a known real-life issue.
>
> so if collision detection is turned on in git, does that make it error
> out if it runs into a second file with the same hash, or does it do
> something else?
>
> David Lang
>
--
Brian
next prev parent reply other threads:[~2005-04-16 13:26 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 [this message]
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
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=4261132A.3090907@khandalf.com \
--to=omb@khandalf.com \
--cc=david.lang@digitalinsight.com \
--cc=git@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=omb@bluewin.ch \
/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).