On Sat, Aug 15, 2015 at 7:24 AM, hasufell <hasuf...@gentoo.org> wrote: > > No one has proven that git is cryptographically insecure. Everyone > claiming that probably refers to > https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html and > the fact that we don't sign blob objects. > > While that is something git upstream has to fix, all known SHA1 > "attacks" are NOT "preimage attacks". So the whole point is utterly and > mathematically moot for us in practice. This is wasting our time. >
I'd take a few issues with your wording, but not with your argument as it applies to Gentoo. Whether a collision attack or a preimage attack is necessary to make something insecure depends on how the hash is being used. In the case of Gentoo the author is the signer, so a collision attack doesn't really mean much. If the signer wanted to sign something different, they would just do it. In another workflow where the where the signer is somebody other than the author, then a collision attack might be meaningful, even in the absence of a preimage attack. That is, as the author I can use a collision attack to generate two git trees with the same hash. One is a tree you would be willing to sign off on, and the other is one that you would be unwilling to sign off on. After obtaining your signature I could keep your commit object and swap out the tree resulting in a repo that has your signature but what you signed off on is not what is in the repo. You could see how in some code-review scenarios that might be relevant (only if the submitted tree is signed unmodified - any rebasing could break this, and even a merge could break it[1]). On the other hand, in the author-is-signer workflow of Gentoo it isn't very relevant, since if I want to stick something nasty in the tree I can just do it. Overall, though, sha1's days are numbered. I don't think that is a reason to make an inconvenient change in our workflow just now. However, it really is the sort of thing the git maintainers should be thinking about and at least planning for. This also brings up the issue of unstated assumptions made by development teams. They use a tool which has some cryptographic weakness, based on the argument that the weakness is not a problem for their intended use. Then when somebody else comes along and uses the application in a manner not originally intended or conceived of by the authors, the weakness compromises the security of the application, perhaps in a way the users aren't aware of. Then when the problem is exploited and publicized everybody gets to argue about whose fault it is. Footnotes: 1 - ...though if you could be reasonably sure that other commits being rebased/merged wouldn't touch the part of the tree you're messing with you could do a collision on a tree object below the root and not on the root itself. As long as no other commits before the merge mess with the part of the tree you're playing games with you could swap out just that part of the tree if you could do a collision attack and then both the merge and your own commit will inherit the changes. -- Rich
