Deprecating SHA1

[openpgp] Deprecating SHA1

Hi,

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

First, I found that Microsoft's "Security Notifications PGP Key" [3],
which was created less than a year ago (Oct 2019) uses SHA-1.  Given
the use of the preferred-email-encoding@pgp.com notation, I suspect
that they are using a Symantec PGP product.

  [3] https://www.microsoft.com/en-us/msrc/pgp-key-security-notifications

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.

For Arch developers, the situation is worse: 2 of the 5 master ("CA")
keys rely on SHA1.  Of the 72 developer keys, 26 (36%) use SHA1 for
all User ID self signatures and direct key signatures.  Of the 46
remaining certificates, 2 use SHA1 for a non-revoked, live
signing-capable subkey.

Looking at the Fedora Project's signing Keys [5]: all 7 use SHA1
exclusively.  When I spoke with the person responsible for this
infrastructure, we discovered that this was due to a configuration
error, which they promptly fixed.

  [5] https://getfedora.org/static/fedora.gpg

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

If the signature included a salt, Mallory would have had a much harder
time coercing Alice to sign the document with the right metadata.  As
such, we plan to include a salt in all signatures that Sequoia makes
so that should, say, SHA256 suffer the same fate as SHA1, we can still
rely on preimage resistance to allow us to continue to accept self
signatures that use SHA256 for a while [8].

  [8] https://gitlab.com/sequoia-pgp/sequoia/-/issues/597

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?

  - What do people think about including a salt in the hash to make
    the content of the hash less predictable as described in [7]?

Thanks!

:) Neal

from Hacker News https://ift.tt/35yfaoa