Re: Migrating away from SHA-1?

On Sat, Jun 18, 2016 at 03:10:27AM +0100, Leo Gaspard wrote: > First, sorry for not having this message threaded: I'm not subscribed to > the list and haven't found a way to get a Message-Id from gmane. Sorry it's taken so long to get back to this. I've been at a conference. > So, my questions

Re: Migrating away from SHA-1?

Leo Gaspard wrote: > First, sorry for not having this message threaded: I'm not subscribed to > the list and haven't found a way to get a Message-Id from gmane. Appending "/raw" to the gmane URL will get you the raw message with full headers:

Re: Migrating away from SHA-1?

First, sorry for not having this message threaded: I'm not subscribed to the list and haven't found a way to get a Message-Id from gmane. I just wanted to ask, as an end-user highly relying on commit signatures, a few questions as to the migration away from SHA-1. SHA-1 already suffers from a

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 06:58:10PM -0700, H. Peter Anvin wrote: > On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote: > >On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote: > >> OK, I'm going to open this can of worms... > >> > >> At what point do we migrate

Re: Migrating away from SHA-1?

On Thu, Apr 14, 2016 at 07:18:53PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > [2] Somewhere in the list archive is my patch to find partial > > collisions like "git commit --sha1=31337", and I did in fact use > > that micro-optimization. That, along with

Re: Migrating away from SHA-1?

Jeff King writes: > [2] Somewhere in the list archive is my patch to find partial > collisions like "git commit --sha1=31337", and I did in fact use > that micro-optimization. That, along with multi-threading, made it > feasible to do 6-8 character prefixes, as I

Re: Migrating away from SHA-1?

On Thu, Apr 14, 2016 at 06:40:51PM -0400, Theodore Ts'o wrote: > Also, remember that while we can write programs that look for > suspicious git objects that have stuff hidden after the null > terminator (in fact, maybe that would be a good thing to add to git, > hmmm?)[...] Detecting the hidden

Re: Migrating away from SHA-1?

On Thu, Apr 14, 2016 at 10:28:50AM -0700, H. Peter Anvin wrote: > > Either way, I agree with Ted, that we have enough time to do it > right, but that is a good reason to do it sooner rather than later > (see also my note about freezing the cryptographic properties.) Sure, I think we should do it

Re: Migrating away from SHA-1?

On April 14, 2016 10:23:03 AM PDT, David Turner wrote: >On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote: >> On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: >> > >> > If SHA-1 is broken (in certain ways), someone *can* replace an >> > arbitrary

Re: Migrating away from SHA-1?

On Wed, 2016-04-13 at 21:53 -0400, Theodore Ts'o wrote: > On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: > > > > If SHA-1 is broken (in certain ways), someone *can* replace an > > arbitrary blob. GPG does not help in this case, because the > > signature > > is over the commit

Re: Migrating away from SHA-1?

Theodore Ts'o wrote: > OK, so how does this map to git? First of all, from a collision > perspective, the two blobs have to map into valid C code Git provides other places to hide the colliding blobs; the best seems to be as an added header in the commit object, or as trailing data after a \0 in

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: > > If SHA-1 is broken (in certain ways), someone *can* replace an > arbitrary blob. GPG does not help in this case, because the signature > is over the commit object (which points to a tree, which eventually > points to the blob),

Re: Migrating away from SHA-1?

On April 12, 2016 6:51:12 PM PDT, Duy Nguyen wrote: >On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote: >> OK, I'm going to open this can of worms... >> >> At what point do we migrate from SHA-1? > >Brian Carlson has been slowly refactoring git code base,

Re: Migrating away from SHA-1?

On Wed, Apr 13, 2016 at 5:38 AM, H. Peter Anvin wrote: > OK, I'm going to open this can of worms... > > At what point do we migrate from SHA-1? Brian Carlson has been slowly refactoring git code base, abstracting SHA-1 away. Once that work is done, I think we can talk about

Re: Migrating away from SHA-1?

On 04/12/16 18:03, Junio C Hamano wrote: and so on. Of course trees don't have any space for this; they have a fixed-length for the hash part of each record, which is basically: NUL <20-byte-sha1> So we'd probably need a "treev2" object type that gives room for an algorithm byte (or we'd

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 06:03:02PM -0700, Junio C Hamano wrote: > > So we'd probably need a "treev2" object type that gives room for an > > algorithm byte (or we'd have to try to shove it into the mode, but since > > old versions won't know the new algorithm anyway, I don't think it > > solves

Re: Migrating away from SHA-1?

Jeff King writes: > So a slightly nicer thing is to parameterize the algorithm for every > object name reference. So commits look like: > > tree sha256:1234abcd... > parent sha256:1234abcd... > > and so on. Of course trees don't have any space for this; they have a >

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 07:15:34PM -0400, David Turner wrote: > It would be possible, of course, to GPG-sign the entire commit's > transitive data (rather than just the SHA1s of same). But as far as I > know, that is not ever what is done. There is a project called git-evtag which does this,

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 03:38:04PM -0700, H. Peter Anvin wrote: > For existing repositories we will need to have a migration mechanism. Since > we can't modify objects without completely invalidating the cryptographic > properties, what I would suggest is that we leave the existing objects as >

Re: Migrating away from SHA-1?

On Tue, 2016-04-12 at 16:00 -0700, Stefan Beller wrote: > On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin > wrote: > > OK, I'm going to open this can of worms... > > > > At what point do we migrate from SHA-1? At this point the > > cryptoanalysis of > > SHA-1 is most likely a

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 04:00:18PM -0700, Stefan Beller wrote: > On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote: > > OK, I'm going to open this can of worms... > > > > At what point do we migrate from SHA-1? At this point the cryptoanalysis of > > SHA-1 is most likely a

Re: Migrating away from SHA-1?

On 04/12/16 16:00, Stefan Beller wrote: On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote: OK, I'm going to open this can of worms... At what point do we migrate from SHA-1? At this point the cryptoanalysis of SHA-1 is most likely a matter of time. And I thought the

Re: Migrating away from SHA-1?

On Tue, Apr 12, 2016 at 3:38 PM, H. Peter Anvin wrote: > OK, I'm going to open this can of worms... > > At what point do we migrate from SHA-1? At this point the cryptoanalysis of > SHA-1 is most likely a matter of time. And I thought the cryptographic properties of SHA1 did not

Migrating away from SHA-1?

OK, I'm going to open this can of worms... At what point do we migrate from SHA-1? At this point the cryptoanalysis of SHA-1 is most likely a matter of time. For existing repositories we will need to have a migration mechanism. Since we can't modify objects without completely invalidating