In my case, it doesn't have an EC subkey; the key is DSA 1024, with ElGamal 2048 and DSA 2048 subkeys. The error I'm getting is
We were unable to encrypt a test message with this key
The export command I'm using is:
gpg --armor --export-options export-minimal --export email@example.com
This may be another case of a gpgy bug, but filing just in case it isn't.
I'm also having this issue, with this key: https://keybase.io/rx14/pgp_keys.asc
The only unusual part of my keys, is that the first UID has been revoked, and replaced (name change)
BTW, my key can be retrieved from most public keyservers; I know it's up-to-date at keys.gnupg.net. The key ID is 09E5788F. For testing:
gpg --receive-keys --keyserver keys.gnupg.net 09E5788F
My issue is a pgpy bug, since my first UID is revoked, pgpy thinks neither uid is primary.
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3.8/site-packages/pgpy/decorators.py", line 129, in _action return action(_key, *args, **kwargs) File "/usr/lib/python3.8/site-packages/pgpy/pgp.py", line 2185, in encrypt cipher_algo = prefs.pop('cipher', uid.selfsig.cipherprefs) IndexError: list index out of range
>>> key.userids.is_primary False >>> key.userids.is_primary False >>> key.userids.selfsig <PGPSignature [CertRevocation] object at 0x7f852cdb5550> >>> key.userids.selfsig <PGPSignature [Positive_Cert] object at 0x7f852cdb5bb0> >>> key.userids.selfsig.cipherprefs  >>> key.userids.selfsig.cipherprefs [<SymmetricKeyAlgorithm.AES256: 9>, <SymmetricKeyAlgorithm.AES192: 8>, <SymmetricKeyAlgorithm.AES128: 7>]
Oh, this could definitely be it for me too. I have had my key since 1999 and have several revoked UIDs, many which predate my current primary ID.
A quick search in the pgpy project's issue tracker didn't turn up any issues with the
is_primarymethod, so they either aren't aware of it or there's something else going on.
Can you post a snippit of the commands you used to get to your keys using
pgpyin the interpreter?
key = pgpy.PGPKey.from_blob(keytext) msg = pgpy.PGPMessage.new("foooo") # To get the backtrace for the failure on meta.sr.ht key.encrypt(msg)
Then you can see the commands I used above.
I can confirm, I also have that issue when using a key where the former primary id was revoked.
My primary key is 3072 DSA with 4096 RSA and 3072 Elgamal subkeys, none of them were revoked though and only one, in the middle of it, expired last year. Same error happening.
Same issue happening with me as well, also the first UID revoked. Seems to be a systemic issue
Two issues for me:
- My srht account email address did not match my gpg key address (my bad)
- There's a bug where pgpy will silently fail if no cipher preference is found on the public key: https://github.com/SecurityInnovation/PGPy/issues/304
Once I managed to add my key,
meta.sr.htused the wrong uid email because it simply grabs the first uid in the list: https://git.sr.ht/~sircmpwn/meta.sr.ht/tree/master/item/metasrht/types/pgpkey.py#L58
Once I removed the revoked uid, meta.sr.ht picked up the correct email address.