git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Starting to think about sha-256?

From
DLDavid Lang <david.lang@digitalinsight.com>
Date
Aug 28, 2006, 17:27 UTC
Message-ID
<656C30A1EFC89F6B2082D9B6@localhost>
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:

Show 22 quoted lines
>
> 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.
Show 14 quoted lines
>> 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
Previous: Linus TorvaldsNext: Linus Torvalds
Message 7 of 19 in “Starting to think about sha-256?”
  1. Jeff GarzikAug 27, 2006
  2. Krzysztof HalasaAug 27, 2006
  3. Linus TorvaldsAug 27, 2006
  4. Krzysztof HalasaAug 27, 2006
  5. Johannes SchindelinAug 27, 2006
  6. Linus TorvaldsAug 27, 2006
  7. David LangAug 28, 2006
  8. Linus TorvaldsAug 28, 2006
  9. Linus TorvaldsAug 28, 2006
  10. Jeff KingAug 28, 2006
  11. Linus TorvaldsAug 28, 2006
  12. Jeff KingAug 28, 2006
  13. Krzysztof HalasaAug 28, 2006
  14. Linus TorvaldsAug 28, 2006
  15. Krzysztof HalasaAug 28, 2006
  16. Linus TorvaldsAug 28, 2006
  17. Johannes SchindelinAug 28, 2006
  18. Linus TorvaldsAug 28, 2006
  19. Florian WeimerAug 29, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.