Mutt says: “error encrypting data: Unusable public key”

Today, I replied to an encypted mail, and right after the last “yes, go ahead, send this stuff already”, my mail client mutt showed an error:

error encrypting data: Unusable public key

Hu? What would “unusable” mean here? The message when all PGP keys are expired looks quite a bit different. And indeed, the key in question was not expired at all:

$ gpg --list-keys person@example.net
pub   rsa4096/0xDEEEEEEEEEEEEEEE 2015-03-21 [SCA] [expires: 2023-02-01]
      FINGERPINTWITHHELDFINGERPRINTWITHHELDFIN
uid                   [  full  ] Person <person@example.net>

– this should do for another year or so. Or should it?

Feeding the message to a search engine brings up quite a few posts, most of them from times when keyservers would mess up subkeys, i.e., the cryptographic material that is used to actually encrypt stuff (as opposed to the main key that usually just authenticates these subkeys).

This obviously did not apply here, since keyservers have long been fixed in this respect. But subkeys were the right hint. If you compare the output above with what such a command will output for the feedback key for this blog:

$ gpg --list-keys zuengeln@tfiu.de
pub   rsa3072/0x6C4D6F3882AF70AD 2021-01-28 [SC]
      60505502FB15190B10DBF1436C4D6F3882AF70AD
uid                   [ultimate] Das Engelszüngeln-Blog <zuengeln@tfiu.de>
sub   rsa3072/0x3FCFC394D8DF7140 2021-01-28 [E]

you'll notice that the Person's key above does not have a sub line, i.e., there are no subkeys.

How can that happen? Gnupg won't create such a thing without serious amounts of coercion, and such a key is largely useless.

Well, it turns out it doesn't happen. The subkeys are there, gnupg just hides them because that's what it does with expired subkeys by default. If you override that default, you'll get:

$  gpg --list-options show-unusable-subkeys --list-keys person@example.net
pub   rsa4096/0xDEEEEEEEEEEEEEEE 2015-03-21 [SCA] [expires: 2023-02-01]
      FINGERPINTWITHHELDFINGERPRINTWITHHELDFIN
uid                   [  full  ] Person <person@example.net>
sub   rsa4096/0xEEEEEEEEEEEEEEEE 2015-02-01 [E] [expired: 2020-01-31]
sub   elg4096/0xEEEEEEEEEEEEEEEE 2020-02-01 [E] [expired: 2022-01-31]

So, that's the actual meaning of the error message about „Unusable public key“: “No usable subkey”.

What's a fix for that? Well, for all I know you cannot force gnupg to encrypt for an expired key, so the way to temporarily fix things (for instance, to tell people make their keys permanent[1]) is to turn the clock. There's the nice program faketime that just changes the time for whatever runs below it. That's great because on modern computers, changing the system time has all kinds of ugly side effects (not to mention you'd have to kill the ntpd that your computer quite likely runs to keep your computer's clock synchronised with the rest of the world).

Since I'm using mutt as a mailer, I'd use faketime like this:

faketime 2022-01-31 mutt

I'm fairly confident this would work with, say, thunderbird as well, though it might be a problem if the times of an X server and client are dramatically different.

But that's really no substitute for an updated key: In most people's mailboxes, such mails will be way down in the swamp of rotting mails from one month ago[2] And mail servers sometimes refuse to transport mail that's so far from the past.

Then again, to my own surprise, everytime I had to go to such extremes because I didn't have a non-expired key, the recipients eventually noticed.

[1]Let me again advertise non-expiring keys. The main arguments for these are that (a) essentially nobody directly attacks keys, so it really doesn't matter if a key is used for a decade or more, and (b) PGP is hard enough for muggles even without auto-destructing keys. The net effect of expiring keys on privacy is thus negative, because they keep people off using PGP and even trying to understand crypto. And you can always revoke keys, in particular when we have educated people to now and then sync their keyring with keywervers.
[2]As a side note: While inbox zero sounds to much like one of those market-radical self-improvement fads to me, I've been religious about less-than-a-page inbox for the past decade or so and found it did improve a relevant part of my life.
Kategorie: edv

Letzte Ergänzungen