Subject: [openpgp] Deprecating SHA1

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 23 Oct 2020 14:51:08 +0200

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 [email-masked] 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: Paul Wouters <[email-masked]>
Date: Fri, 23 Oct 2020 10:52:35 -0400

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 <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 23 Oct 2020 17:17:15 +0200

Hi Paul,

Thanks for following up.

On Fri, 23 Oct 2020 16:52:35 +0200,
> - don’t allow creating sha1 signatures 

I suspect that most implementations already do this.

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

The Sequoia library does pretty much already what you are suggesting
(although we set the cutoff for SHA1 to 2013, not 2020): when an
application developer configures a policy, they can specify a
timestamp.  The timestamp is then used to select algorithms that were
safe as of the specified time.

  https://docs.sequoia-pgp.org/sequoia_openpgp/struct.Cert.html#method.with_policy

The difficulty for the application developer is to find a timestamp
and authenticate it.  Consider: Alice encrypts an email to Bob.  If
Bob's certificate uses SHA1 for all of the self signatures, should
Alice accept the self signatures?  She has no email headers to extract
a time stamp from (she's sending him a mail, not verifying a signature
in a message that Bob sent her).  As for the time stamp in the self
signature, it's not clear to me why it should be trusted.  Say Mallory
collides a document sig and a self sig for Alice, and gets Alice to
sign the document at the right time.  He can set the self sig's
timestamp to whatever he wants, including just far enough in the past
that it gets by your proposed filter.

Thanks for your thoughts,

Neal

---

From: Phil Pennock <[email-masked]>
Date: Fri, 23 Oct 2020 15:23:17 -0400

>     the sophisticated OpenPGP users to re-sign or regenerate their

At the start of this year, I reached out individually to maintainers
signing releases of some security critical software and had good luck
getting them to re-sign, by including instructions on how to do so.

I never got around to producing a blog-post, but the messaging worked,
everyone I reached out to followed through and fixed.  It's a small
sample set of about 5, and population biased towards caring about
security.  So while I wouldn't extrapolate to "everyone will do it", I
think with pressure "many people will".

The TLDR for folks using the widespread GnuPG software is that GnuPG
defaults to protecting you against a new self-sig, but expert-mode makes
it easy:

    gpg --expert --cert-digest-algo SHA256 --sign-key $YourKeyId

Crafted messages around that worked.  "Hey, it's one line and then
uploading your keys" -- I think getting 80% of that 10% is probably
fairly doable.  That then leaves 2% of total users with broken keys,
which is a more viable cut-off.

If services such as keys.openpgp.org started showing big scary red
warnings above keys which lack a sane self-sig, or warning on upload,
we'd get some pressure that way.

-Phil

---

From: Guillem Jover <[email-masked]>
Date: Fri, 23 Oct 2020 22:13:55 +0200

Hi!

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

>   https://gitlab.com/sequoia-pgp/sequoia/-/issues/595
[…]
> As Debian Developers are perhaps the most sophisticated OpenPGP users,
[…]
>   [7] https://gitlab.com/sequoia-pgp/sequoia/-/issues/595#note_433768966
[…]
>     the sophisticated OpenPGP users to re-sign or regenerate their
[…]

Regards,
Guillem

---

From: Guillem Jover <[email-masked]>
Date: Fri, 23 Oct 2020 22:15:04 +0200

Hi!

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

[…]
[…]
[…]
[…]

Regards,
Guillem

---

From: Jonathan McDowell <[email-masked]>
Date: Sat, 24 Oct 2020 09:57:25 +0100

>     gpg --expert --cert-digest-algo SHA256 --sign-key $YourKeyId

I'm one of the people with a SHA1 self signature. I've been aware of it
for some time, and it's been on my todo list to sort out, but when I
last tried GPG did not make it possible. What version of GPG is
necessary for the above to work? The somewhat aged versions on the
airgapped machine my master key lives on do not seem to want to update
the type of the self sig with that command.

J.

-- 
Chaos, panic, & disorder - my work here is done.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Sat, 24 Oct 2020 17:41:52 +0200

Hi Phil,

On Fri, 23 Oct 2020 21:23:17 +0200,
> think with pressure "many people will".

Thanks for the report.  I think your hope is well founded.

>     gpg --expert --cert-digest-algo SHA256 --sign-key $YourKeyId

I wasn't aware of this, thanks for pointing it out.  Unfortunately,
for many keys it is not enough.

