Open Bug 1755650 Opened 3 years ago Updated 11 months ago

Support using a "message password" to encrypt an email message (OpenPGP)

Categories

(MailNews Core :: Security: OpenPGP, enhancement)

Product:
MailNews Core
Component:
Security: OpenPGP
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Unassigned)

Details

(Whiteboard: [jump to comment 6 for the best idea yet])

The common mechanism to exchange encrypted emails is to use the mechanism called "public key encryption" (where each user owns a public key and a secret key, and the public keys are exchanged between users).

This is the mechanism that Thunderbird already implements.

The "public key encryption" mechanism is convenient when using encryption frequently, because you only have to perform the setup of keys once for each involved person.

Another mechanism is to use a "message password" (symmetric encryption). In this mechanism, the correspondents don't need to setup personal keys, and they don't need to exchange/accept public keys. However, the correspondents must find a way to exchange a secret. (This exchange must not be done by plain text email, of course, but could be done in a personal meeting.)

It has been suggested that Thunderbird should support this "message password" encryption mechanism.

From the technical side, this is trivial to implement.

The challenge here is the user interface. In particular, it would be necessary to clearly distinguish it from our UI guidance for the existing mechanism.

It is possible to combine the mechanisms.

If Alice sends a message to Bob and Carol, then Alice could use the regular public-key mechanism with Bob, and use the message-password mechanism with Carol.

In other words, if Alice already has a public key for Bob, then Alice would have to share a message-password only with Carol. This could allow Alice to send a single encrypted email to both Bob and Carol. Bob would only need to own hist secret key (as usual), and Carol would need to know and enter the shared password to decrypt this message.

I imagine that this mixed approach might be an even bigger challenge for the user interface implementation.

It's unclear if we want to support this mixed approach.

Here are some thoughts around a potential user interface that supports EITHER public-key OR message-password (not mixing).

When using a message password, the usual checks for existing public keys must be turned off. We wouldn't show notifications that a key is missing, we wouldn't show a key assistant (as planned in bug 1627956).

If encryption is turned on, and the user configures the message to use the message-password encryption mechanism, it's necessary that the user defines the message-password, and that's sufficient for sending the message.

We'd need a new button or menu item that allows the user to switch the currently composed message to the message-password mechanism.

The composer UI should display a visual item that informs the user that this special mode is on.

Sending is impossible until the user enters the message password.

It's tricky to decide at which point of the time the composing user should enter the message password.

For example, what happens if:

  • the user starts composing
  • user switches to message-password mechanism
  • users enters the message password
  • user starts writing the message
  • user saves the message as a draft, and closes the window
  • later, the user opens the draft and wants to continue editing the message

The message-password is necessary to send the message.
Would the user expect that Thunderbird has remembered the password, and that finishing the draft and sending the message can be done without having to enter the password again?

I think remembering this password across in a draft message adds an undesirable amount of complexity for the implementation, and if possible, I'd prefer to avoid it.

I suggest to require that the message-password must be set in the same session (open composer window) that will be used to send the message. If the user sends the message as a draft, and later continues editing, then I suggest, the user must again switch the composer window into message-password mode, and define the password that shall be used.

