Re: Git and SHA-1 security (again)

Sorry if I'm dropping in at the wrong point (this is one I'd bookmarked).. From: "Duy Nguyen" Sent: Wednesday, July 20, 2016 3:44 PM On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin wrote: But that strategy *still* ignores the distributed

Re: Git and SHA-1 security (again)

Johannes Schindelin writes: > Hi Junio, > > On Mon, 18 Jul 2016, Junio C Hamano wrote: > >> "brian m. carlson" writes: >> >> > I will say that the pack format will likely require some changes, >> > because it assumes ... The reason is

Re: Git and SHA-1 security (again)

Hi Brian, On Mon, 18 Jul 2016, brian m. carlson wrote: > On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote: > > > FWIW it never crossed my mind to allow different same-sized hash > > algorithms. So I never thought we'd need a way to distinguish, say, > > BLAKE2b-256 from

Re: Git and SHA-1 security (again)

Hi Brian, On Mon, 18 Jul 2016, brian m. carlson wrote: > On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote: > > Continuing this thought process, I do not see a good way to allow us > > to wean ourselves off of the old hash, unless we _break_ the pack > > stream format so that each

Re: Git and SHA-1 security (again)

Hi Junio, On Mon, 18 Jul 2016, Junio C Hamano wrote: > "brian m. carlson" writes: > > > I will say that the pack format will likely require some changes, > > because it assumes ... The reason is that we can't have an > > unambiguous parse of the current objects

Re: Git and SHA-1 security (again)

