Re: [openpgp] Deprecating SHA1

[Paul Wouters <[e-mail]>]

Could you give implementers some guidance?

- don’t allow creating sha1 signatures 
- don’t allow verification with sha1 to pass for data time time stamped after 2020 (eg based on email headers or signature time stamps)
- allow verification of old data with sha1 to pass

Paul

Sent from my iPhone

> On Oct 23, 2020, at 08:51, Neal H. Walfield <[e-mail]> wrote:
> 
> 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 [e-mail] 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
> 
> _______________________________________________
> openpgp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp