{"thread":{"id":"19302","subject":"Supporting hashes other than SHA-1","startedAt":"2009-05-11T19:52:42Z","lastAt":"2009-05-12T14:06:17Z","messageCount":5,"participants":["Chris Frey","Jakub Narebski","Andreas Ericsson","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"113582","messageId":"20090511195242.GA14756@foursquare.net","threadId":"19302","inReplyTo":null,"subject":"Supporting hashes other than SHA-1","fromName":"Chris Frey","fromEmail":"cdfrey@foursquare.net","sentAt":"2009-05-11T19:52:42Z","receivedAt":"2009-05-11T19:52:42Z","isPatch":false,"sender":{"key":"cdfrey@foursquare.net","avatar":null},"body":"Hi,\n\nConsidering the recent news regarding SHA-1's newly found weaknesses,\nis there any general interest in making git flexible enough to support\nother hashes in the future?\n\n- Chris\n"},{"id":"113588","messageId":"m3zldjl5bq.fsf@localhost.localdomain","threadId":"19302","inReplyTo":"20090511195242.GA14756@foursquare.net","subject":"Re: Supporting hashes other than SHA-1","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-11T21:04:11Z","receivedAt":"2009-05-11T21:04:11Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Chris Frey writes:\n\n> Considering the recent news regarding SHA-1's newly found weaknesses,\n> is there any general interest in making git flexible enough to support\n> other hashes in the future?\n\nFirst, there isn't as far as I know any 'known preimage' attack\nagainst SHA-1, and only that would truly matter for Git.\n\nSecond, this issue was discussed in depth in the past; check git\nmailing list archives, please...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"113631","messageId":"m3vdo6lbuy.fsf@localhost.localdomain","threadId":"19302","inReplyTo":"m3zldjl5bq.fsf@localhost.localdomain","subject":"Re: Supporting hashes other than SHA-1","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-05-12T12:55:43Z","receivedAt":"2009-05-12T12:55:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jakub Narebski writes:\n\n> Chris Frey writes:\n> \n> > Considering the recent news regarding SHA-1's newly found weaknesses,\n> > is there any general interest in making git flexible enough to support\n> > other hashes in the future?\n> \n> First, there isn't as far as I know any 'known preimage' attack\n> against SHA-1, and only that would truly matter for Git.\n> \n> Second, this issue was discussed in depth in the past; check git\n> mailing list archives, please...\n\nSee also this blog entry (and comments):\n http://kitenet.net/~joey/blog/entry/sha-1/\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"113635","messageId":"4A0980C8.7060106@op5.se","threadId":"19302","inReplyTo":"m3vdo6lbuy.fsf@localhost.localdomain","subject":"Re: Supporting hashes other than SHA-1","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-05-12T13:59:36Z","receivedAt":"2009-05-12T13:59:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Jakub Narebski writes:\n> \n>> Chris Frey writes:\n>>\n>>> Considering the recent news regarding SHA-1's newly found weaknesses,\n>>> is there any general interest in making git flexible enough to support\n>>> other hashes in the future?\n>> First, there isn't as far as I know any 'known preimage' attack\n>> against SHA-1, and only that would truly matter for Git.\n>>\n>> Second, this issue was discussed in depth in the past; check git\n>> mailing list archives, please...\n> \n> See also this blog entry (and comments):\n> http://kitenet.net/~joey/blog/entry/sha-1/\n> \n\nIt's a bit harder than that, since both pre-images have to be the same\nsize. Git does this when hashing an object to the database:\n\nstatic void write_sha1_file_prepare(const void *buf, unsigned long len,\n const char *type, unsigned char *sha1,\n char *hdr, int *hdrlen)\n{\n git_SHA_CTX c;\n\n /* Generate the header */\n *hdrlen = sprintf(hdr, \"%s %lu\", type, len)+1;\n\n /* Sha1.. */\n git_SHA1_Init(&c);\n git_SHA1_Update(&c, hdr, *hdrlen);\n git_SHA1_Update(&c, buf, len);\n git_SHA1_Final(sha1, &c);\n}\n\nIow, the type and, more importantly, *size* of the object is added to\nthe hash. AFAIK, the pre-image conflict generators all rely on being\nable to manipulate the size of the content it's creating hashes for.\nI don't know how hard that would be to change, so perhaps someone else\ncan enlighten me.\n\nI'm not exactly overwhelmed by the attack vectors Joey describes either.\nFirst of all, it's rather trivial to add a check to git to make it\ndecompress its own internal object when it receives a conflicting hash\nand then check the type, size and content of both objects and alert a\nuser if there is a mismatch somewhere. It wouldn't even burn that much\nCPU, since conflicts are extremely rare without malevolent intervention.\nThat would defeat the first scenario by alerting users rather promptly.\n\nThe second scenario can't really be prevented, but unless Alice is\nreally a server-admin on the server hosting the repository, she will\nleave traces in the ssh-logs. It also relies on the build-server being\nutterly stupid by re-cloning the entire project.\n\nNeither case is exactly foolproof. Both have a high risk of exposure.\nA far better and simpler thing to do (if one were so inclined) would\nbe to just add whatever malicious code one wants but make it appear as\nif it was added in a patch-series from someone else and then hope\nnoone notices until it's too late. Far less risk for the same gains.\n\nAs both vectors outlined by Joey require a lot of community trust, I'm\nnot particularly worried.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nRegister now for Nordic Meet on Nagios, June 3-4 in Stockholm\n http://nordicmeetonnagios.op5.org/\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"113636","messageId":"alpine.DEB.1.00.0905121604560.4447@intel-tinevez-2-302","threadId":"19302","inReplyTo":"4A0980C8.7060106@op5.se","subject":"Re: Supporting hashes other than SHA-1","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-05-12T14:06:17Z","receivedAt":"2009-05-12T14:06:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 12 May 2009, Andreas Ericsson wrote:\n\n> Jakub Narebski wrote:\n> > Jakub Narebski writes:\n> > \n> > > Chris Frey writes:\n> > >\n> > > > Considering the recent news regarding SHA-1's newly found weaknesses,\n> > > > is there any general interest in making git flexible enough to support\n> > > > other hashes in the future?\n> > > First, there isn't as far as I know any 'known preimage' attack\n> > > against SHA-1, and only that would truly matter for Git.\n> > >\n> > > Second, this issue was discussed in depth in the past; check git\n> > > mailing list archives, please...\n> > \n> > See also this blog entry (and comments):\n> > http://kitenet.net/~joey/blog/entry/sha-1/\n> > \n> \n> It's a bit harder than that, since both pre-images have to be the same\n> size.\n\nThey don't. The pre-images prefixed by the type identifier and the size \nin ASCII need to have the same hash. There is a difference.\n\nCiao,\nDscho\n"}]}