git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).