On 06/24/2014 07:28 AM, Gabriel Niebler wrote: > I consider myself quite the amateur (I haven't even read most of RFC > 4880 yet), but I do take issue with one point in the riseup.net Best > Practices page, namely the bit where it says "self-signatures must not > use SHA1". > I find that statement too strong. > > AFAICS this will lead to keys which may not be understood by some > perfectly standards-compliant OpenPGP implementations, since SHA-1 is > the _only_ hashing algorithm that MUST be supported by all > implementations of that standard. Everything else is up to the > implementer. > > I do not know that there are any such implementations out there, but > there seem to be a lot of people "rolling their own" who occasionally > post to this very list. > > Possibly breaking OpenPGP compatibility does not seem like a Best > Practice to me. I raised this concern in a comment on the _original_ > page at https://we.riseup.net/riseuplabs+paow/openpgp-best-practices > but it didn't garner any interest. > > I believe additional self-signatures can always be added to existing > UIDs and subkeys later and I presume (someone correct me, if I'm > wrong, please) they can use other hashing algos. That might be a way > to get "the best of both worlds": Not breaking standards compliant > clients (which would hopefully just ignore the selfsigs they can't > understand and focus on those they can) AND strong hashing.
to be clear: clients that support stronger digests than SHA-1 are *also* standards-compliant. I don't know of any modern OpenPGP client that doesn't support SHA-256 or SHA-512. Pretty much anything built today should be using libraries for their digest algorithms, and all reasonable libraries that support SHA-1 also support SHA-256 and SHA-512. If you know of a modern OpenPGP implementation that supports SHA-1 but not SHA-256 or SHA-512, please point it out (and no, creating one just to be able to point to it doesn't count :P) What you're proposing would indeed be slightly more widely-compatible, and it would work like this: 0) every self-certification made by GnuPG would be issued twice: once using SHA-1 (selfsig A), and once using a stronger digest algorithm (e.g. SHA-512) (selfsig B). 1) selfsig A should probably have a timestamp that is strictly earlier (probably by 1 second, since that's the quantum that the OpenPGP spec recognizes) than selfsig B, so that implementations that prefer the most recent self-sig and support the stronger digest algorithm will know to prefer it. (this works around any buggy clients that might get confused by two self-sigs with the same timestamp -- if we want to be widely compatible, we should probably cater to them too) 2) While you're at it, you could create selfsigs with each supported digest algorithm, rather than just 2 -- that would make the signature even more widely-compatible, because it would work for clients who implement, for example, RIPEMD-160 but not SHA-256. But i don't think the additional complexity and bulk (these OpenPGP certs would be larger) are worth the tradeoff, because (a) any OpenPGP implementation that only supports SHA-1 in 2014 should be upgraded and fixed, not coddled (they're probably vulnerable to implementation errors at least if they're that out of date) and (b) i don't think they exist. SHA-1 is within range of collision attacks by sophisticated attackers. By the time someone decides it is unreliable (that is, that they will not rely on certifications made using SHA-1), people should have *already* moved on. It's conceivable that someone who wants to reject SHA-1 certifications in general could make an exception for selfsigs (as distinct from third-party certifications) since the worst thing that an attacker can do if they can forge a selfsig is to make you assert an identity for your key that you don't actually control. But this is still an attack, however silly, and the complexity of splitting out what digests you'll accept in self-certifications from what digests you'll accept in third-party certifications smells like trouble to me. So i think that the simplest practice is best: use a single self-sig, made over a single strong, widely-supported digest algorithm. SHA-512 meets that requirement. I hope this analysis is useful. --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users