From: Jonathan Nieder <jrnieder@gmail.com> To: demerphq <demerphq@gmail.com> Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, Johannes Schindelin <Johannes.Schindelin@gmx.de>, Git <git@vger.kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>, agl@google.com, keccak@noekeon.org Subject: Re: Hash algorithm analysis Date: Mon, 23 Jul 2018 11:35:24 -0700 [thread overview] Message-ID: <20180723183523.GB9285@aiede.svl.corp.google.com> (raw) In-Reply-To: <CANgJU+X39NoEoMyLu+FX38=x19LrRqatz_dUpUAc+WFV+Uw+=A@mail.gmail.com> Hi Yves, demerphq wrote: > On Sun, 22 Jul 2018 at 01:59, brian m. carlson > <sandals@crustytoothpaste.net> wrote: >> I will admit that I don't love making this decision by myself, because >> right now, whatever I pick, somebody is going to be unhappy. [...] > I do not envy you this decision. > > Personally I would aim towards pushing this decision out to the git > user base and facilitating things so we can choose whatever hash > function (and config) we wish, including ones not invented yet. There are two separate pieces to this. One is configurability at compile time. So far that has definitely been a goal, because we want to be ready to start the transition to another hash, and quickly, as soon as the new hash is discovered to be weak. This also means that people can experiment with new hashes and in a controlled environment (where the users can afford to build from source), some users might prefer some bespoke hash for reasons only known to them. ;-) Another piece is configurability at run time. This is a harder sell because it has some negative effects in the ecosystem: - performance impact from users having to maintain a translation table between the different hash functions in use - security impact, in the form of downgrade attacks - dependency bloat, from Git having to be able to compute all hash functions permitted in that run-time configuration The security impact can be mitigated by keeping the list of supported hashes small (i.e. two or three instead of 10ish). Each additional hash function is a potential liability (just as in SSL), so they have to earn their keep. The performance impact is unavoidable if we encourage Git servers to pick their favorite hash function instead of making a decision in the project. This can in turn affect security, since it would increase the switching cost away from SHA-1, with the likely effect being that most users stay on SHA-1. I don't want to go there. So I would say, support for arbitrary hash functions at compile time and in file formats is important and I encourage you to hold us to that (when reviewing patches, etc). But in the standard Git build configuration that most people run, I believe it is best to support only SHA-1 + our chosen replacement hash. Thanks, Jonathan
next prev parent reply other threads:[~2018-07-23 18:35 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 [this message] 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 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=20180723183523.GB9285@aiede.svl.corp.google.com \ --to=jrnieder@gmail.com \ --cc=Johannes.Schindelin@gmx.de \ --cc=agl@google.com \ --cc=demerphq@gmail.com \ --cc=git@vger.kernel.org \ --cc=keccak@noekeon.org \ --cc=sandals@crustytoothpaste.net \ --cc=torvalds@linux-foundation.org \ --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).