From: Jonathan Nieder <jrnieder@gmail.com> To: Junio C Hamano <gitster@pobox.com> Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org, "Linus Torvalds" <torvalds@linux-foundation.org>, "Edward Thomson" <ethomson@edwardthomson.com>, "brian m . carlson" <sandals@crustytoothpaste.net>, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>, demerphq <demerphq@gmail.com>, "Adam Langley" <agl@google.com>, keccak@noekeon.org Subject: Re: [PATCH 2/2] doc hash-function-transition: pick SHA-256 as NewHash Date: Wed, 25 Jul 2018 10:25:37 -0700 Message-ID: <20180725172537.GA176329@aiede.svl.corp.google.com> (raw) In-Reply-To: <xmqq4lgnw9fj.fsf@gitster-ct.c.googlers.com> Hi, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: >> The consensus on the mailing list seems to be that SHA-256 should be >> picked as our NewHash, see the "Hash algorithm analysis" thread as of >> [1]. Linus has come around to this choice and suggested Junio make the >> final pick, and he's endorsed SHA-256 [3]. I think this commit message focuses too much on the development process, in a way that makes it not necessary useful to the target audience that would be finding it with "git blame" or "git log". It's also not self-contained, which makes it less useful in the same way. In other words, the commit message should be speaking for the project, not speaking about the project. I would be tempted to say something as simple as hash-function-transition: pick SHA-256 as NewHash The project has decided. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> and let any Acked-bys on the message speak for themselves. Alternatively, the commit message could include a summary of the discussion: From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256, K12, and so on are all believed to have similar security properties. All are good options from a security point of view. SHA-256 has a number of advantages: * It has been around for a while, is widely used, and is supported by just about every single crypto library (OpenSSL, mbedTLS, CryptoNG, SecureTransport, etc). * When you compare against SHA1DC, most vectorized SHA-256 implementations are indeed faster, even without acceleration. * If we're doing signatures with OpenPGP (or even, I suppose, CMS), we're going to be using SHA-2, so it doesn't make sense to have our security depend on two separate algorithms when either one of them alone could break the security when we could just depend on one. So SHA-256 it is. [...] >> @@ -125,19 +122,19 @@ Detailed Design >> --------------- >> Repository format extension >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> -A NewHash repository uses repository format version `1` (see >> +A SHA-256 repository uses repository format version `1` (see >> Documentation/technical/repository-version.txt) with extensions >> `objectFormat` and `compatObjectFormat`: >> >> [core] >> repositoryFormatVersion = 1 >> [extensions] >> - objectFormat = newhash >> + objectFormat = sha256 >> compatObjectFormat = sha1 > > Whenever we said SHA1, somebody came and told us that the name of > the hash is SHA-1 (with dash). Would we be nitpicker-prone in the > same way with "sha256" here? Regardless of how we spell it in prose, I think `sha256` as an identifier in configuration is the spelling people will expect. For example, gpg ("gpg --version") calls it SHA256. [...] >> Selection of a New Hash >> ----------------------- >> @@ -611,6 +608,10 @@ collisions in 2^69 operations. In August they published details. >> Luckily, no practical demonstrations of a collision in full SHA-1 were >> published until 10 years later, in 2017. >> >> +It was decided that Git needed to transition to a new hash >> +function. Initially no decision was made as to what function this was, >> +the "NewHash" placeholder name was picked to describe it. >> + >> The hash function NewHash to replace SHA-1 should be stronger than >> SHA-1 was: we would like it to be trustworthy and useful in practice >> for at least 10 years. > > This sentence needs a bit of updating to match the new paragraph > inserted above. "should be stronger" is something said by those > who are still looking for one and/or trying to decide. For what it's worth, I would be in favor of modifying the section more heavily. For example: Choice of Hash -------------- In early 2005, around the time that Git was written, Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu announced an attack finding SHA-1 collisions in 2^69 operations. In August they published details. Luckily, no practical demonstrations of a collision in full SHA-1 were published until 10 years later, in 2017. Git v2.13.0 and later subsequently moved to a hardened SHA-1 implementation by default that mitigates the SHAttered attack, but SHA-1 is still believed to be weak. The hash to replace this hardened SHA-1 should be stronger than SHA-1 was: we would like it to be trustworthy and useful in practice for at least 10 years. Some other relevant properties: 1. A 256-bit hash (long enough to match common security practice; not excessively long to hurt performance and disk usage). 2. High quality implementations should be widely available (e.g., in OpenSSL and Apple CommonCrypto). 3. The hash function's properties should match Git's needs (e.g. Git requires collision and 2nd preimage resistance and does not require length extension resistance). 4. As a tiebreaker, the hash should be fast to compute (fortunately many contenders are faster than SHA-1). We choose SHA-256. Changes: - retitled since the hash function has already been selected - added some notes about sha1dc - when discussing wide implementation availability, mentioned CommonCrypto too, as an example of a non-OpenSSL library that the libgit2 authors care about - named which function is chosen We could put the runners up in the "alternatives considered" section, but I don't think there's much to say about them here so I wouldn't. Thanks and hope that helps, Jonathan
next prev parent reply other threads:[~2018-07-25 17:25 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 [this message] 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=20180725172537.GA176329@aiede.svl.corp.google.com \ --to=jrnieder@gmail.com \ --cc=Johannes.Schindelin@gmx.de \ --cc=agl@google.com \ --cc=avarab@gmail.com \ --cc=demerphq@gmail.com \ --cc=ethomson@edwardthomson.com \ --cc=git@vger.kernel.org \ --cc=gitster@pobox.com \ --cc=keccak@noekeon.org \ --cc=sandals@crustytoothpaste.net \ --cc=torvalds@linux-foundation.org \ /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
git@vger.kernel.org list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: 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 # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors. 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.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git