All of lore.kernel.org
 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 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.