ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Deprecating SHA1

2020-10-23 15:15:18
Hi!

[ CCing the Debian keyring maintainers, that I'm not sure whether they are
  subscribed, and leaving enough quoted text for context. ]

[ And forgot to actually CC the first time around, sorry! :) ]

On Fri, 2020-10-23 at 14:51:08 +0200, Neal H. Walfield wrote:
I'm turning to this mailing list to seek advice about how to deal with
SHA1-based self signatures.  I have two concrete questions, which are
at the bottom of the email.  But first, I want to present the concrete
problem and my thoughts so far.


Based on the "SHA-1 is a Shambles" paper [1] we decided to change
Sequoia to reject signatures that use SHA1 by default [2].  This
includes both signatures over data, as well as self signatures of all
kinds including primary key binding signatures (aka backsigs).

  [1] https://sha-mbles.github.io/
  [2] 
https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html#method.reject_hash_at

A Secure Drop developer recently contacted us, and indicated that our
policy was too strict: some of the Secure Drop installations have
offline keys that use SHA1, and the users have no easy way (or lack
the will) to update those keys.

This prompted me to investigate the use of SHA1 in general.
Unfortunately, it appears that many actively used certificates from
technically sophisticated users still rely on SHA1.  The results of my
investigation are here:

  https://gitlab.com/sequoia-pgp/sequoia/-/issues/595

[…]

Looking at the Debian Keyring, I found that:

  - 106 of the 884 certificate (12%) use SHA1 for all User ID binding
    signatures and direct key signatures

  - 63 more (7%) use SHA1 to protect at least one non-revoked User ID.

  - 234 have a non-revoked, live signing capable subkey

    - 19 of those have binding signatures that use SHA1 in some way
      (8%).

    - 9 use something stronger for the subkey binding signature, but
      SHA1 for the backsig.  (This appears to be a bug in GnuPG, which
      I reported [4].)

  [4] https://dev.gnupg.org/T5110

As Debian Developers are perhaps the most sophisticated OpenPGP users,
this is pretty damning.

[…]

Given these results, we decided to reevaluate our bad listing of SHA1.
As the SHA1 paper indicates that SHA1's preimage resistance is not
broken, I thought that we might be able to accept SHA1 for self
signatures, and not for documents [6].  But, Azul pointed out [7] that
Mallory could create a collision for a document and a self-signature,
and then convince Alice to sign the document.  This could work in
practice because Mallory can predict everything in the signature, but
the timestamp, and if Alice is an automated signing service, there is
a good chance that Mallory would be able to get Alice to sign the
document at the right time.

  [6] https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
  [7] https://gitlab.com/sequoia-pgp/sequoia/-/issues/595#note_433768966

[…]

So, two questions:

  - Does anyone see a safe way to accept SHA1 self-signatures today?
    Or (ouch!), if we want to be safe, do we have to convince ~10% of
    the sophisticated OpenPGP users to re-sign or regenerate their
    keys?
[…]

Regards,
Guillem

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>