From: "brian m. carlson" <email@example.com> To: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org> Cc: email@example.com, Adam Langley <firstname.lastname@example.org>, 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>, Stefan Beller <firstname.lastname@example.org>, Jonathan Tan <email@example.com>, Junio Hamano <firstname.lastname@example.org>, Johannes Schindelin <Johannes.Schindelin@gmx.de> Subject: Re: Hash algorithm analysis Date: Thu, 21 Jun 2018 22:39:16 +0000 [thread overview] Message-ID: <20180621223916.GA787060@genre.crustytoothpaste.net> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 2700 bytes --] On Mon, Jun 11, 2018 at 11:19:10PM +0200, Ævar Arnfjörð Bjarmason wrote: > This is a great summary. Thanks. > > In case it's not apparent from what follows, I have a bias towards > SHA-256. Reasons for that, to summarize some of the discussion the last > time around, and to add more details: To summarize my view, I think my ordered preference of hashes is BLAKE2b, SHA-256, and SHA3-256. I agree with AGL that all three of these options are secure and will be for some time. I believe there's sufficient literature on all three of them and there will continue to be for some time. I've seen and read papers from the IACR archves on all three of them, and because all three are widely used, they'll continue to be interesting to cryptologists for a long time to come. I'm personally partial to having full preimage resistance, which I think makes SHAKE128 less appealing. SHAKE128 also has fewer crypto library implementations than the others. My rationale for this ordering is essentially performance. BLAKE2b is quite fast on all known hardware, and it is almost as fast as an accelerated SHA-256. The entire rationale for BLAKE2b is to give people a secure algorithm that is faster than MD5 and SHA-1, so there's no reason to use an insecure algorithm. It also greatly outperforms the other two even in pure C, which matters for the fallback implementation we'll need to ship. I tend to think SHA3-256 is the most conservative of these choices as far as security. It has had an open development process and has a large security margin. It has gained a lot of cryptanalysis and come out quite well, and the versatility of the Keccak sponge construction means that it's going to get a lot more attention. Pretty much the only downside is its performance relative to the other two. I placed SHA-256 in the middle because of its potential for acceleration on Intel hardware. I know such changes are coming, but they won't likely be here for another two years. While hashing performance isn't a huge concern for Git now, I had planned to implement an rsync-based delta algorithm for large files that could make storing some large files in a Git repository viable (of course, there will still be many cases where Git LFS and git-annex are better). The algorithm is extremely sensitive to hash performance and would simply not be viable with an unaccelerated SHA-256 or SHA3-256, although it would perform reasonably well with BLAKE2b. Having said that, I'd be happy with any of the three, and would support a consensus around any of them as well. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204 [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 867 bytes --]
next prev parent reply other threads:[~2018-06-21 22:39 UTC|newest] Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-06-09 20:56 State of NewHash work, future directions, and discussion brian m. carlson 2018-06-09 21:26 ` Ævar Arnfjörð Bjarmason 2018-06-09 22:49 ` Hash algorithm analysis brian m. carlson 2018-06-11 19:29 ` Jonathan Nieder 2018-06-11 20:20 ` Linus Torvalds 2018-06-11 23:27 ` Ævar Arnfjörð Bjarmason 2018-06-12 0:11 ` David Lang 2018-06-12 0:45 ` Linus Torvalds 2018-06-11 22:35 ` brian m. carlson 2018-06-12 16:21 ` Gilles Van Assche 2018-06-13 23:58 ` brian m. carlson 2018-06-15 10:33 ` Gilles Van Assche 2018-07-20 21:52 ` brian m. carlson 2018-07-21 0:31 ` Jonathan Nieder 2018-07-21 19:52 ` Ævar Arnfjörð Bjarmason 2018-07-21 20:25 ` brian m. carlson 2018-07-21 22:38 ` Johannes Schindelin 2018-07-21 23:09 ` Linus Torvalds 2018-07-21 23:59 ` brian m. carlson 2018-07-22 9:34 ` Eric Deplagne 2018-07-22 14:21 ` brian m. carlson 2018-07-22 14:55 ` Eric Deplagne 2018-07-26 10:05 ` Johannes Schindelin 2018-07-22 15:23 ` Joan Daemen 2018-07-22 18:54 ` Adam Langley 2018-07-26 10:31 ` Johannes Schindelin 2018-07-23 12:40 ` demerphq 2018-07-23 12:48 ` Sitaram Chamarty 2018-07-23 12:55 ` demerphq 2018-07-23 18:23 ` Linus Torvalds 2018-07-23 17:57 ` Stefan Beller 2018-07-23 18:35 ` Jonathan Nieder 2018-07-24 19:01 ` Edward Thomson 2018-07-24 20:31 ` Linus Torvalds 2018-07-24 20:49 ` Jonathan Nieder 2018-07-24 21:13 ` Junio C Hamano 2018-07-24 22:10 ` brian m. carlson 2018-07-30 9:06 ` Johannes Schindelin 2018-07-30 20:01 ` Dan Shumow 2018-08-03 2:57 ` Jonathan Nieder 2018-09-18 15:18 ` Joan Daemen 2018-09-18 15:32 ` Jonathan Nieder 2018-09-18 16:50 ` Linus Torvalds 2018-07-25 8:30 ` [PATCH 0/2] document that NewHash is now SHA-256 Ævar Arnfjörð Bjarmason 2018-07-25 8:30 ` [PATCH 1/2] doc hash-function-transition: note the lack of a changelog Ævar Arnfjörð Bjarmason 2018-07-25 8:30 ` [PATCH 2/2] doc hash-function-transition: pick SHA-256 as NewHash Ævar Arnfjörð Bjarmason 2018-07-25 16:45 ` Junio C Hamano 2018-07-25 17:25 ` Jonathan Nieder 2018-07-25 21:32 ` Junio C Hamano 2018-07-26 13:41 ` [PATCH v2 " Ævar Arnfjörð Bjarmason 2018-08-03 7:20 ` Jonathan Nieder 2018-08-03 16:40 ` Junio C Hamano 2018-08-03 17:01 ` Linus Torvalds 2018-08-03 16:42 ` Linus Torvalds 2018-08-03 17:43 ` Ævar Arnfjörð Bjarmason 2018-08-04 8:52 ` Jonathan Nieder 2018-08-03 17:45 ` brian m. carlson 2018-07-25 22:56 ` [PATCH " brian m. carlson 2018-06-11 21:19 ` Hash algorithm analysis Ævar Arnfjörð Bjarmason 2018-06-21 8:20 ` Johannes Schindelin 2018-06-21 22:39 ` brian m. carlson [this message] 2018-06-11 18:09 ` State of NewHash work, future directions, and discussion Duy Nguyen 2018-06-12 1:28 ` brian m. carlson 2018-06-11 19:01 ` Jonathan Nieder 2018-06-12 2:28 ` brian m. carlson 2018-06-12 2:42 ` Jonathan Nieder
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 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 \ --in-reply-to=20180621223916.GA787060@genre.crustytoothpaste.net \ --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 \ --subject='Re: Hash algorithm analysis' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).