It is possible to define multiple passwords for a single messages.
For example, Alice might already have met with Carol and Charlie, and has exchange different message-passwords with each of them.
If Alice wants to send a single encrypted message to both Carol and Charlie, she would need to define two passwords for the single message (that's possible, when receiving the message, either password would work to decrypt the message).

We'd have to decide if we want to offer using multiple passwords for a single message.

Here are some thoughts around a potential user interface that supports the MIXED approach (use public keys for some users, use a message password for other users).

With this implementation, we wouldn't require global mode switching for the composer window. Using public keys or message passwords would always be possible.

Instead of a global switch to enable message password, this switch would have to be per recipient.

We'd require a UI method to mark individual recipients (of one email) to be excluded from the usual "must have public key" requirement. For example, we could offer a right click menu on the entry in the to/cc field, and offer a menu item "recipient uses message password".

As soon as "message password" has been turned on for at least one recipient, sending is impossible until the local user defines the message password for the current message.

Resolving the "inability to send" situation, which we intend to cover using a "key assistant" in the future, would then have to consider this additional "message password" approach.

The multiple message passwords detail (comment 3) also applies to this implementation approach.

The above comments were all about the composing action.

We also need to discuss the other side, the receiving and unlocking action.

I think we should never save message passwords across sessions. (For the purpose of repeated unlocking, it should be OK to cache them in memory. (Of course, should we implement bug 1741042 in the future, this password cache would have to be covered, too.))

When clicking an encrypted message, that requires a message password to unlock, how should we ask the user to provide the password?

The choices are:

  • automatically prompt for the password, and keep prompting
    until the password works or the user presses cancel.

  • show a placeholder message in the message content area
    (e.g. "this message was encrypted with a message password,
    you need to provide the correct password to decrypt and view"),
    plus a button, e.g. "enter password to decrypt".
    When clicked, we show a prompt, and keep prompting until
    the password is correct, or the user cancels.
    If the user has entered the correct password,
    we refresh the message display and show the decrypted
    message contents.

I'm in favor of (2).

Even with (1), we'd need a fallback display for the message content area,
should the user cancel or not have the right password.

I have a new idea for the user interface.

If OpenPGP encryption is turned on, but encryption isn't possible for at least one recipient, then as of today, we show a notification with the text "End-to-end encryption requires resolving key issues", with buttons "resolve" and "disable encryption".

I suggest we change the text to say:
"To use End-to-end encryption, either resolve key issues for ..., or add a password that recipients can use to decrypt the message."
and we'd add another button: "add password…".

If the user clicks "add password", we'd open a prompt that contains a brief explanation, and gets the users choice for the password.

The explanation could say:
"Adding a message encryption password allows recipients to decrypt the message, either using Thunderbird or using other OpenPGP compatible software. Use a method other than email to share the password with your correspondents that need it."

Below that, I'd offer two choices with a radio button

  • Use a new randomly generated password: <random password showing here>
  • Use the following password: [input box]
    Repeat the password [inbox box]

If the user choses to enter a password, the dialog would have to give feedback whether the user has entered a reasonably strong password.
The dialog should offer the user to either repeat the password, or use an "eye" icon to view what the user types (in that case we don't need them to repeat it).

If the user confirms the dialog, then the composer window changes behavior.

The composer will no longer require that valid and accepted keys are available for all recipients. It would no longer warn at all. Rather, when sending the message, it would encrypt using the public keys that are available, and in addition encrypt using the password. (Decrypting will be possible with EITHER the matching private key that a correspondent owns, OR using the password. So the user has to pass on the password only to those recipients for whom no good public key is available.)

I'd prefer to visualize in some way this current mode of operation. The visualization should mention something like "message encryption password set". Clicking it should allow the user to view, modify, or disable the message encryption password (while still in composer).

In theory, offering this message encryption could work even when the user hasn't set up OpenPGP encryption for themselves. But I think we shouldn't offer it, because it would complicate the UI, it would also be in contradiction to our explanations (which we have in several places) that opting in to email encryption is required by setting a key for the user. We disable the encryption button if the user hasn't yet set up their own OpenPGP key, which would further complicate the UI to get this password based encryption turned on. And finally, if the user (sender) has set up their own encryption key, we'll also encrypt with that key, which means the sender will be able to view the encrypted copy in the Sent folder, even after forgetting/losing the message encryption password.

In other words, I suggest: Only if the user is set up for OpenPGP e2ee already, only then offer the user the alternative to encrypt using a password.

On the recipient side, Thunderbird is able to analyze what's required to decrypt an incoming encrypted message.

If the user doesn't have a matching private key, and the message has an encrypted password set, then we could adjust the user interface accordingly.

We could either prompt the user immediately (please enter the password to decrypt this message) or we could show a notification bar with a button, asking the user to enter it.

Whiteboard: [jump to comment 6 for the best idea yet]

With this approach, the interesting aspect is:
You could immediately send an encrypted email to anyone. Tell the recipient that they could decrypt it using Thunderbird, give them the message password, and they can access the message.

Nickolay, a question regarding the potential implementation in Thunderbird:

I understand I can find out whether a message was encrypted with a password, by using the "dummy" decryption that I've recently implemented based on your advice, and calling rnp_op_verify_get_symenc_count. If it returns a count > 0, it means at least there exists at least one password to decrypt the message, right?

I've recently changed TB to no longer rely on the password callback. I did this by unlocking a secret key that can decrypt the message, prior to calling into RNP APIs for decryption.

If possible, I'd like to avoid the callback for messages that were encrypted with a password, too.

Is that already possible? Is there an API that I could use to add a decryption password to an rnp_op_verify_t, prior to calling rnp_op_verify_execute ?

Flags: needinfo?(o.nickolay)

If it returns a count > 0, it means at least there exists at least one password to decrypt the message, right?

Yeah, that's right.

If possible, I'd like to avoid the callback for messages that were encrypted with a password, too. Is that already possible? Is there an API that I could use to add a decryption password to an rnp_op_verify_t, prior to calling rnp_op_verify_execute ?

Unfortunately there is no such function yet, if you need it we may add, it should be quite easy.

Within current API you may use few-liner like ones we use in our tests for constant password:

rnp_ffi_set_pass_provider(ffi, ffi_string_password_provider, (void *) "password"));

Where password provider is as following:

bool
ffi_string_password_provider(rnp_ffi_t        ffi,
                             void *           app_ctx,
                             rnp_key_handle_t key,
                             const char *     pgp_context,
                             char *           buf,
                             size_t           buf_len)
{
    size_t pass_len = strlen((const char *) app_ctx);
    if (pass_len >= buf_len) {
        return false;
    }
    memcpy(buf, app_ctx, pass_len + 1);
    return true;
}
Flags: needinfo?(o.nickolay)
You need to log in before you can comment on or make changes to this bug.