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

Re: SHA-256 transition

From
Jeff King <peff@peff.net>
Date
Jun 24, 2022, 10:52 UTC
Message-ID
<YrWXdNGZGN7gXL40@coredump.intra.peff.net>
In-Reply-To
<YrI9dvfoc5NYgVDq@tapette.crustytoothpaste.net>
On Wed, Jun 22, 2022 at 12:29:59AM +0000, brian m. carlson wrote:
Show 10 quoted lines
> > We've since migrated our default hash function from SHA-1 to SHA-1DC
> > (except on vanilla OSX, see [2]). It's a variant SHA-1 that detects the
> > SHAttered attack implemented by the same researchers. I'm not aware of a
> > current viable SHA-1 collision against the variant of SHA-1 that we
> > actually use these days.
> 
> That's true, but that still doesn't let you store the data.  There is
> some data that you can't store in a SHA-1 repository, and SHA-1DC is
> extremely slow.  Using SHA-256 can make things like indexing packs
> substantially faster.

I'm curious if you have numbers on this. I naively converted linux.git to sha256 by doing "fast-export | fast-import" (the latter in a sha256 repo, of course, and then both repacked with "-f --window=250" to get reasonable apples-to-apples packs).

Running "index-pack --verify" on the result takes about the same time (this is on an 8-core system, hence the real/user differences):

  [sha1dc]
  real	2m43.754s
  user	10m52.452s
  sys	0m36.745s
  [sha256]
  real	2m41.884s
  user	12m23.344s
  sys	0m35.222s

The sha256 repo actually has about 10% fewer objects (I didn't investigate, but this is perhaps due to cutting out tags and a few other things to convince fast-export to finish running). I'm not sure about the extra user time (multicore timings here are funny because of frequency scaling, so I think the "real" line is more interesting). So sha256 actually comes out a bit worse here. On the other hand, this is just using our blk_SHA256 implementation. There may be faster alternatives (including ones with hardware support).

I wouldn't be at all surprised if the difference isn't substantial in the long run, though. The repo is on the order of 100GB of object data. That's a lot to hash, but it's also just a lot to deal with at all (zlib inflating, applying deltas, etc).

Anyway, this is a pretty rough cut at an experiment. I was mostly curious if you had done something more advanced, and/or gotten different results.

-Peff
Previous: Jonathan CorbetNext: Ævar Arnfjörð Bjarmason
Message 15 of 21 in “SHA-256 transition”
  1. Stephen SmithJun 20, 2022
  2. rsbecker@nexbridge.comJun 20, 2022
  3. Ævar Arnfjörð BjarmasonJun 21, 2022
  4. rsbecker@nexbridge.comJun 21, 2022
  5. Ævar Arnfjörð BjarmasonJun 21, 2022
  6. brian m. carlsonJun 22, 2022
  7. Stephen SmithJun 23, 2022
  8. brian m. carlsonJun 23, 2022
  9. Junio C HamanoJun 23, 2022
  10. Ævar Arnfjörð BjarmasonJun 23, 2022
  11. Kyle MeyerJun 24, 2022
  12. Stephen SmithJun 24, 2022
  13. Ævar Arnfjörð BjarmasonJun 24, 2022
  14. Jonathan CorbetJun 24, 2022
  15. Jeff KingJun 24, 2022
  16. Ævar Arnfjörð BjarmasonJun 24, 2022
  17. brian m. carlsonJun 25, 2022
  18. Plan for SHA-256 repos to support SHA-1?Eric W. Biederman, Jun 26, 2022
  19. Junio C HamanoJun 26, 2022
  20. brian m. carlsonJun 26, 2022
  21. Jeff KingJul 1, 2022

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.