There are three types of signatures that we should worry about:

  1. User ID (and User Attribute) self signatures
  2. Subkey binding signatures
  3. Primary key binding signatures (a signing-capable subkey's "backsig")

Your suggestion causes gpg to update the User ID self signatures (1).
It is possible to update subkey binding signatures (2) by changing
their expiration time.  I'm not aware of a way using gpg to simply
say: refresh the current subkey binding signature.  As for the backsig
(3), it would make sense to update this when updating the subkey
binding signature (2), however, gpg doesn't currently do this.  See:

  https://dev.gnupg.org/T5110

> we'd get some pressure that way.

Thats a good idea.

:) Neal

---

From: "brian m. carlson" <[email-masked]>
Date: Sat, 24 Oct 2020 16:53:54 +0000

>     the sophisticated OpenPGP users to re-sign or regenerate their

I think the time for transition with SHA-1 is gone.  The algorithm is
estimated to be attackable for $45,000.  A thrifty and reasonably
well-paid software engineer could put that away in a year or less.  It's
within the budget of almost any medium or large business.

We should soundly bludgeon SHA-1 over the head and let it die.  I'd
propose stating that implementations MUST NOT accept signatures made
with MD5 or SHA-1 in RFC 4880 bis.  Both have been known to be weak for
a long time.  It will be painful, but we're not helping anyone by
continuing to accept weak algorithms.

I should point out that GnuPG has shipped with SHA-256 since
approximately 2002 and SHA-384 and SHA-512 since at least 2007.  That
means everyone using any major operating system that still has security
support should be able to verify newer signatures.

If we're provident, we'll specify some version of SHA-3 to be a SHOULD.
Cryptanalysis is advancing on SHA-2.

>     the content of the hash less predictable as described in [7]?

I know not everyone will agree, but I prefer deterministic signatures.
There are use cases for OpenPGP with systems with little or no entropy
using Ed25519 or deterministic ECDSA for signing.  Smart cards come to
mind, for example.

Additionally, I don't think a salt is proof that a signature doesn't
have a collision.  If the salt is generated by the attacker, then it can
easily be part of the collision.  That could easily be the case if the
signature came from a smart card or embedded device, where the salt
might not be generated on the card.  We therefore cannot rely on it as
evidence that a signature using a weak algorithm is secure.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

---

From: Jon Callas <[email-masked]>
Date: Sat, 24 Oct 2020 18:01:09 -0700

I'm reading this with a good deal of exasperation. I apologize in advance for my tone, and I am not at all sorry about the content.

In 2004, the mathematician Wang Xiaoyun published a thing that possibly doesn't need mentioning. She broke, where "broke" means found collisions, in a mess of hash functions including MD5, SHA0, and a lot more. Her original publication is one of the most badass things I've ever seen in cryptography: she just published the collisions. H(X) == H(Y) for the suitable X and Y in enough number to show it's not a fluke (two is a good number for this) and across appropriate hash functions. This sent everyone into a tizzy. Did she know some underlying mathematical secret that we didn't?

Weeks and weeks went by, on to CRYPTO in Santa Barbara, and there was a lot of stress, speculating, and hand-wringing going on. At CRYPTO, Wang gave a talk on the work[1], and the rest of us found out that she didn't have any new mathematical insight, she was merely the best cryptanalyst on the planet, someone who had seen order trails of flipping bit that no one else on the planet had seen. At dinner that evening, I was talking to Ron Rivest and he said, "I used to think that hash functions were the cryptographic primitive that we understand best, now I know that they're the primitive we understand least."

Between those times, coming out of a session where we all got to talk to Wang in person, I walked out into the UCSB quad, got out my phone and called my friend and colleague, Will Price, who was VPE at PGP; I was CTO. We talked as I explained what had gone on in the session. I remember hearing the clack of Will typing as we talked. Twenty minutes later, he had a download link for me of a version of PGP that didn't use MD5 at all, used SHA256 by default (much of our conversation was whether it should be that or SHA512) and didn't outright prevent using SHA1 (which wasn't broken yet, but the betting on when was pretty furious), but it was pretty much stuck in the "advanced" preference UI in a disused lavatory with a sign on the door reading "beware of the leopard." That software went through our normal release QA, and shipped right after that, total time less than a week.

I know that hindsight is 2020, but why is this being discussed?

I'm sure that some readers of that paragraph saw through the little magic trick I did. I implied it took twenty minutes to make changes. Those same readers will realize that in fact we'd been discussing what to do and had a number of contingency plans based on what we found out about what Wang had discovered. That phone call was us deciding what to write in icing on the cake that had been baked weeks before. We're not geniuses, we just thought ahead and made some bold contingency plans. You can think ahead. You can be bold. Come on, get yourself an outfit and be a cowboy, too[2].

I get the impression that most people here think that the map is the territory. That RFC4880 and anything else is the definition of what one does. Here are a number of options possible.

* You could stop creating signatures that use SHA1. Just stop. Ditto for any other compromised aspect of SHA1.

* You could resolve a signature with SHA-1 in a creative way. For example, signatures have a number of states. There's the obvious case of a signature not computing correctly, say if the message has been damaged. That one's easy. There's the case of a correct signature from a trusted key. That's also easy. There are other cases that you have to take care of that are in the middle. You have to deal with a correct signature from an untrusted key. You have to deal with a signature made by a key that you don't have and so you can tell if it's correct or not. There are other edge cases, too.

Thus, you could consider a SHA1 signature to be incorrect and let the user know. You could consider it to be like a signature for a key you don't have. You could let the user know that it's mathematically correct but untrusted. (We did things like this in PGP; yes, this can be complex.)

You could consider a self-signature done with SHA1 to be non-existent, and handle it appropriately. You could even take special knowledge you have and do some reasonable thing. For example, let's suppose you know that this self-signature was created before the Shatter attack, and so you'll let is slide by. 

* You could also do helpful things for the user -- for example, when you have the key unlocked (by which I mean that you have the user's passphrase and thus the private key in your hot little RAM), you could go rewrite their self-signature with some other hash function and give them a new one just like the old one. (We did that in PGP, too.)

* You can do other helpful things for users like writing preferences in their self-signature that you, as implementor, think are helpful. You could do something like change key expiry automatically, as well. Just as text editors help users with things like autocorrect, you can help users in proper crypto management.

* You could compute primitives in any way that a naïve partner will handle correctly, as well. All the way back to when PGP started doing DSA (because in those days, there were patent issues with RSA), we were concerned with the issue with DSA that losing a single random number exposes the key. So when we computed the DSA random value, we took the raw nonce and then ran it through a keyed hash with the DSA private key. If you use N' = H(K+N) in DSA, you protect the nonce; learning the nonce requires either breaking the hash function or knowing the private key. (These days, you'd likely HMAC the nonce with the private key as that's today's idiom. In those days, there was no HMAC.) It's been that way for like ever, and no one ever noticed. We even discussed deterministic constructions using the private key with NIST and they said, no, we couldn't get that approved, but they liked the keyed hash.

* You can do plenty of other things. The standard is not a straightjacket. Implementers do not have to be fundamentalists nor textualists about it, either.

Particularly in the case where the OpenPGP support is built into some context, like an email client, there's nothing wrong with building something that only does a few things.

I'm flabbergasted because it seems to me that people are waiting for the working group to give permission to use (or not use) features of the OpenPGP standard. On the other hand, it seems that there's this expectation that if the standard says (e.g.) "MUST NOT use SHA1" that that will somehow magically make all the software get updated. 

Yeah, sure, there's nothing wrong with the standard noting that SHA1 is broken for collisions, act accordingly. That's neither necessary nor sufficient. Implementors can all decide that they're not going to use SHA1, and that makes it *really* happen. I'm grouchy about guidance in standards because implementation guidance for cryptography changes over time and often has a lot of nuance in it. There's guidance in 4880 that is just flat wrong. It's there despite being wrong because it was the consensus of the working group and the area directors that these wrong things are there. The one I'm thinking of is also not bad advice, but it's still wrong. Sorry for getting carried away there. My point is that the standard is not gospel and neither is it a bottleneck. It is a description of how the bits are laid out for the purpose of interoperability. 

Summing up, yes, stop using SHA1! How many bits must a cryptography write down before this is an issue. PGP, a reference implementation for OpenPGP stopped in 2004. NIST said to stop using it by the end of 2010. Highlight is 2020. Putting some appropriate text in OpenPGP about it is a fine thing. You don't have to wait for that. Be bold! 

Thanks for reading.

	Jon

[1]: The Wikipedia article on Wang is dreadful. In it, it says, "At the rump session of CRYPTO 2004, she and co-authors demonstrated..." This statement is 100% true and yet paints a picture that is totally false. It implies that the penny was dropped in the rump session when that was the closest thing to an official coming-out. It had been discussed in mailing lists, chat rooms, and the like before.

[2]: https://www.youtube.com/watch?v=dCeelWFO56Y

---

From: Phil Pennock <[email-masked]>
Date: Sat, 24 Oct 2020 21:03:43 -0400

> for many keys it is not enough.

[profanity]

>   3. Primary key binding signatures (a signing-capable subkey's "backsig")

Okay, I think the cases I hit didn't have this, or folks took time to
add new subkeys when things expired.  The UID self-sig is the one needed
to let the web-of-trust calculate without SHA1 so is what I cared about.

For myself, even with the oldest key, using expiring subkeys and
refreshing periodically with newer subkeys, everything _except_ the
self-sig had updated automatically by the time I went looking.

I think really we need some nice pgpkey-sanitycheck command-line tool,
from any project, which looks purely at public key information, so
doesn't need to care about internals (private keys, keyboxes, etc).

Such a tool might then report on outdated algorithms used in important
places, while avoiding getting into the political mess of which
algorithm order preferences should be included in a key.

Deprecating X without tools to make it _trivial_ for people to tell if
they're affected by X is going to be frustrating.  In my previous email,
I didn't mention the diagnostics I used to show people that their key
was affected, but it involved `gpg --list-packets` and it was not
pretty.

I held off on "asking others to write software for me" in the previous
post, keeping it to "this exists now".  This time around, I'm throwing
out a "Hey, pgpkey-sanitycheck would be a nice tool to have, folks" and
running away.

-Phil

---

From: Phil Pennock <[email-masked]>
Date: Sat, 24 Oct 2020 21:19:24 -0400

> the type of the self sig with that command.

[ not to list-cop, just to make sure that I'm not blindly taking this
  down a rat-hole not germane to the IETF list, since I'm the one who
  raised GnuPG in the first place: ]
Since this affects the ease of a deprecation, I'm considering this
on-topic enough for me to reply here; if the follow-ups are specific to
GnuPG, then gnupg-users might be a better mailing-list?  If it's about
the real-world practicalities of migrating and the impact on IETF
standardization then perhaps not.

I see commit messages about "Honor --cert-digest-algo when recreating a
cert." from 2012:

  commit 2b3cb2ee94625498e7a7f939216c9bcddef6ec20
  Author: David Shaw
  Date:   Tue Jan 31 21:30:05 2012 -0500

  commit 60c58766aeb847b769372fa981f79abac6014500
  Author: Christian Aistleitner
  Date:   Sun Oct 14 20:30:20 2012 +0200

Using `git tag --contains $COMMIT_SHA`, it looks like gnupg-2.1.0
onwards include it.  If memory serves, there's an "odd minor is dev,
even minor is release" pattern used here, so 2.2 would have been the
first "real release" even though lots of places had 2.1 packaged.

<https://gnupg.org/download/> has an EOL table; GnuPG 1.4 is dead-end
with no support for modern algorithms; 2.0 started on 2006-11-11 and
reached EOL on 2017-12-31.  GnuPG 2.2 cites 2014-11-06.

If the modern GnuPG approach to partitioning up the work in managing a
keyring is of concern, then I suspect Neal will be happy to help with a
migration to Sequoia PGP.  :)

-Phil

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 25 Oct 2020 05:58:14 +0000

Jon Callas <joncallas=[email-masked]> writes:

>Here are a number of options possible.

Another thing to consider is how to deal with existing signed data.  If
there's a file that's been sitting on a local disk for twenty years signed
with SHA-1 then the signature isn't going to be suddenly invalid just because
SHA-1 is wobbly.  So some provision for recognising existing data as still
valid rather than "anything signed with SHA-1 is automatically suspect" would
be good.

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Oct 2020 23:06:03 -0700

Hi Jon,

> I'm reading this with a good deal of exasperation. I apologize in advance for my tone, and I am not at all sorry about the content.

Understood.

> * You can do plenty of other things. The standard is not a straightjacket. Implementers do not have to be fundamentalists nor textualists about it, either.

Indeed.  In fact, by my reading, the thread started with a request for help
thinking about what to actually do in implementations, with much less
regard for what to put in the standard.

I appreciate that you took the time to write up so many potential things to
do.

Thanks,

Ben

---

From: Ángel <[email-masked]>
Date: Wed, 28 Oct 2020 01:14:44 +0100

On 2020-10-24 at 21:03 -0400, Phil Pennock wrote:
> I think really we need some nice pgpkey-sanitycheck command-line
> tool, from any project, which looks purely at public key information,
> so doesn't need to care about internals (private keys, keyboxes,
> etc).
> 
> Such a tool might then report on outdated algorithms used in
> important places, while avoiding getting into the political mess of
> which algorithm order preferences should be included in a key.
> 
> I held off on "asking others to write software for me" in the
> previous post, keeping it to "this exists now".  This time around,
> I'm throwing out a "Hey, pgpkey-sanitycheck would be a nice tool to
> have, folks" and running away.

I too have thought in the past we should have a "pgplint" tool.¹
I have several ideas on what to measure (this community probably has
lots more), it's something I could do but didn't have the motivation to
start coding it.

¹ I don't know if Broadcom might dislike such name, though. Maybe it
should be called openpgp-lint, then?

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 30 Oct 2020 10:50:59 +0100

On Sun, 25 Oct 2020 02:03:43 +0100,
> self-sig had updated automatically by the time I went looking.

Right.  User ID self signatures are the worse offenders, but subkey
binding signatures are also a problem.  I collected some statistics
about different projects.  You can find them here:

It seems that there are 19 certificates in the Debian keyring that
have non-revoked, live signing-capable subkeys that rely on SHA-1 in
someway.  10 use SHA1 for the subkey binding signature, and 9 only use
it for the primary key binding signature (the backsig).  That's just
over 2% of the certificates in the Debian keyring.  Arch is about the
same (2 of 76 certificates).

Although it is possible to fix the subkey binding signature by
adjusting the subkey's expiration time, using gpg, this won't update
the backsig, see:

> was affected, but it involved `gpg --list-packets` and it was not

Indeed.  Unfortunately, `gpg --list-packets` doesn't show the content
of the backsig:

  $ gpg --export FPR | gpg --list-packets
  ...
  # off=806 ctb=89 tag=2 hlen=3 plen=346
  :signature packet: algo 1, keyid A23C95250F66162A
  	version 4, created 1603438577, md5len 0, sigclass 0x18
  	digest algo 10, begin of digest e9 34
  	hashed subpkt 27 len 1 (key flags: 02)
  	hashed subpkt 33 len 21 (issuer fpr v4 2...)
  	hashed subpkt 2 len 4 (sig created 2020-10-23)
  	hashed subpkt 9 len 4 (key expires after 3y0d0h5m)
**  	subpkt 32 len 156 (signature: v4, class 0x19, algo 1, digest algo 2)
  	subpkt 16 len 8 (issuer key ID A...)
  	data: [1024 bits]

For what it is worth, `pgpdump` `sq packet dump` (also at
https://dump.sequoia-pgp.org), and `rnp --list-packets` do show that
information.

> out a "Hey, pgpkey-sanitycheck would be a nice tool to have, folks" and

The tool that I used to conduct my analysis is available here:

  https://gitlab.com/sequoia-pgp/keyring-linter

(Eventually we plan to integrate a linter into `sq`.)

Justus was nice enough to upload it to crates.io:

  https://crates.io/crates/sequoia-keyring-linter

So it should be just a `cargo install sequoia-keyring-linter` away.

And, if I understood dkg correctly, he is in the process of packaging
it for Debian.

:) Neal

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 30 Oct 2020 10:59:48 +0100

On Wed, 28 Oct 2020 01:14:44 +0100,
> lots more), it's something I could do but didn't have the motivation to

I suspect that this mailing list is not the right place to discuss
this issue in detail.  I'd be happy to use the issue tracker for the
keyring-linter as a place to gather ideas:

(If someone prefers a more neutral place, I'd be fine with that.)

:) Neal

---

From: "Neal H. Walfield" <[email-masked]>
Date: Fri, 30 Oct 2020 13:25:19 +0100

On Sat, 24 Oct 2020 18:53:54 +0200,
> within the budget of almost any medium or large business.

The attack presented in the paper is impressive, but it is perhaps not
as devastating as one might initially think.  In particular, it's not
a preimage attack, but a collision attack that relies on human help.
The attack is still dangerous, and I think we should deprecate SHA-1
in the near future, but there are a number of certificates out there
in active use (see my previous mails) that rely on SHA-1.  And, if
there is a safe way to continue to support them in the near term
(which I increasingly doubt is the case), I think we should.  And, we
should use the time that we buy to smooth the transition for users.

Currently, the ecosystem has radically different approaches to
handling SHA1.

In Sequoia, we decided to bad list SHA1.  (We still provide a
mechanism for a user of the library to say: I know that this artifact
has not been modified since T, so use a reasonable policy for this
authenticated time stamp.  For SHA1, we set the cuttoff to 2013.)

In reaction to the SHA-1 is a Shambles paper, Werner changed gpg to
disallow third-party certifications using SHA1 created prior to
19.1.2019 [1].  But, gpg still unconditionally permits self signatures
and binding signatures using SHA-1 (tested with 2.2.20 from Debian).

  [1] https://github.com/gpg/gnupg/commit/edc36f59fcfcb4b896a53530345d586f7e5df560

It's not clear to me that the impersonation attack presented in the
paper can't be adapted to self-signatures.  For instance, I think Bob
could get Alice to sign his key, then he could reuse that self
signature to add an encryption capable subkey to Alice's key using a
colliding binding signature.

Also gpg doesn't appear to authenticate the timestamp in third-party
certifications.  Although the attack in the paper hides the collision
blocks in the key material and user attribute, and assumes that the
signature packets are identical, it seems to me that it would be
possible with a bit more work to hide them in the signature packet's
hashed subpacket area.  Then, the attacker could control the signature
packets' creation times, and circumvent this defense, at least for
keys created prior to 2019.

My understanding is that the RNP developers don't bad list SHA-1 at
all.  In the future, they plan to add a special result code
RNP_SIGNATURE_WEAK, when a signature uses SHA1, but AIUI they still
plan to accept SHA-1 by default.  I'm not convinced that this will
cause users to be more careful.

  https://bugzilla.mozilla.org/show_bug.cgi?id=1641720#c3
  https://github.com/rnpgp/rnp/issues/1281

These different approaches make it harder to deprecate SHA1.  Even
though Sequoia tells a user that a certificate is unusable, because
the crypto it relies on is weak, if that user is like most users I
know, they will understand the message as: Sequoia can't do something
that these other implementations can do.  This places pressure on us
to find a way to safely accept at least the certificates that rely on
SHA1 and are in active use.

I think we could solve this problem if we as an ecosystem could find a
way to move forward together.  In this regard, the players in the
X.509 ecosystem are far ahead of us: they publish timelines to
deprecate algorithms, and most implementations seem to follow them.

> Cryptanalysis is advancing on SHA-2.

I think this is reasonable.

> using Ed25519 or deterministic ECDSA for signing.  Smart cards come to

I suggested adding the non-determinism to the hashed data (i.e., in
the signature packet), not to the data that is directly signed.  Most
smartcards that I know of are fed the hash.  So, in my proposal, it
would be up to the host system to generate the salt, not the
smartcard.

> evidence that a signature using a weak algorithm is secure.

I'm trying to save the self signatures.  So, the case that I'm worried
about is: Mallory convinces Alice to sign something, and the signature
can be repurposed to modify Alice's key, e.g., attaching an
encryption-capable subkey that Mallory controls to it.  A self
signature is over the primary key, a User ID, and a signature packet.
In this case Mallory doesn't control the primary key or the User ID.
So, he has to modify the signature packet.  Since he can't give Alice
a signature packet, he has to predict the signature packet's contents.
Today, modulo the time stamp, this is possible.  Adding a salt would
make this harder.  And, the authors of SHA-1 is a Shambles seem to
suggest that this would be a reasonable defense:

  Section 7.2 SHA-1 Usage in X.509 Certificates

  If some of the CAs still issuingSHA-1certificates use predictable
  serialnumbers, a similar attack might be possible today (being
  located at the beginning of the“to-be-signed” part of the
  certificate, if the serial number is unpredictable then the
  CPcollision attack is thwarted as a crucial part of the hashed input
  is not controlled by theattacker).

  https://eprint.iacr.org/2020/014.pdf

Thanks,

:) Neal

---

From: Tobias Mueller <[email-masked]>
Date: Thu, 29 Oct 2020 13:02:04 +0100

Hi Ángel,

On Wed, 2020-10-28 at 01:14 +0100, Ángel wrote:
> I too have thought in the past we should have a "pgplint" tool.

Maybe hopenpgp's "lint", i.e. "hokey lint" is such a tool.
>From the man page:

   Available commands:
       [...]

       lint   check key(s) for 'best practices'

Cheers,
  Tobi