Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

Uwe Kleine-König <[email protected]> Thu, 11 Sep 2025 10:36:33 +0200
Newsgroups	org.kernel.linux.keys
Message-ID	<gnk6kytvttlu7aw3rmfcelrjbfoufsmo6ypj7nfv5whkjxabvm@33s5tsfs2es7>
Hello Willy,

On Wed, Sep 10, 2025 at 08:40:58AM +0200, Willy Tarreau wrote:
> On Tue, Sep 09, 2025 at 12:03:20PM +0200, Uwe Kleine-König wrote:
> > recently your PGP key 4E386D9C9C61702F was updated in the kernel PGP
> > keyring after you expanded its validity
> > (https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/commit/?id=e8a3192d295094087e09f623595c8309b2eac915). 
> > 
> > Taking this as a hint that you still care about the key:
> > 
> > This key suffers from SHA-1 bindings which are not considered on par with
> > typical security recommendations today:
> > 
> > 	$ sq cert lint < keys/4E386D9C9C61702F.asc
> > 	Certificate 4E386D9C9C61702F is not valid under the standard policy: No binding signature at time 2025-09-09T09:45:16Z
> > 	Certificate 4E386D9C9C61702F contains a User ID (Willy Tarreau <[email protected]>) protected by SHA-1
> > 	Certificate 4E386D9C9C61702F, key 014180C7E8419672 uses a SHA-1-protected binding signature.
> > 	Examined 1 certificate.
> > 	  0 certificates are invalid and were not linted. (GOOD)
> > 	  1 certificate was linted.
> > 	  1 of the 1 certificates (100%) has at least one issue. (BAD)
> > 	0 of the linted certificates were revoked.
> > 	  0 of the 0 certificates has revocation certificates that are weaker than the certificate and should be recreated. (GOOD)
> > 	0 of the linted certificates were expired.
> > 	1 of the non-revoked linted certificate has at least one non-revoked User ID:
> > 	  1 has at least one User ID protected by SHA-1. (BAD)
> > 	  1 has all User IDs protected by SHA-1. (BAD)
> > 	1 of the non-revoked linted certificates has at least one non-revoked, live subkey:
> > 	  1 has at least one non-revoked, live subkey with a binding signature that uses SHA-1. (BAD)
> > 	0 of the non-revoked linted certificates have at least one non-revoked, live, signing-capable subkey:
> > 	  0 certificates have at least one non-revoked, live, signing-capable subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
> > 
> > 	  Error: 1 certificate have at least one issue
> > 
> > The issue is that the proofs about your UID and your subkey
> > 014180C7E8419672 belonging to your main key 4E386D9C9C61702F rely on
> > SHA-1 hashes which is considered weak since at least 2005[1]. Practical
> > breakage is not known yet, but still I recommend to update your key to a
> > safer hash algorithm to reduce attacking surface.
> 
> Hmmm unless I'm missing something, these serve to sign tags designating
> a commit that itself relies on SHA-1, no ? So in this case if we don't
> trust the keys anymore because we consider them weak, we shouldn't trust
> the tags nor the commits either ?

As Konstantin already explained the attacks are different and so the
available measurements to protect against then are different. But yes,
git using SHA-1 is also a problem, though on a smaller scale.

> > GnuPG doesn't create such bindings by default any more, but it also
> > doesn't fix these when opportunities arise (e.g. when expanding key
> > validity). Other implementations (e.g. Sequoia PGP) don't even accept
> > these keys any more (while GnuPG continues to be happy about them).
> 
> OK that might be a good reason (even if some tools tend to deprecate
> certain well-known and well working solutions sometimes for non-technical
> reasons, I'm not judging if that's the case here or not).

In my opinion it's GnuPG that's wrong here. See
https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
for another opinion.

I'm not sure if GnuPG should stop trusting SHA-1, but at least it should
fixup SHA-1 bindings on key updates.

> > Find more details at
> > https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
> > which also describes a procedure to (hopefully) fix your key.
> 
> Thank you. I must admit I'm a bit lost by the complexity of these
> operations, especially since I don't understand their impact. Does
> this mean that my key that was previously signed will change if I
> do that, and that as such it will have to be signed again ? What
> should I backup before entering these operations in case things go
> wrong or if I simply do a mistake ? I never understand even the
> questions in GPG, so I tend to randomly respond until it works.

What I'd recommend you here is:

	gpgconf -K all
	make a backup of ~/.gnupg
	gpg --export 0C9568FA554656551590C5E44E386D9C9C61702F > my-key-with-sha1
	Fix the bindings according to my description (or Konstantin's if you prefer that with their side effects)

	gpg --export 0C9568FA554656551590C5E44E386D9C9C61702F > my-key-without-sha1

Then you can check what the binding fix did using e.g.:

	diff <(sq packet dump < my-key-with-sha1) <(sq packet dump < my-key-without-sha1)

which should convince you that it just added some signature packets and
so doesn't invalidate e.g. signatures you received or mails you signed.
You can also use `gpg --list-packets` instead of `sq packet dump`, but
the diff is more cluttered then because gpg includes offsets in its
output that change but are not relevant to the semantic changes.

Once you're convinced the update was fine, send the key to the key
servers. If you're unsure, feel free to follow up with your doubts (and
run `gpgconf -K all` + restore ~/.gnupg).

> I must admit that I'm not exactly GPG's best friend and it turns the
> favor back to me, so the least I touch it the better I feel.

Yeah, GnuPG has the problem that a) OpenPGP isn't easy and b) the tool
is already old and has some historic ballast. If you care about user
experience I recommend exploring Sequoia. The command to fix your key
with that is just

	sq cert lint --fix 0C9568FA554656551590C5E44E386D9C9C61702F

which is much more user friendly than the GnuPG way to fix the key
(without further changes).

Best regards
Uwe
signature.asc (application/pgp-signature, 488 B)