Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi Peff, On Fri, 16 Jun 2017, Jeff King wrote: > On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote: > > > I have no doubt that Visual Studio Team Services, GitHub and Atlassian > > will eventually end up with FPGAs for hash computation. So that's > > that. > > I actually

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16 2017, Jonathan Nieder jotted: > Part of the reason I suggested previously that it would be helpful to > try to benchmark Git with various hash functions (which didn't go over > well, for some reason) is that it makes these comparisons more > concrete. Without measuring, it is hard

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Junio C Hamano wrote: > Junio C Hamano writes: >> Adam Langley writes: >>> However, as I'm not a git developer, I've no opinion on whether the >>> cost of carrying implementations of these functions is worth the speed >>> vs using SHA-256, which can be

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Junio C Hamano writes: > Adam Langley writes: > >> However, as I'm not a git developer, I've no opinion on whether the >> cost of carrying implementations of these functions is worth the speed >> vs using SHA-256, which can be assumed to be supported

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Adam Langley writes: > However, as I'm not a git developer, I've no opinion on whether the > cost of carrying implementations of these functions is worth the speed > vs using SHA-256, which can be assumed to be supported everywhere > already. Thanks. My impression from this

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote: > I have no doubt that Visual Studio Team Services, GitHub and Atlassian > will eventually end up with FPGAs for hash computation. So that's that. I actually doubt this from the GitHub side. Hash performance is not even on our

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin wrote: > > And while I am really thankful that Adam chimed in, I think he would agree > that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit > of speed That is correct. Although worth keeping in

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, On Fri, 16 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 16 2017, brian m. carlson jotted: > > > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > >> So I don't follow the argument that we shouldn't weigh future HW > >> acceleration highly just because

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

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 >> wrote: >> > SHA-256 acceleration exists for some existing Intel platforms already. >> >

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 06:10:22AM +0900, Mike Hommey wrote: > > > What do the experts think or SHA512/256, which completely removes the > > > concerns over length extension attack? (which I'd argue is better than > > > sweeping them under the carpet) > > > > I don't think it's sweeping them

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

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 > wrote: > > SHA-256 acceleration exists for some existing Intel platforms already. > > However, they're not practically present on anything

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson wrote: > On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote: >> (I was asked to comment a few points in public by Jonathan.) >> >> I think this group can safely assume that SHA-256, SHA-512, BLAKE2, >> K12,

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote: > (I was asked to comment a few points in public by Jonathan.) > > I think this group can safely assume that SHA-256, SHA-512, BLAKE2, > K12, etc are all secure to the extent that I don't believe that making > comparisons between them

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

(I was asked to comment a few points in public by Jonathan.) I think this group can safely assume that SHA-256, SHA-512, BLAKE2, K12, etc are all secure to the extent that I don't believe that making comparisons between them on that axis is meaningful. Thus I think the question is primarily

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > > Footnote *1*: SHA-256, as all hash functions whose output is essentially > > > the entire

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, On Thu, 15 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jun 15 2017, Jeff King jotted: > > > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > > > >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > >> > >> > Footnote *1*: SHA-256, as all hash

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Brandon Williams writes: >> It would make a whole of a lot of sense to make that knob not Boolean, >> but to specify which hash function is in use. > > 100% agree on this point. I believe the current plan is to have the > hashing function used for a repository be a repository

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi Dscho, Johannes Schindelin wrote: > From what I read, pretty much everybody who participated in the discussion > was aware that the essential question is: performance vs security. I don't completely agree with this framing. The essential question is: how to get the right security properties

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On 06/15, Johannes Schindelin wrote: > Hi, > > I thought it better to revive this old thread rather than start a new > thread, so as to automatically reach everybody who chimed in originally. > > On Mon, 6 Mar 2017, Brandon Williams wrote: > > > On 03/06, brian m. carlson wrote: > > > > > On

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15 2017, Jeff King jotted: > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: >> > Footnote *1*: SHA-256, as all hash functions whose output is essentially >> > the entire internal state, are

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote: > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > > Footnote *1*: SHA-256, as all hash functions whose output is essentially > > the entire internal state, are susceptible to a so-called "length > > extension

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote: > Footnote *1*: SHA-256, as all hash functions whose output is essentially > the entire internal state, are susceptible to a so-called "length > extension attack", where the hash of a secret+message can be used to > generate the

Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, I thought it better to revive this old thread rather than start a new thread, so as to automatically reach everybody who chimed in originally. On Mon, 6 Mar 2017, Brandon Williams wrote: > On 03/06, brian m. carlson wrote: > > > On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds

Re: RFC: Another proposed hash function transition plan

Hi Kostis, On Mon, 13 Mar 2017, ankostis wrote: > On 13 March 2017 at 18:48, Jonathan Nieder wrote: > > > > The Keccak Team wrote: > > > > > We have read your transition plan to move away from SHA-1 and > > > noticed your intent to use SHA3-256 as the new hash function in

Re: RFC: Another proposed hash function transition plan

On 13 March 2017 at 18:48, Jonathan Nieder wrote: > > Hi, > > The Keccak Team wrote: > > > We have read your transition plan to move away from SHA-1 and noticed > > your intent to use SHA3-256 as the new hash function in the new Git > > repository format and protocol. Although

Re: RFC: Another proposed hash function transition plan

Hi, The Keccak Team wrote: > We have read your transition plan to move away from SHA-1 and noticed > your intent to use SHA3-256 as the new hash function in the new Git > repository format and protocol. Although this is a valid choice, we > think that the new SHA-3 standard proposes alternatives

Re: RFC: Another proposed hash function transition plan

Hello, We have read your transition plan to move away from SHA-1 and noticed your intent to use SHA3-256 as the new hash function in the new Git repository format and protocol. Although this is a valid choice, we think that the new SHA-3 standard proposes alternatives that may also be interesting

Re: RFC: Another proposed hash function transition plan

Hi Ian, On Wed, 8 Mar 2017, Ian Jackson wrote: > Linus Torvalds writes ("Re: RFC: Another proposed hash function transition > plan"): > > Of course, having written that, I now realize how it would cause > > problems for the usual shit-for-brains case-insensitive

Re: RFC: Another proposed hash function transition plan

Hi Ian, On Wed, 8 Mar 2017, Ian Jackson wrote: > Few people use uppercase in ref names because of the case-insensitive > filesystem problem; Not true. Ciao, Johannes

Re: RFC: Another proposed hash function transition plan

Linus Torvalds writes ("Re: RFC: Another proposed hash function transition plan"): > Also, since 256 isn't evenly divisible by 6, and because you'd want > some way to explictly disambiguate the new hashes, the rule *could* be > that the ASCII representation of a new hash is

Re: RFC: Another proposed hash function transition plan

Jonathan Nieder writes ("RFC: Another proposed hash function transition plan"): > This past week we came up with this idea for what a transition to a new > hash function for Git would look like. I'd be interested in your > thoughts (especially if you can make them as comme

Re: RFC: Another proposed hash function transition plan

On Tue, Mar 7, 2017 at 10:57 AM, Ian Jackson wrote: > > Also I think you need to specify how abbreviated object names are > interpreted. One option might be to not use hex for the new hash, but base64 encoding. That would make the full size ASCII hash encoding

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 10:39:49AM -0800, Jonathan Tan wrote: > The "nohash" thing was in the hope of requiring only one signature to sign > all the hashes (in all the functions) that the user wants, while preserving > round-tripping ability. Thanks, this explained it very well. I understand

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote: > David Lang wrote: > > >> Translation table > >> ~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk. The exact format > >> of that

Re: RFC: Another proposed hash function transition plan

David Lang wrote: >> Translation table >> ~ >> A fast bidirectional mapping between sha1-names and sha256-names of >> all local objects in the repository is kept on disk. The exact format >> of that mapping is to be determined. >> >> All operations that make new objects (e.g.,

Re: RFC: Another proposed hash function transition plan

Linus Torvalds writes: > So *if* the new object format uses a git header line like > > "blob \0" > > then it would inherently contain that mapping from 256-bit hash to the > SHA1, but it would actually also protect against attacks on the new > hash. This is

Re: RFC: Another proposed hash function transition plan

On 03/06, Linus Torvalds wrote: > On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan > wrote: > > > > I think "nohash" can be explained in 2 points: > > I do think that that was my least favorite part of the suggestion. Not > just "nohash", but all the special "hash" lines

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan wrote: > > I think "nohash" can be explained in 2 points: I do think that that was my least favorite part of the suggestion. Not just "nohash", but all the special "hash" lines too. I would honestly hope that the design

Re: RFC: Another proposed hash function transition plan

On 03/06/2017 12:43 AM, Jeff King wrote: Overall the basics of the conversion seem sound to me. The "nohash" things seems more complicated than I think it ought to be, which probably just means I'm missing something. I left a few related comments on the google doc, so I won't repeat them here.

Re: RFC: Another proposed hash function transition plan

Jeff King writes: >> You can use the doc URL >> >> https://goo.gl/gh2Mzc > > I'd encourage anybody following along to follow that link. I almost > didn't, but there are a ton of comments there (I'm not sure how I feel > about splitting the discussion off the list, though). I am

Re: RFC: Another proposed hash function transition plan

On 03/06, brian m. carlson wrote: > On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote: > > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote: > > > > > > This document is still in flux but I thought it best to send it out > > > early to start getting feedback.

Re: RFC: Another proposed hash function transition plan

On Mon, Mar 06, 2017 at 10:29:33AM +0100, ankostis wrote: > On 5 March 2017 at 12:02, David Lang wrote: > >> Translation table > >> ~ > >> A fast bidirectional mapping between sha1-names and sha256-names of > >> all local objects in the repository is kept on disk.

Re: RFC: Another proposed hash function transition plan

On Fri, Mar 03, 2017 at 05:12:51PM -0800, Jonathan Nieder wrote: > This past week we came up with this idea for what a transition to a new > hash function for Git would look like. I'd be interested in your > thoughts (especially if you can make them as comments on the document, > which makes it

Re: RFC: Another proposed hash function transition plan

On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote: > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote: > > > > This document is still in flux but I thought it best to send it out > > early to start getting feedback. > > This actually looks very reasonable if

Re: RFC: Another proposed hash function transition plan

Translation table ~ A fast bidirectional mapping between sha1-names and sha256-names of all local objects in the repository is kept on disk. The exact format of that mapping is to be determined. All operations that make new objects (e.g., "git commit") add the new objects to the

Re: RFC: Another proposed hash function transition plan

On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote: > > This document is still in flux but I thought it best to send it out > early to start getting feedback. This actually looks very reasonable if you can implement it cleanly enough. In many ways the "convert entirely to

RFC: Another proposed hash function transition plan

Hi, This past week we came up with this idea for what a transition to a new hash function for Git would look like. I'd be interested in your thoughts (especially if you can make them as comments on the document, which makes it easier to address them and update the document). This document is