Date: Wed, 13 Nov 2013 11:54:17 -0500 From: Daniel Kahn Gillmor <dkg@...thhorseman.net> To: oss-security@...ts.openwall.com Subject: cryptographic primitive choices [was: Re: Microsoft Warns Customers Away From RC4 and SHA-1] On 11/13/2013 10:57 AM, Tim wrote: > Using a weak encyption algorithm alone isn't a sufficient condition to > issue a CVE against software, since often the context of the usage > matters a lot. If you use MD5 or SHA-1 for password hashing (with > lots of salt and rounds), then there's no vulnerability. If you use > them for HMACs, then there's also likely no problem. But if you use > them for a signature with a public key, there is. I'm inclined to try to apply your suggested guidelines to GnuPG: gnupg uses SHA-1 as its default digest algorithm when making public key signatures, both for cleartext "data signatures" and "certifications" (OpenPGP keysigning). Suggestions in the past to change the default digest algorithm to SHA-256 have been resisted for the sake of interoperability, despite every OpenPGP implementation in wide use having been capable of SHA-256 for many years. Are you saying we should assign a CVE for the fact that GnuPG generates data signatures over SHA-1 by default? What about its generation of certifications over SHA-1 by default? What about for the fact that GnuPG validates and accepts OpenPGP certificates made via SHA-1 (note that this is a different question from whether generating them warrants a CVE)? GnuPG also currently accepts and validates certifications and data signatures made with MD5. (it prints a warning, but it still treats the certifications as acceptable when computing certificate validity, for example). Should we assign a CVE for this as well? As a reference point, the recent ENISA recommendations  recommend digests of 160 bits (SHA-1) for "legacy" applications, 256 bits (SHA-256) for "near-term future" (at least 10 years) applications and 512 bits (SHA-512) for "long-term future" (30 to 50 years, which they acknowledge is difficult to predict). I've been encouraging gnupg to move to stronger default cryptographic primitives for years. i would appreciate any guidance the community wants to give about how seriously to take these configuration choices. --dkg  http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report Download attachment "signature.asc" of type "application/pgp-signature" (1028 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.