Open Bug 1909073 Opened 2 years ago Updated 1 year ago

Thunderbird attempts to decrypt with the wrong pgp key

Categories

(MailNews Core :: Security: OpenPGP, enhancement, P5)

Thunderbird 115
enhancement

Tracking

(Not tracked)

People

(Reporter: morgan, Unassigned)

Details

Thunderbird: 115.12.0
GPG: 2.2.40
OS: Debian 12 (bookworm)

This may be a weird intersection of circumstances, but it is definitely weird and unexpected.

I have two accounts, each with their own private gpg key setup using an External GnuPG Key (specifically yubikeys, but I suspect that doesn't matter). Both are configured correctly, and when sending email the correct authentication dialog for each respective key.

However, if I receive an email which is encrypted with both keys, then Thunderbird will attempt to decrypt the message with the wrong key (for one of the accounts). It's like Thunderbird is seeing the message is encrypted with some set of keys, and asks gpg if it knows about the keys in order, rather than only attempting to decrypt with the key associated with the account.

So to summarize, for a given encrypted email sent to both accounts, it seems the key use order is the same for each. IE If account A and account B receive messages encrypted with both of their keys, they will both first try key A, and then key B (rather than only trying with their own keys). So in this example account A sees no issue, but account B sees a request for account A's gpg key credentials! Of course, if account A decides not to decrypt the message, then it will get a popup for account B's credentials.

It's mostly a weird UX, to be working in the context of one email account with one of my keys plugged in, for Thunderbird/gpg to then request that I plug in my other yubikey for my other account to decrypt a message that is encrypted with both accounts' keys.

When decrypting, Thunderbird will not make any attempt to request the use of a specific key.

It simply asks the OpenPGP engine (RNP or external GnuPG) to decrypt the message, and hopes that the engine will find a secret key that works.

morgan, does that explain it?

Can we close this bug?

Flags: needinfo?(morgan)

(In reply to Kai Engert (:KaiE:) from comment #2)

morgan, does that explain it?

Can we close this bug?

So it explains why it happens but it seems to me it shouldn't happen. Do these OpenPGP engines support somehow only trying to decrypt with a particular key? Presumably encrypt+sign operations support this given one can use multiple keys on multiple accounts without crossing the streams.

One could imagine a scenario where someone accidentally bricks their security token if they input the wrong pin multiple times because they don't realise the GPG agent is actually asking for foo's credentials, despite being in bar's Thunderbird account.

Another potential problem is a malicious actor wants to determine if foo@hotmail.com is the same person as bar@hotmail.com, by sending foo an email with some tracking element encrypted with bar's key (and the user happens to have bar's yubikey plugged in and decrypts without thinking).

Does that make sense?

Flags: needinfo?(morgan)
Flags: needinfo?(kaie)

I have never tried to investigate if such key-specific decryption APIs exist.
I briefly looked, but couldn't immediately find anything like that in RNP or GPGME.

After you asked for decrypt, you can get information which of your keys was used to decrypt, but I see no way to limit which keys shall be allowed prior to requesting decrypt.

The prompt to unlock a key should tell the use an identification property, so the user can be aware.

In theory, the application could use separate, and reduced, in-memory keyrings, and when asking to decrypt, the application could give only the reduced keyring to the decrypt operation.

This is the first time I hear such a request. And while I could see how it could potentially be done with RNP, it sounds like you are using GnuPG, and I don't know how that would be done there. It would require some special configuration.

In my opinion, if the user wants to protect themselves against accidentally using the wrong key, they should go the extra mile and setup isolated environments, for example by using separate Thunderbird profiles, and if GnuPG shall be used, e.g. environment variables that point to different key storage directories.

Flags: needinfo?(kaie)

While this could be an enhancement request, I see it as very special, and given it is for users who explicitly want to disable the convenience of automatically chosing the correct decryption key (which includes also using older keys the user might still have for older message), I think it should be solved by the user at the application configuration level (separate profiles).

Severity: -- → N/A
Type: defect → enhancement
Priority: -- → P5

In the case of old keys it seems like that could/should also be configured in the client (i.e. a legacy keys list). In any event, I realise this is probably just a more fundamental problem with GPG and there's only so much Thunderbird can do to wrap it with a better UX.

You need to log in before you can comment on or make changes to this bug.