Re: SHA1 collisions found

On Fri, Mar 03, 2017 at 02:54:56PM +, Ian Jackson wrote: > > What _does_ get rewritten is what's in your ref files, your pack .idx, > > etc. Those are all sha256 (or whatever), and work as sha1's do now. > > This all sounds very similar to my proposal. Yeah, sorry I haven't reviewed that

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 11:55 AM, Linus Torvalds wrote: > > So: What do you think about the concept? > >Linus One of the things I like about working on Git is its pretty high standard of testing. So we would need to come up with good methods of

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 11:55:45AM -0800, Linus Torvalds wrote: > Anyway, I do have a suggestion for what the "object version" would be, > but I'm not even going to mention it, because I want people to first > think about the _concept_ and not the implementation. > > So: What do you think about

Re: SHA1 collisions found

Jeff King writes ("Re: SHA1 collisions found"): > I think you've read more into my "conversion" than I intended. The old > history won't get rewritten. It will just be grafted onto the bottom of > the commit history you've got, and the new trees will all be written >

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 01:46:10PM -0800, Brandon Williams wrote: > There were a few of us discussing this sort of approach internally. We > also figured that, given some performance hit, you could maintain your > repo in sha256 and do some translation to sha1 if you need to push or > fetch to a

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 5:50 PM, Mike Hommey wrote: > > What if the "object version" is a hash of the content (as opposed to > header + content like the normal git hash)? It doesn't actually matter for that attack. The concept of the attack is actually fairly simple: generate

Re: SHA1 collisions found

On Thu, Mar 02, 2017 at 02:27:15PM -0800, Linus Torvalds wrote: > On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote: > > > > There's a surprising result of combining iterated hash functions, that > > the combination is no more difficult to attack than the strongest hash > >

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 12:43 PM, Junio C Hamano wrote: > > My reaction heavily depends on how that "object version" thing > works. > > Would "object version" be like a truncated SHA-1 over the same data > but with different IV or something, i.e. something that guarantees >

Re: SHA1 collisions found

On 02/26, Jeff King wrote: > On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote: > > > On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > > > I was thinking we would need mixed mode support for smoother > > > transition, but it now seems to me that the approach to

Re: SHA1 collisions found

Linus Torvalds wrote: > So you'd have to be able to attack both the full SHA1, _and_ whatever > other different good hash to 128 bits. There's a surprising result of combining iterated hash functions, that the combination is no more difficult to attack than the strongest hash function used.

Re: SHA1 collisions found

On Thu, Mar 2, 2017 at 1:54 PM, Joey Hess wrote: > > There's a surprising result of combining iterated hash functions, that > the combination is no more difficult to attack than the strongest hash > function used. Duh. I should actually have known that. I started reading the

Re: SHA1 collisions found

Linus Torvalds writes: > Anyway, I do have a suggestion for what the "object version" would be, > but I'm not even going to mention it, because I want people to first > think about the _concept_ and not the implementation. > > So: What do you think about the

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds wrote: > > Honestly, I think that a primary goal for a new hash implementation > absolutely needs to be to minimize mixing. > > Not for security issues, but because of combinatorics. You want to > have a model that

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 03:11:32PM -0800, Linus Torvalds wrote: > > Of course for dedicated code this can be simplified, and some parts > > could be further optimized. > > So I'd be worried about changing your tested code too much, since the > only test-cases we have are the two pdf files. If we

RE: SHA1 collisions found

> - Dan timed the sha1dc implementation with and without the collision > detection enabled. The sha1 implementation is only 1.33x slower than >block-sha1 (for raw sha1 time). Adding in the detection makes it >2.6x slower. >So there's some potential gain from optimizing the sha1

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 2:50 PM, Marc Stevens wrote: > > Because we only have 32 disturbance vectors to check, we have DVMASKSIZE > equal to 1 and maski always 0. > In the more general case when we add disturbance vectors this will not > remain the case. Ok, I didn't get why

Re: SHA1 collisions found

Behalf Of Linus > Torvalds > Sent: Tuesday, February 28, 2017 11:34 AM > To: Junio C Hamano <gits...@pobox.com> > Cc: Jeff King <p...@peff.net>; Joey Hess <i...@joeyh.name>; Git Mailing List > <git@vger.kernel.org> > Subject: Re: SHA1 collisions found >

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:52 AM, Shawn Pearce wrote: > >> and from what I can tell, the 'maski' value is always 0, so the >> looping over 80 state masks is really just a loop over two. > > Actually, look closer at that loop: No, sorry, I wasn't clear and took some shortcuts

