ERROR key generation error: Unknown signature subpacket: 34 (error 905), gpg (GnuPG) 2.3.1 libgcrypt 1.9.3

[MuhtasimTanmoy]

While importing pgp key, the command below is generating this error: keybase pgp select

Please refer to line number: 120 common/openpgpdefs.h as of gnupg-2.3.1

SIGSUBPKT_PREF_AEAD = 34, /* Preferred AEAD algorithms. */

[prertik]

I ran into this issue too.

[ppaeps]

Does Keybase not support Ed25519 OpenPGP keys?

I get this error when trying to add a new public key. I don't understand why the error message mentions "key generation". I don't need Keybase to generate a key. I need it to spit out a statement for me to sign.

[benmontour]

Same issue here when attempting to import ed25519 OpenPGP generated key using keybase pgp select --import

[markdascher]

I managed to workaround this issue by removing the preferred AEAD algorithms from the public key. Not sure if there's an better way to do it, but the setpref subcommand of gpg --edit-key works. You basically have to run showpref, then copy the whole list except for AEADs (and Uncompressed/Features, which are both implied) into a new setpref command, like this:

% gpg --edit-key mykey

gpg> showpref
[ultimate] (1). mykey
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB, EAX
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify

gpg> setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD: 
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y

[ppaeps]

Unfortunately, this is not working for me.

I modified my public key as @markdascher suggested.

% gpg --edit-key B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B
[... do the thing ...]
% gpg --edit-key B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B
[...]
gpg> showpref
[ultimate] (1). Philip Paeps <philip@trouble.is>
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
[ultimate] (2)  Philip Paeps <philip@freebsd.org>
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify

I verified that the AEAD prefs were actually gone by comparing the output of gpg --list-packets before and after:

% diff -u pubkey.asc.txt pubkey-no-aead.asc.txt
--- pubkey.asc.txt  2021-06-23 13:02:50.000000000 +0800
+++ pubkey-no-aead.asc.txt  2021-06-23 13:18:58.000000000 +0800
@@ -5,39 +5,37 @@
    keyid: BB6D8A14AFE7D96B
 :user ID packet: "Philip Paeps <philip@trouble.is>"
 :signature packet: algo 22, keyid BB6D8A14AFE7D96B
-   version 4, created 1621924124, md5len 0, sigclass 0x13
-   digest algo 10, begin of digest 91 fe
+   version 4, created 1624424244, md5len 0, sigclass 0x13
+   digest algo 10, begin of digest 13 22
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 9 len 4 (key expires after 2y37d5h32m)
+   hashed subpkt 23 len 1 (keyserver preferences: 80)
+   hashed subpkt 25 len 1 (primary user ID)
+   hashed subpkt 33 len 21 (issuer fpr v4 B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B)
+   hashed subpkt 2 len 4 (sig created 2021-06-23)
    hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
-   hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
    hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
-   hashed subpkt 30 len 1 (features: 07)
-   hashed subpkt 23 len 1 (keyserver preferences: 80)
-   hashed subpkt 33 len 21 (issuer fpr v4 B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B)
-   hashed subpkt 2 len 4 (sig created 2021-05-25)
-   hashed subpkt 25 len 1 (primary user ID)
+   hashed subpkt 30 len 1 (features: 05)
    subpkt 16 len 8 (issuer key ID BB6D8A14AFE7D96B)
    data: [256 bits]
-   data: [256 bits]
+   data: [255 bits]
 :user ID packet: "Philip Paeps <philip@freebsd.org>"
 :signature packet: algo 22, keyid BB6D8A14AFE7D96B
-   version 4, created 1621924146, md5len 0, sigclass 0x13
-   digest algo 10, begin of digest c7 b2
-   hashed subpkt 33 len 21 (issuer fpr v4 B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B)
-   hashed subpkt 2 len 4 (sig created 2021-05-25)
+   version 4, created 1624424254, md5len 0, sigclass 0x13
+   digest algo 10, begin of digest 8f e8
    hashed subpkt 27 len 1 (key flags: 03)
    hashed subpkt 9 len 4 (key expires after 2y37d5h32m)
+   hashed subpkt 23 len 1 (keyserver preferences: 80)
+   hashed subpkt 33 len 21 (issuer fpr v4 B851CD3AC248F2ED3E2CC18CBB6D8A14AFE7D96B)
+   hashed subpkt 2 len 4 (sig created 2021-06-23)
    hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
-   hashed subpkt 34 len 2 (pref-aead-algos: 2 1)
    hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
    hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
-   hashed subpkt 30 len 1 (features: 07)
-   hashed subpkt 23 len 1 (keyserver preferences: 80)
+   hashed subpkt 30 len 1 (features: 05)
    subpkt 16 len 8 (issuer key ID BB6D8A14AFE7D96B)
-   data: [253 bits]
-   data: [255 bits]
+   data: [256 bits]
+   data: [256 bits]
 :public sub key packet:
    version 4, algo 22, created 1621924204, expires 0
    pkey[0]: [80 bits] ed25519 (1.3.6.1.4.1.11591.15.1)

Selecting that key from keybase select pgp --multi still returns the same error:

▶ ERROR key generation error: Unknown signature subpacket: 34 (error 905)

[chloeruka]

@ppaeps I ran into this just before when I added another uid via adduid using GnuPG on a key generated with Keybase; the answer in your case might be to remove any additional "Features" listed in the preferences. I couldn't find a list of feature switches from a quick google, but for me what worked was to append ks-modify no-mdc to the end of the preference string.

Example:

gpg --expert --edit-key YOURKEYID
gpg> setpref AES AES256 CAST5 3DES SHA256 SHA512 SHA1 RIPEMD160 ZIP ZLIB ks-modify no-mdc
Set preference list to:
     Cipher: AES, AES256, CAST5, 3DES
     AEAD:
     Digest: SHA256, SHA512, SHA1, RIPEMD160
     Compression: ZIP, ZLIB, Uncompressed
Really update the preferences? (y/N) y
gpg> save

And then I was able to keybase pgp update.

[ppaeps]

Hooray! That worked.

Thanks @chloeruka!

[nottoseethesun]

I have the same issue, but the fix that worked for @ppaeps is not working for me:

To try to fix, I did this:

setpref AES256 AES192 AES 3DES OCB EAX SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed MDC ks-modify no-mdc

The pref set is accepted, I accept (y), quit and save. Then did keybase pgp update.

Still the same error when I try to select that key for keybase pgp select. It's on a YubiKey that's plugged into the computer.

More info:

gpg> showpref
[ultimate] (1). foobar (batbaz) <bar@bat.com>
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB, EAX
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: AEAD

gpg>

As a side note, I could not add "AEAD" in the prefs list, for it complained that it is an invalid option. But it always appears under "fetaures". Prior to the set, I had "Keyserver no-modify" (which I don't care about), and after the set, it is gone.

[ppaeps]

@nottoseethesun You want to remove the AEAD prefs from your list, so your setpref line should read:

setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed ks-modify no-mdc

As I understand it, the Features: line shows up automatically and lists AEAD if any AEAD forms (e.g. OCB, EAX) appear in the cipher preference list. Likewise, it'll list MDC unless ks-modify no-mdc is given, as suggested by @chloeruka.

[ppaeps]

@nottoseethesun Note that these manipulations shouldn't affect your YubiKey in any way. As I understand it, the preferences are part of the public key and your YubiKey really only cares about private keys. Having said that, it's been a while since I looked closely at OpenPGP.

Before uploading my public key anywhere (either with Keybase or anything else), I always very carefully check with gpg --list-packets what has changed. I like to store my public keys in Git and have this snippet in my .gitconfig:

[diff "asc"]
    textconv = "f(){ gpg --list-packets < \"$1\" | grep -v \"^# off=\"; }; f"

The output of that is very slightly more lucid than a big blob of base64. ;-)

I only uploaded public key with the modified cipher preference list to Keybase. Other sources of my public key have the previous preference list (i.e. the defaults as set by GnuPG when I generated the key). So far, this doesn't seem to have upset the delicate balance of the universe.

[nottoseethesun]

@ppaeps Thanks; got rid of AEAD as you suggested and now this key is working great with Keybase.

[yuliu]

Why doesn't Keybase fix this issue?

[chipbuster]

Can anyone give a short overview of the implications of changing the default settings as suggested by the current workaround? (Or a link to such documentation---google has pulled up many scattered and incomplete results, but nothing definitive).

I did find a gist that suggests that "reasonably secure defaults" are no-ks-modify and mdc, but I still don't know what these actually do.

[4czr]

@ppaeps I ran into this just before when I added another uid via adduid using GnuPG on a key generated with Keybase; the answer in your case might be to remove any additional "Features" listed in the preferences. I couldn't find a list of feature switches from a quick google, but for me what worked was to append ks-modify no-mdc to the end of the preference string.

Example:

gpg --expert --edit-key YOURKEYID
gpg> setpref AES AES256 CAST5 3DES SHA256 SHA512 SHA1 RIPEMD160 ZIP ZLIB ks-modify no-mdc
Set preference list to:
     Cipher: AES, AES256, CAST5, 3DES
     AEAD:
     Digest: SHA256, SHA512, SHA1, RIPEMD160
     Compression: ZIP, ZLIB, Uncompressed
Really update the preferences? (y/N) y
gpg> save

And then I was able to keybase pgp update.

This worked perfectly, thanks dude!

[ppaeps]

On 2022-02-08 01:38:57 (+0800), Kevin Song wrote:

Can anyone give a short overview of the implications of changing the default settings as suggested by the current workaround? (Or a link to such documentation---google has pulled up many scattered and incomplete results, but nothing definitive).

The ks-modify option controls the No-Modify key server preference specified in RFC 4880 section 5.2.3.17. In practice I think it means key servers should reject updates that are not accompanied by a self-signature. This bit is irrelevant for Keybase since it needs you to authenticate to update/modify your key.
Keybase doesn't support something like "gpg --send-key" which would allow arbitrary updates to your key.

The no-mdc option will clear the Modification Detection feature flag on the public key. This is in RFC 4880 section 5.2.3.24. Clearing that bit might cause some OpenPGP implementations to mistakenly determine that your OpenPGP implementation doesn't support MDC, an integrity protection mechanism that defies any attempts at a short overview. The practical implication is that you might get encrypted messages without integrity protection bits. If those messages are not also signed, they may have been modified after being encrypted.

Note that if you only clear these bits on the public key you upload to Keybase, they only affect people who get your public key from there. If they subsequently get an update to your key from somewhere else, they may see the mdc and ks-no-modify bits (and the AEAD prefs). Moreover, implementations may decide to use MDC even in the absence of the feature flag on the latest self-signature.

Recent versions of GnuPG will always use MDC if AEAD is not available.
GnuPG has also warned about missing integrity protection for years.
More recent versions of GnuPG will refuse to decrypt by default if there is no integrity protection.

To summarise the summary, I believe that clearing these bits is probably harmless under most circumstances. You can further mitigate any downsides by only clearing the bits on the copy of the public key you upload to Keybase and providing other ways for people to get your public key (e.g. WKD or other keyservers).

[chipbuster]

@ppaeps Thank you so much, that was very helpful!

[3OG]

getting this issue aswell.

[drin]

I just wanted to add that I was able to leave MDC in (I did not set no-mdc). From @ppaeps comment, it seemed like it would be nice to check.

I also confirmed that having both OCB and EAX failed, as well as EAX and not OCB. I didn't try OCB only since it seemed unlikely to work.

I also did not try to omit ks-modify

[omBratteng]

I just had issues with this, AEAD was set to nothing, yet I could see subpkt 34 when I listed out the packets. My issue was because I renew my keys every 3 months, I have a lot of signatures of my keys. Where one of the older ones might've had AEAD set to something.

To see old signatures, you can run the following

gpg --list-signatures <MY_KEY_ID>

And to remove old signatures, you run this. Which will remove old signatures.

gpg --edit-key <MY_KEY_ID>
gpg> minimize
gpg> save

[slezercc]

does anyone have a fix? I've been having this issue for like a year now. How do I fix this?

[drin]

does anyone have a fix? I've been having this issue for like a year now. How do I fix this?

have any of the above methods worked for you?

[chloeruka] proposed a work around. many comments afterwards are experiences about other options and workarounds. If you need more help, it would be useful to know what you've tried.

[Discere8]

I too have observed that Key Pairs created on gpg4win do not work on OpenKeyChain and Key Pairs created on OpenKeyChain do not work on gpg4win.

I understand that in order to be secure there has to be a Robust process to key creation, export, import, encryption, and decryption; however, I am relatively computer literate and I have found this attempt at cross platform file sharing, (Windows to Android and Android to Windows) to be extremely frustratingly difficult. The average Windows and Android user would not even try this again after the problem is fixed. If software developers hope to see their products used by more than a small cadre of coders, there has to be a more streamlined method for sharing keys between pc and smartphone.

Please fix this issue as soon as practicable.

Many thanks.

[kbrock]

Ok, this worked for me. This is trying to follow what was specified above.; Thanks for the help, and corrections would be appreciated.

# keybase login
[...]
# gpg -k --keyid-format SHORT

/Users/jcool/.gnupg/pubring.kbx
--------------------------------
pub   rsa4096/99999999 2022-01-01 [SC]
[...]

# gpg --edit-key 99999999 # part right after the `rsa9999/` bit
gpg> pref
[ultimate] (1). Joe Cool <joe@example.com>
     S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]
gpg> showpref
[ultimate] (1). Joe Cool <joe@example.com>
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify

gpg> setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed mdc no-ks-modify
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y
gpg> quit
Save changes? (y/N) y
# keybase pgp select --import

• The pref shows the defaults. No surprise, those are the values used in the current keys. (possibly a little cryptic)
• The setpref value to use is the current values with the OCB / AEAD values removed.
• The MDC and no-ks-modify are auto added (per the pref) unless you pass in the no-mdc or ks-modify respectively.
• Calling setpref with no values will set to the default, probably the value you had before.

[x86txt]

Thanks for the help, and corrections would be appreciated.

This worked perfectly on my gpg4win & Windows 11 combo.

Note

You forgot the Uncompressed feature in the Compression list (not sure if it matters or not?), but just adding it between ZIP and mdc worked perfectly fine.

setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed mdc no-ks-modify

[ShotgunPR]

Thanks @chloeruka!

Your recommendation worked! Was almost tempted to crash into a wall before reading this!

[alexkubica]

Ok, this worked for me. This is trying to follow what was specified above.; Thanks for the help, and corrections would be appreciated.

# keybase login
[...]
# gpg -k --keyid-format SHORT

/Users/jcool/.gnupg/pubring.kbx
--------------------------------
pub   rsa4096/99999999 2022-01-01 [SC]
[...]

# gpg --edit-key 99999999 # part right after the `rsa9999/` bit
gpg> pref
[ultimate] (1). Joe Cool <joe@example.com>
     S9 S8 S7 S2 A2 H10 H9 H8 H11 H2 Z2 Z3 Z1 [mdc] [aead] [no-ks-modify]
gpg> showpref
[ultimate] (1). Joe Cool <joe@example.com>
     Cipher: AES256, AES192, AES, 3DES
     AEAD: OCB
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, AEAD, Keyserver no-modify

gpg> setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP mdc no-ks-modify
Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N) y
gpg> quit
Save changes? (y/N) y
# keybase pgp select --import

• The pref shows us the defaults. No surprise, those are the values used in my keys. (possibly a little cryptic)
• The setpref value to use is basically the current values, just with none of the AEAD values.
• The MDC and no-ks-modify are auto added (per our pref) unless we pass in the no-mdc or ks-modify respectively.
• just calling setpref without any args will set to the default, probably the value you had before.

can confirm this worked for me, thanks!

[selfagency]

not a single one of the above solutions works for me unfortunately

[drin]

@selfagency want to share the commands and their results?

[ppaeps]

For what it's worth: the incantation in my comment in this discussion from 2021-07-27 still works as of 2023-05-08 (and is still required to work around the issue).

[Kounavi]

I also get ERROR key generation error: Unknown signature subpacket: 34 (error 905) after running keybase pgp select --import. Has this been fixed?

[Kamek437]

@nottoseethesun You want to remove the AEAD prefs from your list, so your setpref line should read:

setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed ks-modify no-mdc

As I understand it, the Features: line shows up automatically and lists AEAD if any AEAD forms (e.g. OCB, EAX) appear in the cipher preference list. Likewise, it'll list MDC unless ks-modify no-mdc is given, as suggested by @chloeruka.

Worked for me, thanks man!

[iseki0]

Why keybase doesn't fix it?

[saltbo]

arrived here one year ago...

[sgloutnikov]

Has anyone gotten the workaround in this thread to work with a key having multiple identities? I removed AEAD from my key but still am getting the ▶ ERROR key generation error: Unknown signature subpacket: 34 (error 905) error when doing keybase pgp select. Maybe it's not the multiple identities but that's the only difference I'm seeing from the comments above. Lastly, the RSA key (2) selects fine.

gpg --version
gpg (GnuPG) 2.4.5
libgcrypt 1.10.3

keybase --version
keybase version 6.2.8-20240305171439+e38523abbe

keybase pgp select
#    Algo    Key Id             Created   UserId
=    ====    ======             =======   ======
1    256?    SSSSSSSSSSSSSSSS             Stefan Gloutnikov <a@b.com>, Stefan Gloutnikov <c@d.com>
2    4096R   TTTTTTTTTTTTTTTT             Stefan Gloutnikov <a@b.com>, Stefan Gloutnikov <c@d.com>
Choose a key: 1
▶ ERROR key generation error: Unknown signature subpacket: 34 (error 905)

gpg --expert --edit-key SSSSSSSSSSSSSSSS

sec  ed25519/SSSSSSSSSSSSSSSS
     created: 2024-03-31  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  cv25519/UUUUUUUUUUUUUUUU
     created: 2024-03-31  expires: 2029-03-30  usage: E
ssb  ed25519/VVVVVVVVVVVVVVVV
     created: 2024-03-31  expires: 2029-03-30  usage: SA
[ultimate] (1). Stefan Gloutnikov <a@b.com>
[ultimate] (2)  Stefan Gloutnikov <c@d.com>

gpg> showpref
[ultimate] (1). Stefan Gloutnikov <a@b.com>
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
[ultimate] (2)  Stefan Gloutnikov <c@d.com>
     Cipher: AES256, AES192, AES, 3DES
     AEAD:
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed

[purpleidea]

I'm experiencing this issue when using kbpgp js package: https://github.com/keybase/kbpgp

What's most unusual, is that I have the code and my key on a static website, and it used to work, but at some point it stopped working without me changing any of the code :/

Kind of suspicious... How is that even possible if the libraries aren't interacting with the outside world somehow?

[ppaeps]

Has anyone gotten the workaround in this thread to work with a key having multiple identities?

There are multiple identities on the key I've used this workaround on. I've used the same workaround on the same key a couple of times now (annual self-signature to extend the expiry date).

I removed AEAD from my key but still am getting the ▶ ERROR key generation error: Unknown signature subpacket: 34 (error 905) error when doing keybase pgp select. Maybe it's not the multiple identities but that's the only difference I'm seeing from the comments above. Lastly, the RSA key (2) selects fine.

I have found gpg --list-packets very helpful to debug this kind of problem. I don't see anything immediately wrong with the output you've posted, but maybe a closer look at the packets will help.

[sgloutnikov]

I may have previously been editing the identities incorrectly. Regenerated an entirely new set of keys, edited each preferences per the workaround and this time it imported into Keybase! Thank you for the help!

gpg --edit-key a@b.com
setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed mdc no-ks-modify
quit (and save)
gpg --edit-key c@d.com
setpref AES256 AES192 AES 3DES SHA512 SHA384 SHA256 SHA224 SHA1 ZLIB BZIP2 ZIP Uncompressed mdc no-ks-modify
quit (and save)
keybase pgp select

[handsomexdd1024]

It seems that the new AEAD implementation specific to gnupg (OCB) is responsible for this error:

With gnupg 2.4, gpg generates keys, which advertise support for a GnuPG specific AEAD encryption mechanism (based on OCB). However, this flavor of AEAD is not supported by other OpenPGP implementations!

This article describes how to disable unsupported AEAD features, it works perfectly for me.

Any key generated with gnupg 2.4.x is expected to have AEAD features enabled by default.

[kenkit]

This worked for my javacard key tool

[samj]

The cloud brain believes that these changes are a terrible, horrible, no good, very bad idea, but rather than quoting what may be hallucinations I'm just going to suggest that you completely understand the changes you're making before making them.

At first I was disappointed Keybase wasn't keeping up with the times (which may well be the case), but it sounds like GPG has some answering to do in terms of deliberately deviating from the IEFT process and introducing incompatible changes.

Arch Linux have some strong views on this topic which I'll leave you to see for yourself. At the very least Keybase should introduce more useful errors, but with so many GPG users they should probably accept its defaults too.

[ppaeps]

I would be interested in learning more about why these changes are terrible, horrible, no good, very bad idea. With references please.

In https://github.com/keybase/keybase-issues/issues/4025#issuecomment-1032186446 (2022) I summarised my understanding of the modifications and why I think they're harmless. Moreover, removing the AEAD feature seems to align with the suggestion on the Arch Linux wiki you cite.

If you're concerned about removing the GnuPG-specific AEAD bits, consider signing encrypted messages. Or treating unsigned encrypted messages with suspicion.

I agree that Keybase could be more helpful in supporting recently generated keys with the most widely used OpenPGP implementation.

(I don't think this issue is a good place to argue GnuPG/LibrePGP/OpenPGP.)