{"thread":{"id":"11418","subject":"NIST's policy: sha-1 until 2010, after 2010 sha-2.","startedAt":"2007-12-29T04:27:02Z","lastAt":"2007-12-29T05:07:12Z","messageCount":3,"participants":["J.C. Pizarro","David Symonds","David Brown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"64168","messageId":"998d0e4a0712282027y6e625141jcef90bd38fb83b75@mail.gmail.com","threadId":"11418","inReplyTo":null,"subject":"NIST's policy: sha-1 until 2010, after 2010 sha-2.","fromName":"J.C. Pizarro","fromEmail":"jcpiza@gmail.com","sentAt":"2007-12-29T04:27:02Z","receivedAt":"2007-12-29T04:27:02Z","isPatch":false,"sender":{"key":"jcpiza@gmail.com","avatar":null},"body":"Dear Linus Torvalds,\n\nWhat do you think to do when your git has to change from SHA-1 to SHA-2\n because of the weaker collision-resistance of SHA-1 in the next years?\n\n (e.g. from an damn developer trying to commit a collisioned-SHA-1 file)\n\nhttp://csrc.nist.gov/groups/ST/hash/policy.html says\n\nNIST's Policy on Hash Functions\n-------------------------------\nMarch 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224,\nSHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all\napplications using secure hash algorithms. Federal agencies should\nstop using SHA-1 for digital signatures, digital time stamping and\nother applications that require collision resistance as soon as\npractical, and must use the SHA-2 family of hash functions for these\napplications after 2010. After 2010, Federal agencies may use SHA-1\nonly for the following applications: hash-based message authentication\ncodes (HMACs); key derivation functions (KDFs); and random number\ngenerators (RNGs). Regardless of use, NIST encourages application and\nprotocol designers to use the SHA-2 family of hash functions for all\nnew applications and protocols.\n"},{"id":"64169","messageId":"ee77f5c20712282045ha230f42n3e68477229deb199@mail.gmail.com","threadId":"11418","inReplyTo":"998d0e4a0712282027y6e625141jcef90bd38fb83b75@mail.gmail.com","subject":"Re: NIST's policy: sha-1 until 2010, after 2010 sha-2.","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2007-12-29T04:45:35Z","receivedAt":"2007-12-29T04:45:35Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Dec 29, 2007 3:27 PM, J.C. Pizarro wrote:\n> Dear Linus Torvalds,\n>\n> What do you think to do when your git has to change from SHA-1 to SHA-2\n> because of the weaker collision-resistance of SHA-1 in the next years?\n>\n> (e.g. from an damn developer trying to commit a collisioned-SHA-1 file)\n\nIt's a non-issue. The closest-to-practical attack method on SHA-1 is a\ncollision-finding attack, not a second pre-image attack, which means\nyou can find two messages with the same hash. As far as I know,\nthere's no significant weakness known for finding a pre-image, which\nwould be the most practical way of weakening Git's \"security\" via\nSHA-1 substitution.\n\nRegardless, the use of SHA-1 in Git isn't primarily for security,\nthough it is a nice side-effect. The SHA-1 is there for reliability in\naddressing and as a good hash.\n\n\nDave.\n"},{"id":"64170","messageId":"20071229050712.GA27378@old.davidb.org","threadId":"11418","inReplyTo":"ee77f5c20712282045ha230f42n3e68477229deb199@mail.gmail.com","subject":"Re: NIST's policy: sha-1 until 2010, after 2010 sha-2.","fromName":"David Brown","fromEmail":"git@davidb.org","sentAt":"2007-12-29T05:07:12Z","receivedAt":"2007-12-29T05:07:12Z","isPatch":false,"sender":{"key":"git@davidb.org","avatar":"https://gravatar.com/avatar/94c86a2938470a74c2eac5e2b69afc0871f79a660295c02219597aba8cb101c1?d=mp&s=160"},"body":"On Sat, Dec 29, 2007 at 03:45:35PM +1100, David Symonds wrote:\n>On Dec 29, 2007 3:27 PM, J.C. Pizarro wrote:\n>> Dear Linus Torvalds,\n>>\n>> What do you think to do when your git has to change from SHA-1 to SHA-2\n>> because of the weaker collision-resistance of SHA-1 in the next years?\n>>\n>> (e.g. from an damn developer trying to commit a collisioned-SHA-1 file)\n>\n>It's a non-issue. The closest-to-practical attack method on SHA-1 is a\n>collision-finding attack, not a second pre-image attack, which means\n>you can find two messages with the same hash. As far as I know,\n>there's no significant weakness known for finding a pre-image, which\n>would be the most practical way of weakening Git's \"security\" via\n>SHA-1 substitution.\n\n has some good background on\nthe \"problem\".\n\nI suppose when SHA-1 is broken and people can generate arbitrary files with\nthe same hash, it would be possible to use this to make files that were\nannoying to try and use with Git. Git wouldn't have any problem with\nnormal colliding files, since it hashes the files with a prefix, so the\nfiles would have to be generated specifically for git.\n\n>Regardless, the use of SHA-1 in Git isn't primarily for security,\n>though it is a nice side-effect. The SHA-1 is there for reliability in\n>addressing and as a good hash.\n\nGiven a method for producing a colliding pair for SHA1, it would be\npossible to check in a version of a file and later replace it in a\nrepository with the other version without detection. The current pairs for\nMD5 contain blocks of binary data, so this would be fairly obvious if it\ngot checked into source code.\n\nIt would also only replace the blob on a compromised machine. Anyone who\nhas already pulled the blob wouldn't download the new one.\n\nAs far as a collision occurring accidentally, according to the Wiki page\n(the math looks right), for a 128-bit hash, 820 billion objects would have\na 10^(-15) probability of a collision. SHA-1 is 160 bits, so the\nprobability is even lower.\n\nThe possible (or even likely) breaking of SHA-1 is only for intentional\ncollisions. SHA-1 as a non-colliding hash function should be good for\ntrillions of objects, and that's all in the same repo.\n\nIt might be worth tossing around ideas for using a larger hash in a fairly\nlong-term future, though.\n\nDave\n"}]}