RE: SHA1 collisions found

o:linus...@gmail.com] On Behalf Of Linus Torvalds Sent: Tuesday, February 28, 2017 11:34 AM To: Junio C Hamano <gits...@pobox.com> Cc: Jeff King <p...@peff.net>; Joey Hess <i...@joeyh.name>; Git Mailing List <git@vger.kernel.org> Subject: Re: SHA1 collisions found On Tue, Fe

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:34 AM, Linus Torvalds wrote: > On Tue, Feb 28, 2017 at 11:07 AM, Junio C Hamano wrote: >> >> In a way similar to 8415558f55 ("sha1dc: avoid c99 >> declaration-after-statement", 2017-02-24), we would want this on >> top.

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:07 AM, Junio C Hamano wrote: > > In a way similar to 8415558f55 ("sha1dc: avoid c99 > declaration-after-statement", 2017-02-24), we would want this on > top. There's a few other simplifications that could be done: (1) make the symbols static that

Re: SHA1 collisions found

Junio C Hamano writes: >> [1/3]: add collision-detecting sha1 implementation >> [2/3]: sha1dc: adjust header includes for git >> [3/3]: Makefile: add USE_SHA1DC knob > > I was lazy so I fetched the above and then added this on top before > I start to play with it. > > --

Re: SHA1 collisions found

On Tue, Feb 28, 2017 at 11:07:37AM -0800, Junio C Hamano wrote: > Junio C Hamano writes: > > >> [1/3]: add collision-detecting sha1 implementation > >> [2/3]: sha1dc: adjust header includes for git > >> [3/3]: Makefile: add USE_SHA1DC knob > > > > I was lazy so I

Re: SHA1 collisions found

Jeff King writes: > The first one is 98K. Mail headers may bump it over vger's 100K barrier. > It's actually the _least_ interesting patch of the 3, because it just > imports the code wholesale from the other project. But if it doesn't > make it, you can fetch the whole series

Re: SHA1 collisions found

On Mon, Feb 27, 2017 at 02:29:18PM +0100, René Scharfe wrote: > Am 25.02.2017 um 20:04 schrieb brian m. carlson: > >>> So I think that the current scope left is best estimated by the > >>> following command: > >>> > >>> git grep -P 'unsigned char\s+(\*|.*20)' | grep -v '^Documentation' > >>> >

Re: SHA1 collisions found

Am 25.02.2017 um 20:04 schrieb brian m. carlson: >>> So I think that the current scope left is best estimated by the >>> following command: >>> >>> git grep -P 'unsigned char\s+(\*|.*20)' | grep -v '^Documentation' >>> >>> So there are approximately 1200 call sites left, which is quite a bit of

Re: SHA1 collisions found

Just swap in md5 in place of sha1. Pad with '0'. That'll give you all the collisions you want and none of those you don't want. On Mon, Feb 27, 2017 at 5:43 AM, Jeff King wrote: > On Mon, Feb 27, 2017 at 10:57:37AM +0100, Geert Uytterhoeven wrote: > >> > Yeah, that is a lot more

Re: SHA1 collisions found

On Mon, Feb 27, 2017 at 10:57:37AM +0100, Geert Uytterhoeven wrote: > > Yeah, that is a lot more flexible for experimenting. Though I'd think > > you'd probably want more than 4 bits just to avoid accidental > > collisions. Something like 24 bits gives you some breathing space (you'd > > expect a

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 10:30 PM, Jeff King wrote: > On Sun, Feb 26, 2017 at 07:57:19PM +0100, Thomas Braun wrote: >> While reading about the subject I came across [1]. The author reduced >> the hash size to 4bits and then played around with git. >> >> Diff taken from the posting

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 10:38:35PM +0100, Ævar Arnfjörð Bjarmason wrote: > On Sun, Feb 26, 2017 at 8:11 PM, Linus Torvalds > wrote: > > But yes, SHA3-256 looks like the sane choice. Performance of hashing > > is important in the sense that it shouldn't _suck_, but

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 8:11 PM, Linus Torvalds wrote: > But yes, SHA3-256 looks like the sane choice. Performance of hashing > is important in the sense that it shouldn't _suck_, but is largely > secondary. All my profiles on real loads (well, *my* real loads) have

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 07:57:19PM +0100, Thomas Braun wrote: > While reading about the subject I came across [1]. The author reduced > the hash size to 4bits and then played around with git. > > Diff taken from the posting (not my code) > --- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c >

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 9:38 AM, brian m. carlson wrote: > > SHA-256: > Common, but cryptanalysis has advanced. Preimage resistance (which is > even more important than collision resistance) has gotten to 52 of 64 > rounds. Pseudo-collision attacks are

Re: SHA1 collisions found

Am 25.02.2017 um 00:06 schrieb Jeff King: > So we don't actually know how Git would behave in the face of a SHA-1 > collision. It would be pretty easy to simulate it with something like: > > --- > diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c > index 22b125cf8..1be5b5ba3 100644 > ---

Re: SHA1 collisions found

Jeff King writes: > Trees are more difficult, as they don't have any such field. But a valid > tree does need to start with a mode, so sticking some non-numeric flag > at the front of the object would work (it breaks backwards > compatibility, but that's kind of the point). Just

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 12:18:34AM -0500, Jeff King wrote: > On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote: > > > On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > > > I was thinking we would need mixed mode support for smoother > > > transition, but it now seems to

Re: SHA1 collisions found

Jeff King writes: > On Sat, Feb 25, 2017 at 11:35:27PM +0100, Lars Schneider wrote: > ... >> That's a good idea! I wonder if it would make sense to setup an >> additional job in TravisCI that patches every Git version with some hash >> collisions and then runs special tests. > >

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 12:16:07AM +, Jason Cooper wrote: > Hi, > > On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote: > > That is why I believe that some HASH (e.g. SHA-3) must be the blessed one. > > All git >= 3.x.x must support at least this one (for naming and > >

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 07:09:44AM +0900, Mike Hommey wrote: > On Sat, Feb 25, 2017 at 02:26:56PM -0500, Jeff King wrote: > > I looked at that earlier, because I think it's a reasonable idea for > > future-proofing. The first byte is a "varint", but I couldn't find where > > they defined that

Re: SHA1 collisions found

On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote: > On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > > I was thinking we would need mixed mode support for smoother > > transition, but it now seems to me that the approach to stratify the > > history into old and new is

Re: SHA1 collisions found

Hi Junio, On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote: > I was thinking we would need mixed mode support for smoother > transition, but it now seems to me that the approach to stratify the > history into old and new is workable. As someone looking to deploy (and having

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 11:35:27PM +0100, Lars Schneider wrote: > > So we don't actually know how Git would behave in the face of a SHA-1 > > collision. It would be pretty easy to simulate it with something like: > [...] > > That's a good idea! I wonder if it would make sense to setup an >

Re: SHA1 collisions found

Hi, On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote: > That is why I believe that some HASH (e.g. SHA-3) must be the blessed one. > All git >= 3.x.x must support at least this one (for naming and > cross-referencing between objects). I would stress caution here. SHA3 has survived the

Re: SHA1 collisions found

On 24 February 2017 at 18:23, Jason Cooper wrote: > Hi Ian, > > On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote: >> Joey Hess writes ("SHA1 collisions found"): >> > https://shattered.io/static/shattered.pdf >> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/

Re: SHA1 collisions found

> On 25 Feb 2017, at 00:06, Jeff King wrote: > > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > >> I have just read on ArsTechnica[1] that while Git repository could be >> corrupted (though this would require attackers to spend great amount >> of resources

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 02:26:56PM -0500, Jeff King wrote: > On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote: > > > > As long as the reader can tell from the format of object names > > > stored in the "new object format" object from what era is being > > > referred to in some way

Re: SHA1 collisions found

On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote: > > As long as the reader can tell from the format of object names > > stored in the "new object format" object from what era is being > > referred to in some way [*1*], we can name new objects with only new > > hash, I would

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 04:42:38PM +0700, Duy Nguyen wrote: > On Thu, Feb 23, 2017 at 11:43 PM, Joey Hess wrote: > > IIRC someone has been working on parameterizing git's SHA1 assumptions > > so a repository could eventually use a more secure hash. How far has > > that gotten?

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote: > Ian Jackson writes: > > > I have been thinking about how to do a transition from SHA1 to another > > hash function. > > Good. I think many of us have also been, too, not necessarily just > in the

Re: SHA1 collisions found

Linus Torvalds writes: > For example, what I would suggest the rules be is something like this: > > - introduce new tag2/commit2/tree2/blob2 object type tags that imply > that they were hashed using the new hash > > - an old type obviously can never contain a

Re: SHA1 collisions found

Repos should address keeping / 'fixing' broken sha-1 as needed. They also really need to create new native modes so users can initialize and use repos with (sha-3 / sha-256 / whatever) going forward. Backward compatibility with sha-1 or 'fixed sha-1' will be fine. Clients can 'taste' and 'test'

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:39 PM, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > >>> what if they are forks of each other? (LEDE and OpenWRT, or just >>> linux-kernel and linux-kernel-stable) >> >> >> Once one flips, the other one needs to flip to, or can't interact

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:21 PM, Jeff King wrote: > On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote: > >> On Fri, 24 Feb 2017, Jeff King wrote: >> >> > >> > So I'd much rather see strong rules like: >> > >> > 1. Once a repo has flag-day switched over to the new hash

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: OpenWRT/LEDE have their core repo, and they pull from many other (unrelated) projects into that repo (and then have 'feeds', which is sort-of-like-submodules to pull in other software that's maintained completely independently) I think with submodules

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 05:39:43PM -0800, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > > > > what if they are forks of each other? (LEDE and OpenWRT, or just > > > linux-kernel and linux-kernel-stable) > > > > Once one flips, the other one needs to flip to, or can't interact with

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: what if they are forks of each other? (LEDE and OpenWRT, or just linux-kernel and linux-kernel-stable) Once one flips, the other one needs to flip to, or can't interact with them. I know that's harsh, and is likely to create headaches. But in the long

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 05:00:55PM -0800, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > > > > > So I'd much rather see strong rules like: > > > > 1. Once a repo has flag-day switched over to the new hash format[1], > > new references are _always_ done with the new hash. Even

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 04:39:45PM -0800, Linus Torvalds wrote: > For example, what I would suggest the rules be is something like this: > > - introduce new tag2/commit2/tree2/blob2 object type tags that imply > that they were hashed using the new hash > > - an old type obviously can never

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 5:00 PM, David Lang wrote: > On Fri, 24 Feb 2017, Jeff King wrote: > >> >> So I'd much rather see strong rules like: >> >> 1. Once a repo has flag-day switched over to the new hash format[1], >> new references are _always_ done with the new hash. Even

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Jeff King wrote: So I'd much rather see strong rules like: 1. Once a repo has flag-day switched over to the new hash format[1], new references are _always_ done with the new hash. Even ones that point to pre-flag-day objects! how do you define when a repo has

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 4:39 PM, Linus Torvalds wrote: > > - you'd see in the "object->type" whether it's a new or old-style hash. Actually, I take that back. I think it might be easier to keep "object->type" as-is, and it would only show the current OBJ_xyz

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 3:39 PM, Jeff King wrote: > > One thing I worry about in a mixed-hash setting is how often the two > will be mixed. Honestly, I think that a primary goal for a new hash implementation absolutely needs to be to minimize mixing. Not for security issues, but

Re: SHA1 collisions found

On 24 February 2017 at 21:32, Junio C Hamano wrote: > ankostis writes: > >> Let's assume that git is retroffited to always support the "default" >> SHA-3, but support additionally more hash-funcs. >> If in the future SHA-3 also gets defeated, it would be

Re: SHA1 collisions found

Ian Jackson writes ("Re: SHA1 collisions found"): > The idea of using the length is a neat trick, but it cannot support > the dcurrent object name abbreviation approach unworkable. Sorry, it's late here and my grammar seems to have disintegrated ! Ian.

Re: SHA1 collisions found

Junio C Hamano writes ("Re: SHA1 collisions found"): > Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > > * Therefore the transition needs to be done by giving every object > >two names (old and new hash function). Objects may refer to each > >

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote: > > * Therefore the transition needs to be done by giving every object > >two names (old and new hash function). Objects may refer to each > >other by either name, but must pick one. The usual shape of > > I do not think

Re: SHA1 collisions found

W dniu 25.02.2017 o 00:06, Jeff King pisze: > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > >> I have just read on ArsTechnica[1] that while Git repository could be >> corrupted (though this would require attackers to spend great amount >> of resources creating their own

Re: SHA1 collisions found

On 2017-02-25 00:05:34, Jakub Narębski wrote: > W dniu 24.02.2017 o 23:53, Santiago Torres pisze: > > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > > > I have just read on ArsTechnica[1] that while Git repository could > > > be corrupted (though this would require attackers to

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > I have just read on ArsTechnica[1] that while Git repository could be > corrupted (though this would require attackers to spend great amount > of resources creating their own collision, while as said elsewhere > in this thread

Re: SHA1 collisions found

W dniu 24.02.2017 o 23:53, Santiago Torres pisze: > On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: >> >> I have just read on ArsTechnica[1] that while Git repository could be >> corrupted (though this would require attackers to spend great amount >> of resources creating their own

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote: > I have just read on ArsTechnica[1] that while Git repository could be > corrupted (though this would require attackers to spend great amount > of resources creating their own collision, while as said elsewhere > in this thread

Re: SHA1 collisions found

I have just read on ArsTechnica[1] that while Git repository could be corrupted (though this would require attackers to spend great amount of resources creating their own collision, while as said elsewhere in this thread allegedly easy to detect), putting two proof-of-concept different PDFs with

Re: SHA1 collisions found

From: "Stefan Beller" On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: you are inviting people to start using md5,54ddf8d47340e048166c45f439ce65fd as object names. which might even be okay for specific subsets of operations. (e.g. all

Re: SHA1 collisions found

ankostis writes: > Let's assume that git is retroffited to always support the "default" > SHA-3, but support additionally more hash-funcs. > If in the future SHA-3 also gets defeated, it would be highly unlikely > that the same math would also break e.g. Blake. > So certain

Re: SHA1 collisions found

On 24 February 2017 at 20:20, Junio C Hamano wrote: > Stefan Beller writes: > >> On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: >> >>> you are inviting people to start using >>> >>> md5,54ddf8d47340e048166c45f439ce65fd >>>

Re: SHA1 collisions found

Junio C Hamano writes: > The not-so-well-hidden agenda was exactly that we _SHOULD_ not > mimick PGP. They do not have a requirement to encourage everybody > to use the same thing because each message is encrypted/signed > independently, i.e. they do not have to chain things

Re: SHA1 collisions found

Stefan Beller writes: > On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: > >> you are inviting people to start using >> >> md5,54ddf8d47340e048166c45f439ce65fd >> >> as object names. > > which might even be okay for specific subsets of

Re: SHA1 collisions found

On Fri, Feb 24, 2017 at 10:14 AM, Junio C Hamano wrote: > you are inviting people to start using > > md5,54ddf8d47340e048166c45f439ce65fd > > as object names. which might even be okay for specific subsets of operations. (e.g. all local work including staging things,

Re: SHA1 collisions found

David Lang writes: > On Fri, 24 Feb 2017, Junio C Hamano wrote: > >> *1* In the above toy example, length being 40 vs 64 is used as a >>sign between SHA-1 and the new hash, and careful readers may >>wonder if we should use sha-3,20769079d22... or something like >>that

Re: SHA1 collisions found

On Fri, 24 Feb 2017, Junio C Hamano wrote: *1* In the above toy example, length being 40 vs 64 is used as a sign between SHA-1 and the new hash, and careful readers may wonder if we should use sha-3,20769079d22... or something like that that more explicity identifies what hash is used,

Re: SHA1 collisions found

Hi Ian, On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote: > Joey Hess writes ("SHA1 collisions found"): > > https://shattered.io/static/shattered.pdf > > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ > > > > IIRC someone has been working on parameterizing git's SHA1 assumptions

Re: SHA1 collisions found

Ian Jackson writes: > I have been thinking about how to do a transition from SHA1 to another > hash function. Good. I think many of us have also been, too, not necessarily just in the past few days in response to shattered, but over the last 10 years, yet

Re: SHA1 collisions found

On 24 February 2017 at 16:13, Ian Jackson wrote: > > Joey Hess writes ("SHA1 collisions found"): > > https://shattered.io/static/shattered.pdf > > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ > > > > IIRC someone has been working on parameterizing git's

Re: SHA1 collisions found

Joey Hess writes ("SHA1 collisions found"): > https://shattered.io/static/shattered.pdf > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/ > > IIRC someone has been working on parameterizing git's SHA1 assumptions > so a repository could eventually use a more secure hash. How far has > that

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 8:13 PM, Morten Welinder wrote: > The attack seems to generate two 64-bytes blocks, one quarter of which > is repeated data. (Table-1 in the paper.) > > Assuming the result of that is evenly distributed and that bytes are > independent, we can

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 11:43 PM, Joey Hess wrote: > IIRC someone has been working on parameterizing git's SHA1 assumptions > so a repository could eventually use a more secure hash. How far has > that gotten? There are still many "40" constants in git.git HEAD. Michael asked

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 3:05 PM, Jeff King wrote: > > (By the way, I don't see your version on the list, Linus, which probably > means it was eaten by the 100K filter). Ahh. I didn't even think about a size filter. Doesn't matter, your version looks fine. Linus

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 05:43:02PM -0500, Jeff King wrote: > On Thu, Feb 23, 2017 at 02:38:29PM -0800, Linus Torvalds wrote: > > > > Thanks, I hadn't seen that yet. That doesn't look like it should be hard > > > to integrate into Git. > > > > Here's a *very* ugly patch that is absolutely

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 2:43 PM, Jeff King wrote: > > Yeah. I started looking at that, but the ubc check happens after the > initial expansion. Yes. That's the point where I gave up and just included their ugly sha1.c file. I suspect it can be done, but it would need somebody to

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 02:38:29PM -0800, Linus Torvalds wrote: > > Thanks, I hadn't seen that yet. That doesn't look like it should be hard > > to integrate into Git. > > Here's a *very* ugly patch that is absolutely disgusting and should not be > used. But it does kind of work (I tested it

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 09:49:09PM +0100, Jakub Narębski wrote: > > How is GIT affected? GIT strongly relies on SHA-1 for the > > identification and integrity checking of all file objects and > > commits. It is essentially possible to create two GIT repositories > > with the same head commit hash

Re: SHA1 collisions found

Jeff King wrote: > It's not an identical prefix, but I think collision attacks generally > are along the lines of selecting two prefixes followed by garbage, and > then mutating the garbage on both sides. That would "work" in this case > (modulo the fact that git would complain about the NUL). >

Re: SHA1 collisions found

W dniu 23.02.2017 o 18:12, David Lang pisze: > On Thu, 23 Feb 2017, Junio C Hamano wrote: > >> On Thu, Feb 23, 2017 at 8:43 AM, Joey Hess wrote: >>> >>> Since we now have collisions in valid PDF files, collisions in >>> valid git commit and tree objects are probably able to be

Re: SHA1 collisions found

On 2017-02-23 11:09:32, Linus Torvalds wrote: > I'm aware of the fsck checks, but I have to admit I wasn't aware of > 'transfer.fsckobjects'. I should turn that on myself. > > Or maybe git should just turn it on by default? The problem with this is that there are many repos with errors out

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 11:09:32AM -0800, Linus Torvalds wrote: > On Thu, Feb 23, 2017 at 10:46 AM, Jeff King wrote: > >> > >> So I agree with you that we need to make git check for the opaque > >> data. I think I was the one who brought that whole argument up. > > > > We do

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 11:47:16AM -0800, Linus Torvalds wrote: > On Thu, Feb 23, 2017 at 11:32 AM, Jeff King wrote: > > > > Yeah, they're not expensive. We've discussed enabling them by default. > > The sticking point is that there is old history with minor bugs which > >

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 11:32 AM, Jeff King wrote: > > Yeah, they're not expensive. We've discussed enabling them by default. > The sticking point is that there is old history with minor bugs which > triggers some warnings (e.g., malformed committer names), and it would > be

Re: SHA1 collisions found

pointers to a little more info https://shattered.it/static/ the two files are: https://shattered.it/static/shattered-1.pdf https://shattered.it/static/shattered-2.pdf 422435 shattered-2.pdf 422435 shattered-1.pdf identical length and a lot smaller than I expected (~162K of the 413K file is

Re: SHA1 collisions found

The attack seems to generate two 64-bytes blocks, one quarter of which is repeated data. (Table-1 in the paper.) Assuming the result of that is evenly distributed and that bytes are independent, we can estimate the chances that the result is NUL-free as (255/256)^192 = 47% and the probability

Re: SHA1 collisions found

On Thu, Feb 23, 2017 at 10:46 AM, Jeff King wrote: >> >> So I agree with you that we need to make git check for the opaque >> data. I think I was the one who brought that whole argument up. > > We do already. I'm aware of the fsck checks, but I have to admit I wasn't aware of

  1   2   >