Mailing List Archive

Working around SHA1 signatures in keyring
For a few years, using gpg (GnuPG) 2.0.22 / libgcrypt 1.5.3 from
ubuntu-14.04 I signed coworker keys using Preferences: AES256 SHA512
BZIP2 ZLIB ZIP in gpg.conf. I am currently setting up an ubuntu-20.04
workstation with gpg (GnuPG) 2.2.19 / libgcrypt 1.8.5 and it would
seem that my config got wiped at some point because the last two keys
I signed (several months ago) give the following error when checking
sigs on my new workstation:

gpg: Note: third-party key signatures using the SHA1 algorithm are rejected

I should point out that I had to add no-self-sigs-only to the
keyserver-options as I guess the default workaround to poisoned keys
(either in the original source or something debian or ubuntu added) is
a scorched earth policy, which is fine but unworkable to our web of
trust. I created some test keys to mimic the same situation and did
the following to try to fix it:

gpg --cert-digest-algo SHA512 --expert --edit-key <key to resign>

I deleted my original signature and signed again. Then I pushed the
test key to the keyservers and added import-clean to gpg.conf and
refreshed the keys from a different test user and it _seems_ to work.
Is this a sane fix? Is there a better or more proper fix?

Thanks!

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Working around SHA1 signatures in keyring [ In reply to ]
On Freitag, 26. M?rz 2021 22:54:51 CET alejandro Cortez via Gnupg-users wrote:
> For a few years, using gpg (GnuPG) 2.0.22 / libgcrypt 1.5.3 from
> ubuntu-14.04 I signed coworker keys using Preferences: AES256 SHA512
> BZIP2 ZLIB ZIP in gpg.conf. I am currently setting up an ubuntu-20.04
> workstation with gpg (GnuPG) 2.2.19 / libgcrypt 1.8.5 and it would
> seem that my config got wiped at some point because the last two keys
> I signed (several months ago) give the following error when checking
> sigs on my new workstation:
>
> gpg: Note: third-party key signatures using the SHA1 algorithm are rejected
>
> I should point out that I had to add no-self-sigs-only to the
> keyserver-options as I guess the default workaround to poisoned keys
> (either in the original source or something debian or ubuntu added) is
> a scorched earth policy, which is fine but unworkable to our web of
> trust.

From gpg's NEWS file:
=====
* gpg: Prepare against chosen-prefix SHA-1 collisions in key
signatures. This change removes all SHA-1 based key signature
from the web-of-trust. Note that this includes all key signature
created with dsa1024 keys. (Version 2.2.18 limits this to key
signatures newer than 2019-01-19.) The new option
--allow-weak-key-signatues[sic] can be used to override the new and
safer behaviour. [#4755,CVE-2019-14855]
=====

Of course, the option is called --allow-weak-key-signatures.

> I created some test keys to mimic the same situation and did
> the following to try to fix it:
>
> gpg --cert-digest-algo SHA512 --expert --edit-key <key to resign>
>
> I deleted my original signature and signed again. Then I pushed the
> test key to the keyservers and added import-clean to gpg.conf and
> refreshed the keys from a different test user and it _seems_ to work.
> Is this a sane fix? Is there a better or more proper fix?

Well, deleting your original signature is useless if you have already
published a key with this signature. Signing the key again with SHA512 is the
proper fix. Note, that using "gpg --quick-sign-key" may be more convenient
than using --edit-key.

Regards,
Ingo