1941457 - In the Message Security panel, the openpgp-other-enc-* strings are used in the wrong scenarios

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[Calum Mackay]

Perhaps I'm thinking of this backwards, but I'm confused by the Message Security panel, when I receive an OpenPGP encrypted email.

Someone has just sent me a signed, encrypted email. The Message Security panel, in its bottom box, says:

The message was encrypted to the owners of the following keys:

and then shows the key of the sender.

Does this make sense? "encrypted to", surely should show my key, as the recipient?

Changing it to "encrypted by" wouldn't make sense, either: for encryption we use the public key of the recipient, and the sender's key is only used for signing (which is happening here, but the box says "encrypted").

Or am I missing the point?

===

Daily 136.0a1 (2025-01-13) (64-bit); MacOS 13.7.1

Comment 1

[Magnus Melin [:mkmelin]]

I can confirm. But it would normally encrypt to your own key as well (so you can read your sent mail in the sent folder). Maybe it's just an incomplete listing...

Comment 2

[Magnus Melin [:mkmelin]]

Actually, it's working as expected. Before that note, you'll see "Your decryption key id".
I guess the UI would be more natural have it all in one list, with "you" listed first...

Comment 3

[Calum Mackay]

thanks very much Magnus.

Are you saying that TB also sends via SMTP encrypted text that was encrypted using the sender's public key, merely so that it can be read in the sender's Sent Mail, which is (likely) written via IMAP. What's the point of sending that to the recipient via SMTP? [Note that the sender did not Cc themselves]

Wouldn't that also mean that if the sender is careless with their own private key, the message can be intercepted and read, even without my (recipient) private key? That seems like a slight lessening of security?

And I'd still argue that the final box in Message Security is confusing, and needs adjustment, even if just to add "also" :)

Comment 4

[Magnus Melin [:mkmelin]]

Encryption happens before. What gets sent over SMTP is also the blob that gets stored in the Sent folder.
It's encrypted to the sender's public key. I don't see how this would be less secure, and I believe this is common practice - you do want to be able to read what you sent, e.g. to verify or recall details.
Sure, you of course need to careful with your private key, but that is very core to encryption. If you disclose that, all is lost.

Comment 5

[Calum Mackay]

Thanks Magnus. I'll take your word on it being common practice.

The reason I mentioned it was a long-held belief that, when encrypting a message (not necessarily an email), with public key encryption (not necessarily PGP), then the message can only be decrypted using the private key of the intended recipient of the message.

I wasn't aware that, when this is translated to email, that the message will also be readable if you have the private key of the sender. I can see that this would be useful for the Sent folder, although I don't see that this translates to it having to be sent over SMTP. i.e. I see your comment that this is because what is sent over SMTP is the same blob, as an implementation detail.

Anway, fair enough on the above.

===

What remains, I believe, is that the Message Security panel remains confusing, especially if you're not aware of the above implementation detail (common practice, as you say).

May I request it please be considered to change the panel, e.g. even as simply as to add "also"?

The message was also encrypted to the owners of the following keys

thanks again.

Comment 6

[Kai Engert [:KaiE:]]

I agree with the suggestion to improve the wording of the bottom introduction sentence. Maybe it could simply be prefixed by the word "Additionally"

Regarding the multiple encryption:

We only send a single message. But a trick is used to make the message decryptable by multiple keys.

The email contents itself are encrypted using a "symmetric session key" which was randomly chosen.
That makes sense, because symmetric encryption is faster than asymmetric encryption.

That encrypted data (the ciphertext) is prefixed by a header section. That header section has multiple entries, one for each recipient. Each entry in the header contains the session encrypted, asymmetrically encrypted for the respective recipient.

Comment 7

[Kai Engert [:KaiE:]]

I notice we already have a string starting with "in addition" prepared, but we have a bug in the logic to select the string for display.

Comment 8

[Kai Engert [:KaiE:]]

The use of two alternative strings is swapped.

Also, when we don't have the name of an encryption key, our current code would incorrectly display the text "The message was encrypted to the owners of the following keys" twice!

Comment 9

[Kai Engert [:KaiE:]]

Attachment: Bug 1941457 - Fix the use of the openpgp-other-enc-* strings. r=mkmelin

Comment 10

[Kai Engert [:KaiE:]]

This regression was introduced by bug 1647039.
https://hg.mozilla.org/comm-central/rev/c8edbf65b666

Originally, openpgp-other-enc-additional-key-ids was used when myIdToSkipInList was true.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/64a7cc88d613
Fix the use of the openpgp-other-enc-* strings. r=mkmelin