What's the impact to something like git that makes extensive use of SHA-1?
In their example they've created two PDFs with the same SHA-1. Could I replace the blob in a git repo with the "bad" version of a file if it matches the SHA-1?
In their example they've created two PDFs with the same SHA-1. Could I replace the blob in a git repo with the "bad" version of a file if it matches the SHA-1?
So what I could potentially do (given a multi-million dollar budget) is create from scratch two git repositories with different content, whose HEAD is the same. This would allow me to serve different repositories to different users.
What is currently still not feasible is to create a custom git repository whose HEAD matches that of the Linux kernel.
See also: http://crypto.stackexchange.com/questions/1173/what-are-prei...
I'm not convinced that's good enough.
In git, the SHA1 is always the hash of a gzip, which is subject to tricks[1] where a header might be prepared and then some padding inserted to collide a malicious tail.
See this commit: https://github.com/git/git/commit/d98b46f8d9a3daf965a39f8c00...
Hang on, that doesn't matter though, does it?
I was under the impression that git's SHAs were to be treated as repo-wise unique; not universally. There must non-adversarial 'collisions' across repositories already, surely?
I thought this attack potentially allows creating two commits in the same repo with the same hash - although it may only be possible for these to be root commits.
If I could downvote myself...
tl;dr it's a non-issue
Linus' answer is correct, as far as it goes, but the threats he considers are only a subset of the real problems.
Laying aside the fact that this attack isn't the one you need to attack a hit repo, and recognizing that the theoretical weakness of SHA-1 (that has been known since (IIRC) before the conception of git) has now become a practical weakness
If an attacker can forge an arbitrary part of a git tree, then if they can poison an upstream repo (we are presuming a motivated attacker given the costs involved), then they can undetectably compromise anyone downstream that clones the repo.
Linus describes in 2006 a trust model where you don't trust remote repos more than your local repo. This isn't how git is used by most users today
We should assume that nation state adversaries may have known this for a while - whether they have acted on it remains to be seen. I suspect it is unlikely for git because it is measurable after the fact (unless you contaminate every instance) I'd be more worried about signing schemes.
(Wrote previous while bathing a toddler)
edit.: they seem to quote 560k, I overlooked using both the CPUs and the GPUs.
>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 and different contents, say a benign source code and a backdoored one. An attacker could potentially selectively serve either repository to targeted users. This will require attackers to compute their own collision.
If you had seven commits, and two timestamps per commit, and each timestamp could be fudged by 90 minutes without detection, you might not need any dummy comments or files at all.