SHA1 bindings in your PGP key 4E386D9C9C61702F

SHA1 bindings in your PGP key 4E386D9C9C61702F

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2806 bytes --]

Hello Willy,

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 <w@1wt.eu>) 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.

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).

Find more details at
https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
which also describes a procedure to (hopefully) fix your key.

If questions arise, don't hesitate to ask, in private or on the list.

Best regards
Uwe

[1] https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

[Willy Tarreau]

Hello Uwe!

On Tue, Sep 09, 2025 at 12:03:20PM +0200, Uwe Kleine-König wrote:
> Hello Willy,
> 
> 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 <w@1wt.eu>) 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 ?

> 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).

> 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.

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.

Thanks,
Willy

Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

[Konstantin Ryabitsev]

On Wed, Sep 10, 2025 at 08:40:58AM +0200, Willy Tarreau wrote:
> > 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 ?

Well, there is collision detection code in git to prevent a lot of badness
associated with that attack, and nothing like that in PGP (not sure that's
even possible). So, I wouldn't treat these two problems as the same.

> > 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.

It should not impact your signatures in any way, it will just recreate the
certificate that pairs your identity to your primary key.

If you want to feed to birds with one scone, you can just add your kernel.org
identity to your key and then reset your 1wt.eu identity as primary:

    gpg --quick-add-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <wtarreau@kernel.org>'
    gpg --quick-set-primary-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <w@1wt.eu>'

This will make your key discoverable via the kernel.org WKD and fix the
problem with the SHA1 signature.

You then just need to send me the updated key export.

Hope that helps!

-K

Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

[Willy Tarreau]

Hi Konstantin!

On Wed, Sep 10, 2025 at 09:16:14AM -0400, Konstantin Ryabitsev wrote:
> On Wed, Sep 10, 2025 at 08:40:58AM +0200, Willy Tarreau wrote:
> > > 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 ?
> 
> Well, there is collision detection code in git to prevent a lot of badness
> associated with that attack, and nothing like that in PGP (not sure that's
> even possible). So, I wouldn't treat these two problems as the same.

OK good to know, thank you!

> > > 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.
> 
> It should not impact your signatures in any way, it will just recreate the
> certificate that pairs your identity to your primary key.
> 
> If you want to feed to birds with one scone, you can just add your kernel.org
> identity to your key and then reset your 1wt.eu identity as primary:
> 
>     gpg --quick-add-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <wtarreau@kernel.org>'
>     gpg --quick-set-primary-uid 0C9568FA554656551590C5E44E386D9C9C61702F 'Willy Tarreau <w@1wt.eu>'

But then it creates a new identity ? If so, that's precisely what I'm
trying to avoid. I'm not using my kernel.org e-mail address, and am using
my current GPG key to sign other projects. That's why I'm overly cautious,
given breakage in this area is usually invisible only for the one doing it,
but quite visible for everyone else.

I'll try to run through Uwe's link and see how far that goes without error
(since gpg loves to change options in every version).

Thanks!
Willy

Re: SHA1 bindings in your PGP key 4E386D9C9C61702F

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 5976 bytes --]

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 <w@1wt.eu>) 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]