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@xxxxxxxx> 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.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos