From: Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> To: "brian m. carlson" <email@example.com> Cc: Adam Langley <firstname.lastname@example.org>, Johannes Schindelin <Johannes.Schindelin@gmx.de>, Jeff King <email@example.com>, Mike Hommey <firstname.lastname@example.org>, Brandon Williams <email@example.com>, Linus Torvalds <firstname.lastname@example.org>, Jonathan Nieder <email@example.com>, Git Mailing List <firstname.lastname@example.org>, Stefan Beller <email@example.com>, Jonathan Tan <firstname.lastname@example.org>, Junio Hamano <email@example.com> Subject: Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan Date: Fri, 16 Jun 2017 08:25:50 +0200 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> On Fri, Jun 16 2017, brian m. carlson jotted: > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote: >> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson >> <firstname.lastname@example.org> wrote: >> > SHA-256 acceleration exists for some existing Intel platforms already. >> > However, they're not practically present on anything but servers at the >> > moment, and so I don't think the acceleration of SHA-256 is a >> > something we should consider. >> >> Whatever next-gen hash Git ends up with is going to be in use for >> decades, so what hardware acceleration exists in consumer products >> right now is practically irrelevant, but what acceleration is likely >> to exist for the lifetime of the hash existing *is* relevant. > > The life of MD5 was about 23 years (introduction to first document > collision). SHA-1 had about 22. Decades, yes, but just barely. SHA-2 > was introduced in 2001, and by the same estimate, we're a little over > halfway through its life. I'm talking about the lifetime of SHA-1 or $newhash's use in Git. As our continued use of SHA-1 demonstrates the window of practical hash function use extends well beyond the window from introduction to published breakage. It's also telling that SHA-1, which any cryptographer would have waived you off from since around 2011, is just getting widely deployed HW acceleration now in 2017. The practical use of hash functions far exceeds their recommended use in new projects. >> So I don't follow the argument that we shouldn't weigh future HW >> acceleration highly just because you can't easily buy a laptop today >> with these features. >> >> Aside from that I think you've got this backwards, it's AMD that's >> adding SHA acceleration to their high-end Ryzen chips but Intel is >> starting at the lower end this year with Goldmont which'll be in >> lower-end consumer devices. If you read the github issue I linked >> to upthread you can see that the cryptopp devs already tested their >> SHA accelerated code on a consumer Celeron recently. >> >> I don't think Intel has announced the SHA extensions for future Xeon >> releases, but it seems given that they're going to have it there as >> well. Have there every been x86 extensions that aren't eventually >> portable across the entire line, or that they've ended up removing >> from x86 once introduced? >> >> In any case, I think by the time we're ready to follow-up the current >> hash refactoring efforts with actually changing the hash >> implementation many of us are likely to have laptops with these >> extensions, making this easy to test. > > I think you underestimate the life of hardware and software. I have > servers running KVM development instances that have been running since > at least 2012. Those machines are not scheduled for replacement anytime > soon. > > Whatever we deploy within the next year is going to run on existing > hardware for probably a decade, whether we want it to or not. Most of > those machines don't have acceleration. To clarify, I'm not dismissing the need to consider existing hardware without these acceleration functions or future processors without them. I don't think that makes any sense, we need to keep those in mind. I was replying to a bit in your comment where you (it seems to me) were making the claim that we shouldn't consider the HW acceleration of certain hash functions either. Clearly both need to be considered. > Furthermore, you need a reasonably modern crypto library to get hardware > acceleration. OpenSSL has only recently gained support for it. RHEL 7 > does not currently support it, and probably never will. That OS is > going to be around for the next 6 years. > > If we're optimizing for performance, I don't want to optimize for the > latest, greatest machines. Those machines are going to outperform > everything else either way. I'd rather optimize for something which > performs well on the whole everywhere. There are a lot of developers > who have older machines, for cost reasons or otherwise. We have real data showing that the intersection between people who care about the hash slowing down and those who can't afford the latest hardware is pretty much nil. I.e. in 2.13.0 SHA-1 got slower, and pretty much nobody noticed or cared except Johannes Schindelin, myself & Christian Couder. This is because in practice hashing only becomes a bottleneck on huge monorepos that need to e.g. re-hash the contents of a huge index. > Here are some stats (cycles/byte for long messages): > > SHA-256 BLAKE2b > Ryzen 1.89 3.06 > Knight's Landing 19.00 5.65 > Cortex-A72 1.99 5.48 > Cortex-A57 11.81 5.47 > Cortex-A7 28.19 15.16 > > In other words, BLAKE2b performs well uniformly across a wide variety of > architectures even without acceleration. I'd rather tell people that > upgrading to a new hash algorithm is a performance win either way, not > just if they have the latest hardware. Yup, all of those need to be considered, although given my comment above about big repos a 40% improvement on Ryzen (a processor likely to be used for big repos) stands out, where are those numbers from, and is that with or without HW accel for SHA-256 on Ryzen?
next prev parent reply index Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-04 1:12 Jonathan Nieder 2017-03-05 2:35 ` Linus Torvalds 2017-03-06 0:26 ` brian m. carlson 2017-03-06 18:24 ` Brandon Williams 2017-06-15 10:30 ` Which hash function to use, was " Johannes Schindelin 2017-06-15 11:05 ` Mike Hommey 2017-06-15 13:01 ` Jeff King 2017-06-15 16:30 ` Ævar Arnfjörð Bjarmason 2017-06-15 19:34 ` Johannes Schindelin 2017-06-15 21:59 ` Adam Langley 2017-06-15 22:41 ` brian m. carlson 2017-06-15 23:36 ` Ævar Arnfjörð Bjarmason 2017-06-16 0:17 ` brian m. carlson 2017-06-16 6:25 ` Ævar Arnfjörð Bjarmason [this message] 2017-06-16 13:24 ` Johannes Schindelin 2017-06-16 17:38 ` Adam Langley 2017-06-16 20:52 ` Junio C Hamano 2017-06-16 21:12 ` Junio C Hamano 2017-06-16 21:24 ` Jonathan Nieder 2017-06-16 21:39 ` Ævar Arnfjörð Bjarmason 2017-06-16 20:42 ` Jeff King 2017-06-19 9:26 ` Johannes Schindelin 2017-06-15 21:10 ` Mike Hommey 2017-06-16 4:30 ` Jeff King 2017-06-15 17:36 ` Brandon Williams 2017-06-15 19:20 ` Junio C Hamano 2017-06-15 19:13 ` Jonathan Nieder 2017-03-07 0:17 ` RFC v3: " Jonathan Nieder 2017-03-09 19:14 ` Shawn Pearce 2017-03-09 20:24 ` Jonathan Nieder 2017-03-10 19:38 ` Jeff King 2017-03-10 19:55 ` Jonathan Nieder 2017-09-28 4:43 ` [PATCH v4] technical doc: add a design doc for hash function transition Jonathan Nieder 2017-09-29 6:06 ` Junio C Hamano 2017-09-29 8:09 ` Junio C Hamano 2017-09-29 17:34 ` Jonathan Nieder 2017-10-02 8:25 ` Junio C Hamano 2017-10-02 19:41 ` Jason Cooper 2017-10-02 9:02 ` Junio C Hamano 2017-10-02 19:23 ` Jason Cooper 2017-10-03 5:40 ` Junio C Hamano 2017-10-03 13:08 ` Jason Cooper 2017-10-04 1:44 ` Junio C Hamano 2017-09-06 6:28 ` RFC v3: Another proposed hash function transition plan Junio C Hamano 2017-09-08 2:40 ` Junio C Hamano 2017-09-08 3:34 ` Jeff King 2017-09-11 18:59 ` Brandon Williams 2017-09-13 12:05 ` Johannes Schindelin 2017-09-13 13:43 ` demerphq 2017-09-13 22:51 ` Jonathan Nieder 2017-09-14 18:26 ` Johannes Schindelin 2017-09-14 18:40 ` Jonathan Nieder 2017-09-14 22:09 ` Johannes Schindelin 2017-09-13 23:30 ` Linus Torvalds 2017-09-14 18:45 ` Johannes Schindelin 2017-09-18 12:17 ` Gilles Van Assche 2017-09-18 22:16 ` Johannes Schindelin 2017-09-19 16:45 ` Gilles Van Assche 2017-09-29 13:17 ` Johannes Schindelin 2017-09-29 14:54 ` Joan Daemen 2017-09-29 22:33 ` Johannes Schindelin 2017-09-30 22:02 ` Joan Daemen 2017-10-02 14:26 ` Johannes Schindelin 2017-09-18 22:25 ` Jonathan Nieder 2017-09-26 17:05 ` Jason Cooper 2017-09-26 22:11 ` Johannes Schindelin 2017-09-26 22:25 ` [PATCH] technical doc: add a design doc for hash function transition Stefan Beller 2017-09-26 23:38 ` Jonathan Nieder 2017-09-26 23:51 ` RFC v3: Another proposed hash function transition plan Jonathan Nieder 2017-10-02 14:54 ` Jason Cooper 2017-10-02 16:50 ` Brandon Williams 2017-10-02 14:00 ` Jason Cooper 2017-10-02 17:18 ` Linus Torvalds 2017-10-02 19:37 ` Jeff King 2017-09-13 16:30 ` Jonathan Nieder 2017-09-13 21:52 ` Junio C Hamano 2017-09-13 22:07 ` Stefan Beller 2017-09-13 22:18 ` Jonathan Nieder 2017-09-14 2:13 ` Junio C Hamano 2017-09-14 15:23 ` Johannes Schindelin 2017-09-14 15:45 ` demerphq 2017-09-14 22:06 ` Johannes Schindelin 2017-09-13 22:15 ` Junio C Hamano 2017-09-13 22:27 ` Jonathan Nieder 2017-09-14 2:10 ` Junio C Hamano 2017-09-14 12:39 ` Johannes Schindelin 2017-09-14 16:36 ` Brandon Williams 2017-09-14 18:49 ` Jonathan Nieder 2017-09-15 20:42 ` Philip Oakley 2017-03-05 11:02 ` RFC: " David Lang [not found] ` <CA+dhYEXHbQfJ6KUB1tWS9u1MLEOJL81fTYkbxu4XO-i+379LPw@mail.gmail.com> 2017-03-06 9:43 ` Jeff King 2017-03-06 23:40 ` Jonathan Nieder 2017-03-07 0:03 ` Mike Hommey 2017-03-06 8:43 ` Jeff King 2017-03-06 18:39 ` Jonathan Tan 2017-03-06 19:22 ` Linus Torvalds 2017-03-06 19:59 ` Brandon Williams 2017-03-06 21:53 ` Junio C Hamano 2017-03-07 8:59 ` Jeff King 2017-03-06 18:43 ` Junio C Hamano 2017-03-07 18:57 ` Ian Jackson 2017-03-07 19:15 ` Linus Torvalds 2017-03-08 11:20 ` Ian Jackson 2017-03-08 15:37 ` Johannes Schindelin 2017-03-08 15:40 ` Johannes Schindelin 2017-03-20 5:21 ` Use base32? Jason Hennessey 2017-03-20 5:58 ` Michael Steuer 2017-03-20 8:05 ` Jacob Keller 2017-03-21 3:07 ` Michael Steuer 2017-03-13 9:24 ` RFC: Another proposed hash function transition plan The Keccak Team 2017-03-13 17:48 ` Jonathan Nieder 2017-03-13 18:34 ` ankostis 2017-03-17 11:07 ` Johannes Schindelin
Reply instructions: You may reply publically 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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --cc=Johannes.Schindelin@gmx.de \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox