ERROR key generation error: Unknown signature subpacket: 34 (error 905), gpg (GnuPG) 2.3.1 libgcrypt 1.9.3 #4025
Comments
|
I ran into this issue too. |
|
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. |
|
Same issue here when attempting to import ed25519 OpenPGP generated key using |
|
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 |
|
Unfortunately, this is not working for me. I modified my public key as @markdascher suggested. I verified that the AEAD prefs were actually gone by comparing the output of Selecting that key from |
|
@ppaeps I ran into this just before when I added another uid via 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> saveAnd then I was able to |
|
Hooray! That worked. Thanks @chloeruka! |
|
I have the same issue, but the fix that worked for @ppaeps is not working for me: To try to fix, I did this: The pref set is accepted, I accept ( Still the same error when I try to select that key for More info: 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. |
|
@nottoseethesun You want to remove the AEAD prefs from your list, so your As I understand it, the |
|
@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 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. |
|
@ppaeps Thanks; got rid of |
|
Why doesn't Keybase fix this issue? |
|
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 |
This worked perfectly, thanks dude! |
|
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](https://datatracker.ietf.org/doc/html/rfc4880#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](https://datatracker.ietf.org/doc/html/rfc4880#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).
|
|
@ppaeps Thank you so much, that was very helpful! |
|
getting this issue aswell. |
|
I just wanted to add that I was able to leave I also confirmed that having both I also did not try to omit |
|
I just had issues with this, 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 |
|
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. |
|
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. |
|
Ok, this worked for me.
|
This worked perfectly on my gpg4win & Windows 11 combo.
|
|
Thanks @chloeruka! Your recommendation worked! |
can confirm this worked for me, thanks! |
|
not a single one of the above solutions works for me unfortunately |
|
@selfagency want to share the commands and their results? |
|
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). |
|
I also get ERROR key generation error: Unknown signature subpacket: 34 (error 905) after running |
Worked for me, thanks man! |
|
Why keybase doesn't fix it? |
|
arrived here one year ago... |
Updated gpg.conf to generate keys compatible with Keybase by adding the ks-modify and no-mdc default key preferences as documented here: keybase/keybase-issues#4025 Signed-off-by: Drwsburah <Drwsburah@yahoo.com>
|
Has anyone gotten the workaround in this thread to work with a key having multiple identities? I removed |
|
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? |
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 have found |
|
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! |
|
It seems that the new AEAD implementation specific to gnupg (OCB) is responsible for this error:
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. |
|
This worked for my javacard key tool |
and others
While importing
pgpkey, the command below is generating this error:keybase pgp selectPlease refer to
line number: 120common/openpgpdefs.h as of gnupg-2.3.1SIGSUBPKT_PREF_AEAD = 34, /* Preferred AEAD algorithms. */The text was updated successfully, but these errors were encountered: