On 02/23/2017 01:03 PM, Lamar Owen wrote: > On 02/23/2017 03:32 PM, James Hogarth wrote: >> On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote: >>> Not to stir up a hornets' nest, but how does Google's announcement at >>> https://shattered.it affect this now? (Executive summary: Google has >>> successfully produced two different PDF files that hash to the same >>> SHA-1.) >>> There is a whole paragraph on 'How is GIT affected?' >> To stave off another ridiculous thread - short version is simply "it >> isn't" >> > Ridiculous? Seriously? I don't think it's time to be in panic mode, > but it is time to prepare for the generation-after-next of GPUs which > will be able to produce SHA-1 collisions quickly enough to be able to > keep up with a git repo. > > Dan Goodin disagrees that it's not a problem for git in the long run. > See: > https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/ > (not a bit of hyperbole in that headline, right? ) Maybe it's a bit > premature to call it 'dead' but it is definitely in its death rattles. > > Google is scheduled to release the source code to produce arbitrary > "identical-prefix" collisions of SHA-1 hashes in three months. You need > about $110,000 worth of compute time to pull off the attack, and that > number will go down. We're basically at the same place now with SHA-1 > as we were in 2010 with MD5. > > The full paper can be read at https://shattered.io/static/shattered.pdf > > And an interesting discussion on git's potential handling of a SHA-1 > collision on a blob is at > https://stackoverflow.com/questions/9392365/how-would-git-handle-a-sha-1-collision-on-a-blob > > > It may not be urgent, but it's not ridiculous. > I think the issue is that you not only have to create a trojan file that matches the same hash, but you have to create a trojan file that matches the same hash and doesn't break compiling. Maybe you could do that by padding the file in a comment, but I suspect it would be extremely difficult to pull off. Bottom line is git needs to move to sha256 but I do not believe there is any present danger. I'd be more worried about fraudulently issued TLS certs combined with a DNS cache attack when doing a git checkout. That would be easier to easier to pull off.