Page MenuHome GnuPG

GnuPG 2.4.6 rewrites Ed25519 MPIs into non-compliant MPI form
Open, Needs TriagePublic

Description

On gnupg-devel, @wiktor-k reports that GnuPG appears to be modifying the MPIs of an Ed25519 signature packet into non-compliant MPI form.

I was able to replicate the problem with 2.4.6, but 2.2.45 does not appear to have the problem.

Below is a minimal sample v4 OpenPGP signing-capable secret key using EdDSA/Ed25519 with user ID "User ID 22546":

-----BEGIN PGP PRIVATE KEY BLOCK-----

xVgEZzupvxYJKwYBBAHaRw8BAQdAX2U1y958rcAE4NnPUsUtDI82d7Ps6Uwc9ekh
9mmNJIcAAQCrb3+ZJB9vugoCS8u192VXZcJVaD1hr9+zwxeQ1F2scA+jzQ1Vc2Vy
IElEIDIyNTQ2wnwEExYIACYFgmc7qckCF4ACmwMCHgAWIQRxT9PuuFQWBrbG1qTG
zklMbZWW8wAKCRDGzklMbZWW80YLAO0Yq5Q32hDb36xOb0+n8FagD4nJd00g7oZ4
EsOL78cBAJbHTdDHmTy4cpiNumN64TVYoq52N0C82BKGJiV5qd4M
=Y1DF
-----END PGP PRIVATE KEY BLOCK-----

The UID self-sig's Ed25519 signature has an R value of length 237 and an S value of length 256.

I roundtrip it through gnupg like so:

$ rm -rf g
$ mkdir -m 0700 g
$ gpg --homedir g --import example.key
$ gpg --homedir g --export --armor "User ID 22546"
$ rm -rf g

If i round-trip it through gnupg 2.2.45, i get the same signature packet
back out:

0000003c                                       00 ed         eddsa_sig_r_len
0000003e                                             18 ab   eddsa_sig_r
00000040  94 37 da 10 db df ac 4e  6f 4f a7 f0 56 a0 0f 89
00000050  c9 77 4d 20 ee 86 78 12  c3 8b ef c7
0000005c                                       01 00         eddsa_sig_s_len
0000005e                                             96 c7   eddsa_sig_s
00000060  4d d0 c7 99 3c b8 72 98  8d ba 63 7a e1 35 58 a2
00000070  ae 76 37 40 bc d8 12 86  26 25 79 a9 de 0c

If i round-trip it through 2.4.6, i get:

0000003c                                       01 00         eddsa_sig_r_len
0000003e                                             00 00   eddsa_sig_r
00000040  18 ab 94 37 da 10 db df  ac 4e 6f 4f a7 f0 56 a0   
00000050  0f 89 c9 77 4d 20 ee 86  78 12 c3 8b ef c7
0000005e                                             01 00   eddsa_sig_s_len
00000060  96 c7 4d d0 c7 99 3c b8  72 98 8d ba 63 7a e1 35   eddsa_sig_s
00000070  58 a2 ae 76 37 40 bc d8  12 86 26 25 79 a9 de 0c

note the multiple octets of leading zeros.

Details

Version
2.4.6

Event Timeline

after a bit more testing, it looks to me like 2.2.45 will revise the signature packet to use 0x00ed as the MPI header for r, if it receives input from 2.4.6. And 2.4.6 will revise the signature packet to use 0x0100 as the MPI header for r. So the same OpenPGP self-sig will change shape each time it is passed back and forth between the different versions.

2.2. reaches EOL in 6 weeks and thus we won't look at a potential problem with no real world impact.

This is not a bug in 2.2, this is a bug in 2.4.

As for real world impact, this will break any workflow that assumes signatures are bitwise stable. For example:

  • 1pa3pc relies on a digest over the binary contents of the signature packet
  • hockeypuck merges TPKs by deduplicating the packets on each side, using a digest over the raw packet.

In addition, other implementations may reject signature packets with leading zeros in the MPI.

with no real world impact.

Just in case this helps we found this issue during tests in archlinux-keyring: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/277 which uses GnuPG 2.4.

We're happy with how we use GnuPG there for user ID revocations and would like to keep the status quo. If this bug is not considered valid we would have to rewrite the tests to Sequoia's sq but we're really want to avoid doing that (due to time constraints et al.).

Thanks in advance for reconsidering!

dkg added a subscriber: ebo.

@ebo i'm not sure i understand why you removed the gnupg24 (gnupg-2.4.5) project label. the report indicates that GnuPG 2.4.6 at least (other versions untested, but i didn't see a gnupg24 (gnupg-2.4.6) label in this system) produces MPI artifacts for EdDSA/Ed25519 signatures that are non-compliant with all the known specifications. the 2.2 series appears to retain compatible MPI formats.