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
next prev parent 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).