Stefan Beller writes: >> to follow the above, in my view, interaction with sha1 repos go >> through some conversion bridges like what we have with hg and svn. I >> don't know if we are going this route. It's certainly simpler and >> people already have experiences (from

Re: Git and SHA-1 security (again)

On Wed, Jul 20, 2016 at 7:44 AM, Duy Nguyen wrote: > On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin > wrote: >> But that strategy *still* ignores the distributed nature of Git. Just >> because *you* make that merge at a certain point does not

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 8:58 PM, Herczeg Zsolt wrote: > 2016-07-19 20:04 GMT+02:00 Duy Nguyen : >> On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: >>> On Tue, 19 Jul 2016, Duy Nguyen wrote: >>> On Tue, Jul 19, 2016 at 7:34 PM, David

Re: Git and SHA-1 security (again)

On Wed, Jul 20, 2016 at 2:28 PM, Johannes Schindelin wrote: > But that strategy *still* ignores the distributed nature of Git. Just > because *you* make that merge at a certain point does not necessarily mean > that I make it at that point, too. > > Any approach that

Re: Git and SHA-1 security (again)

Hi Duy, On Tue, 19 Jul 2016, Duy Nguyen wrote: > On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: > > On Tue, 19 Jul 2016, Duy Nguyen wrote: > > > >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: > >>> > >>> On Tue, 19 Jul 2016, Duy Nguyen wrote: > >>> >

Re: Git and SHA-1 security (again)

2016-07-19 20:04 GMT+02:00 Duy Nguyen : > On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: >> On Tue, 19 Jul 2016, Duy Nguyen wrote: >> >>> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: On Tue, 19 Jul 2016, Duy Nguyen wrote:

Re: Git and SHA-1 security (again)

Duy Nguyen writes: >> Even though that single operation might be possible, do not go >> there. A "pathname" identifies a "path", not its contents, and >> "appending crap after path" breaks the data model badly. > > I thought about that but I thought all those operations

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:59 PM, David Lang wrote: > On Tue, 19 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: >>> >>> On Tue, 19 Jul 2016, Duy Nguyen wrote: >>> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: But we can recreate SHA-1 from the same content and

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:34 PM, David Lang wrote: > On Tue, 19 Jul 2016, Duy Nguyen wrote: > >> On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin >> wrote: But we can recreate SHA-1 from the same content and verify GPG, right? I know

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Duy Nguyen wrote: On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: But we can recreate SHA-1 from the same content and verify GPG, right? I know it's super expensive, but it feels safer to not carry SHA-1 around when it's not secure

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 7:06 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Post-shower thoughts. In a tree object, a submodule entry consists of >> perm (S_IFGITLINK), hash (which is the external hash) and path. We >> could fill the "hash" part with

Re: Git and SHA-1 security (again)

Duy Nguyen writes: > Post-shower thoughts. In a tree object, a submodule entry consists of > perm (S_IFGITLINK), hash (which is the external hash) and path. We > could fill the "hash" part with all zero (invalid, signature of new > submodule hash format), then append "/:" to >

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 6:51 PM, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: >> I'm going to end up having to do something similar because of the issue >> of submodules. Submodules may still be SHA-1, while the

Re: Git and SHA-1 security (again)

On Tue, Jul 19, 2016 at 9:18 AM, Johannes Schindelin wrote: >> But we can recreate SHA-1 from the same content and verify GPG, right? >> I know it's super expensive, but it feels safer to not carry SHA-1 >> around when it's not secure anymore (I recall something about

Re: Git and SHA-1 security (again)

On Tue, 19 Jul 2016, Johannes Schindelin wrote: Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: I'm going to end up having to do something similar because of the issue of submodules. Submodules may still

Re: Git and SHA-1 security (again)

Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: > > I'm going to end up having to do something similar because of the issue > > of submodules. Submodules may still be SHA-1, while the main repo may > > be

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> My point is not to throw out old hashes and break signatures. My point > >> is to convert the data storage, and use mapping to resolve problems > >> with those old hashes and signatures. > > > > If you convert the data storage, then the

Re: Git and SHA-1 security (again)

Hi Duy, On Mon, 18 Jul 2016, Duy Nguyen wrote: > On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin > wrote: > > > > On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > > > >> >> I think converting is a much better option. Use a single-hash > >> >> storage, and convert

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 11:00:35AM -0700, Junio C Hamano wrote: > Continuing this thought process, I do not see a good way to allow us > to wean ourselves off of the old hash, unless we _break_ the pack > stream format so that each object in the pack carries not just the > data but also the hash

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 09:00:06AM +0200, Johannes Schindelin wrote: > Hi Brian, > > On Sun, 17 Jul 2016, brian m. carlson wrote: > > > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > > > Out of curiosity: have you considered something like padding the SHA-1s > > > with,

Re: Git and SHA-1 security (again)

>> The reality of the current situation is that it's largely mitigated in >> practice because: >> >> a) it's hard to hand someone a crafted blob to begin with for reasons >> that have nothing to do with SHA-1 (they'll go "wtf is this garbage?") >> >> b) even in that case it's *very* hard to come

Re: Git and SHA-1 security (again)

Junio C Hamano wrote: > Continuing this thought process, I do not see a good way to allow us > to wean ourselves off of the old hash, unless we _break_ the pack > stream format so that each object in the pack carries not just the > data but also the hash algorithm to be used to _name_ it, so that

Re: Git and SHA-1 security (again)

Ævar Arnfjörð Bjarmason writes: > The reality of the current situation is that it's largely mitigated in > practice because: > > a) it's hard to hand someone a crafted blob to begin with for reasons > that have nothing to do with SHA-1 (they'll go "wtf is this garbage?") > > b)

Re: Git and SHA-1 security (again)

On Mon, 18 Jul 2016, Herczeg Zsolt wrote: In particular, as far as I know and as Theodore Ts'o's post describes better than I could[1], you seem to be confusing preimage attacks with collision attacks, and then concluding that because SHA1 is vulnerable to collision attacks that use-cases that

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 7:48 PM, Herczeg Zsolt wrote: >> In particular, as far as I know and as Theodore Ts'o's post describes >> better than I could[1], you seem to be confusing preimage attacks with >> collision attacks, and then concluding that because SHA1 is vulnerable >>

Re: Git and SHA-1 security (again)

"brian m. carlson" writes: > I will say that the pack format will likely require some changes, > because it assumes ... > The reason is that we can't have an unambiguous parse of the current > objects if two hash algorithms are in use > So when we look at a new

Re: Git and SHA-1 security (again)

> In particular, as far as I know and as Theodore Ts'o's post describes > better than I could[1], you seem to be confusing preimage attacks with > collision attacks, and then concluding that because SHA1 is vulnerable > to collision attacks that use-cases that would need a preimage attack > to be

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: > I'm going to end up having to do something similar because of the issue > of submodules. Submodules may still be SHA-1, while the main repo may > be a newer hash. Or even the other way around, main repo is

Re: Git and SHA-1 security (again)

On Sat, Jul 16, 2016 at 3:48 PM, Herczeg Zsolt wrote: > I would like to discuss an old topic from 2006. I understand it was > already discussed. The only reason i'm sending this e-mail is to talk > about a possible solution which didn't show up on this list before. You mention

Re: Git and SHA-1 security (again)

Hi Johannes, >> My point is not to throw out old hashes and break signatures. My point >> is to convert the data storage, and use mapping to resolve problems >> with those old hashes and signatures. > > If you convert the data storage, then the SHA-1s listed in the commit > objects will have to

Re: Git and SHA-1 security (again)

On Mon, Jul 18, 2016 at 5:57 PM, Johannes Schindelin wrote: > Hi Zsolt, > > On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> >> I think converting is a much better option. Use a single-hash >> >> storage, and convert everything to that on import/clone/pull. >> > >> >

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > >> I think converting is a much better option. Use a single-hash > >> storage, and convert everything to that on import/clone/pull. > > > > That ignores two very important issues that I already had mentioned: > > That's not true. If you

Re: Git and SHA-1 security (again)

>> I think converting is a much better option. Use a single-hash storage, and >> convert everything to that on import/clone/pull. > > That ignores two very important issues that I already had mentioned: That's not true. If you double-check the next part of my message, you I just showed that an

Re: Git and SHA-1 security (again)

Hi Zsolt, On Mon, 18 Jul 2016, Herczeg Zsolt wrote: > I think converting is a much better option. Use a single-hash storage, and > convert everything to that on import/clone/pull. That ignores two very important issues that I already had mentioned: - existing references, both in-repository,

Re: Git and SHA-1 security (again)

Hi Brian, On Sun, 17 Jul 2016, brian m. carlson wrote: > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > > Out of curiosity: have you considered something like padding the SHA-1s > > with, say 0xa1, to the size of the new hash and using that padding to > > distinguish

Fwd: Git and SHA-1 security (again)

Do you think the multi-hash approach worth the added complexity? It'll break a lot of things. I mean almost everything. All git algorithms rely on the "same hash => same content" "same content => same hash" statements. I think converting is a much better option. Use a single-hash storage, and

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 12:23:49PM -0400, Theodore Ts'o wrote: > On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote: > > As I said, I'm not planning on multiple hash support at first, but it > > doesn't appear impossible if we go this route. We might still have to > > rewrite

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 03:42:34PM +, brian m. carlson wrote: > As I said, I'm not planning on multiple hash support at first, but it > doesn't appear impossible if we go this route. We might still have to > rewrite objects, but we can verify signatures over the legacy SHA-1 > objects by

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 05:19:02PM +0200, Duy Nguyen wrote: > On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson > wrote: > > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > >> Out of curiosity: have you considered something like padding the

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 4:21 PM, brian m. carlson wrote: > On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: >> Out of curiosity: have you considered something like padding the SHA-1s >> with, say 0xa1, to the size of the new hash and using that

Re: Git and SHA-1 security (again)

On Sun, Jul 17, 2016 at 10:01:38AM +0200, Johannes Schindelin wrote: > Out of curiosity: have you considered something like padding the SHA-1s > with, say 0xa1, to the size of the new hash and using that padding to > distinguish between old vs new hash? I'm going to end up having to do something

Re: Git and SHA-1 security (again)

Hi Brian, On Sat, 16 Jul 2016, brian m. carlson wrote: > My current plan is not to implement side-by-side data, for a couple > reasons. I am as guilty as the next person to have use the "deafbee(This is my commit, 2007-08-21)" format to refer to older commits. So I do have concerns about

Re: Git and SHA-1 security (again)

On Sat, Jul 16, 2016 at 11:46:06PM +0200, Herczeg Zsolt wrote: > Dear Brian, > > Thank you for your response. It very good to hear that changing the > hash is on the git project's list. I haven't found any official > communication on that topic since 2006. There's been some recent discussion on

Re: Git and SHA-1 security (again)

Dear Brian, Thank you for your response. It very good to hear that changing the hash is on the git project's list. I haven't found any official communication on that topic since 2006. I'll look into the contributions guide and the source codes, to check if I can contribute to this transition. If

Re: Git and SHA-1 security (again)

On Sat, Jul 16, 2016 at 03:48:49PM +0200, Herczeg Zsolt wrote: > But - and that's the main idea i'm writing here - changing the storage > keys does not mean you should drop your old hashes out. If you change > the git data structure in a way, that it can keep multiple hashes for > the same "link"

Git and SHA-1 security (again)

Dear List Members, Git Developers, I would like to discuss an old topic from 2006. I understand it was already discussed. The only reason i'm sending this e-mail is to talk about a possible solution which didn't show up on this list before. I think we all understand that SHA-1 is broken. It