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

Re: SHA-256 transition

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Jun 25, 2022, 08:53 UTC
Message-ID
<YrbNIUnftj+Ooumo@tapette.crustytoothpaste.net>
In-Reply-To
<YrWXdNGZGN7gXL40@coredump.intra.peff.net>
On 2022-06-24 at 10:52:36, Jeff King wrote:
Show 17 quoted lines
> On Wed, Jun 22, 2022 at 12:29:59AM +0000, brian m. carlson wrote:
> 
> > > 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).

I did the same thing, except I just did a regular gc and not a custom repack, and I created both a SHA-1 and SHA-256 repo from the same original.

Show 12 quoted lines
> 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
Here are my results:

[sha256] time ~/checkouts/git/git index-pack --verify .git/objects/pack/pack-*.pack ~/checkouts/git/git index-pack --verify .git/objects/pack/pack-*.pack 2768.42s user 181.00s system 185% cpu 26:31.70 total

[sha1dc] time ~/checkouts/git/git index-pack --verify .git/objects/pack/pack-*.pack ~/checkouts/git/git index-pack --verify .git/objects/pack/pack-*.pack 3041.28s user 184.84s system 199% cpu 26:54.74 total

Note that in my case, I'm using an accelerated hardware-based SHA-256 implementation (Nettle, which I will send a patch for soon). This is a brand new ThinkPad X1 Carbon Gen 10 with an i7-1280P (with 20 "cores" of different sizes).

So this is about 9% faster in terms of total CPU usage on SHA-256 with that implementation. The wallclock time is less impressive here.

Of course, it might be slower in software, but considering that AMD has had SHA-NI for some time, newer Intel processors have it, and ARM also has SHA-2 acceleration instructions, it's likely it will be faster on most recent machines assuming it's compiled appropriately.

-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA
Previous: Ævar Arnfjörð BjarmasonNext: Eric W. Biederman
Message 17 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.