git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Lang <david.lang@digitalinsight.com>
To: Linus Torvalds <torvalds@osdl.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Krzysztof Halasa <khc@pm.waw.pl>, Jeff Garzik <jeff@garzik.org>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Starting to think about sha-256?
Date: Mon, 28 Aug 2006 10:27:29 -0700	[thread overview]
Message-ID: <656C30A1EFC89F6B2082D9B6@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0608271522390.27779@g5.osdl.org>

--On Sunday, August 27, 2006 03:35:20 PM -0700 Linus Torvalds 
<torvalds@osdl.org> wrote:
>
> On Mon, 28 Aug 2006, Johannes Schindelin wrote:
>> Even if the breakthrough really comes to full SHA-1, you still have to
>> add  _at least_ 20 bytes of gibberish. Which would be harder to spot,
>> but it  would be spotted.
>
> Yeah, I don't think this is at all critical, especially since git really
> on a security level doesn't _depend_ on the hashes being
> cryptographically  secure. As I explained early on (ie over a year ago,
> back when the whole  design of git was being discussed), the _security_
> of git actually depends  on not cryptographic hashes, but simply on
> everybody being able to secure  their own _private_ repository.
>
> So the only thing git really _requires_ is a hash that is _unique_ for
> the  developer (and there we are talking not of an _attacker_, but a
> benign  participant).
>
> That said, the cryptographic security of SHA-1 is obviously a real bonus.
> So I'd be disappointed if SHA-1 can be broken more easily (and I
> obviously  already argued against using MD5, exactly because generating
> duplicates of  that is fairly easy). But it's not "fundamentally
> required" in git per se.


>> This made me think about the use of hashes in git. Why do we need a hash
>> here (in no particular order):
>>
>> 1) integrity checking,
>> 2) fast lookup,
>> 3) identifying objects (related to (2)),
>> 4) trust.
>>
>> Except for (4), I do not see why SHA-1 -- even if broken -- should not
>> be  adequate. It is not like somebody found out that all JPGs tend to
>> have  similar hashes so that collisions are more likely.
>
> Correct. I'm pretty sure we had exactly this discussion around May 2005,
> but I'm too lazy to search ;)

just to double check.

if you already have a file A in git with hash X is there any condition 
where a remote file with hash X (but different contents) would overwrite 
the local version?

what would happen if you ended up with two packs that both contained a file 
with hash X but with different contents and then did a repack on them? 
(either packs from different sources, or packs downloaded through some 
mechanism other then the git protocol are two ways this could happen that I 
can think of)

David Lang

  reply	other threads:[~2006-08-28 17:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-27 17:56 Starting to think about sha-256? Jeff Garzik
2006-08-27 20:30 ` Krzysztof Halasa
     [not found]   ` <Pine.LNX.4.64.0608271343120.27779@g5.o sdl.org>
2006-08-27 20:46   ` Linus Torvalds
2006-08-27 21:14     ` Krzysztof Halasa
2006-08-27 22:02     ` Johannes Schindelin
2006-08-27 22:35       ` Linus Torvalds
2006-08-28 17:27         ` David Lang [this message]
2006-08-28 17:56           ` Linus Torvalds
2006-08-28 18:06             ` Linus Torvalds
2006-08-28 18:32             ` Jeff King
2006-08-28 18:46               ` Linus Torvalds
2006-08-28 19:00                 ` Jeff King
2006-08-28 20:12             ` Krzysztof Halasa
2006-08-28 20:20               ` Linus Torvalds
2006-08-28 21:12                 ` Krzysztof Halasa
2006-08-28 21:23                   ` Linus Torvalds
2006-08-28 23:09             ` Johannes Schindelin
2006-08-28 23:48               ` Linus Torvalds
2006-08-29  6:17 ` Florian Weimer
  -- strict thread matches above, loose matches on Subject: below --
2006-09-05  9:05 linux

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=656C30A1EFC89F6B2082D9B6@localhost \
    --to=david.lang@digitalinsight.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jeff@garzik.org \
    --cc=khc@pm.waw.pl \
    --cc=torvalds@osdl.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).