On the advisability of stronger digests than SHA-1 in OpenPGP certifications [was: Re: riseup.net OpenPGP Best Practices article]

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140626/d2cf123d/attachment.sig>