1679278 - Thunderbird: Support a separate, user defined OpenPGP passphrase, and the ability to relock secret keys after use

Status: RESOLVED FIXED

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

Description

[Kai Engert (:KaiE:)]

Currently, Thunderbird uses a randomly created passphrase to protect the OpenPGP key files managed by Thunderbird. The random passphrase is optionally protected using the master password.

Some users are concerned that the master password mechanism isn't sufficiently strong to protect the OpenPGP keys. (See also bug 973759.)

The suggestion is to implement a feature, that allows users to protect the OpenPGP secret keys using passphrases that are chosen by the user, and using the cryptographic code of the OpenPGP library.

Thunderbird could have a single pref, that could disable the use of the automatic passphrase mechanism. When importing keys, Thunderbird could keep the existing passphrase protection. When generating new keys, Thunderbird could ask the user to define the individual passphrase for the new key. Whenever using the secret key, Thunderbird could prompt the user to enter the individual passphrase for the respective key.

Comment 1

[User48756]

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

Hi Kai,
there are so many complains about this, don't you think it may be worth to think about this topic once again.

There is so much to do and it seems that only "your" OpenPGP counts.
I use TB with windows 10 and every day (really every day) when finishing TB it reports:
"sorry some problems happend.
please choose restart or finish TB.
Error Report is send"
Every day an error report is send (to whom) but nobody seems to care.

Sometimes TB is hidden and I select its icon in the task bar, TB seems to have lost its windows settings (desktop coordinates) and it is not visible any more. That seems very much like a memory fault.

A few days ago I configured a "business card" to attach to my emails. I made the mistake to enter a wrong phone number. No problem I thought, just change it. But this is impossible !!! Again and again the wrong phone number is displayed, no matter what I have tried !!!

I wanted to use TB a little more professional but any feature I try seems to fail or is insufficient.
You are right to do like you want it to be done but it seems not to be what users need. The result is that I have configured Outlook last week (I really don't like Outlook at all) but ....

The necessary should be done and not only what is fun or ...

all the wonderful work that has been done with TB will be in vain if you continue to do so. I have been using TB for so long and I am now thinking about changing it.

You have the following choices:

This will cause all of the above changes to be overwritten, except for the added comment(s).

Comment 2

[User48756]

sorry, the last to lines are not part of my comment

Comment 3

[Kai Engert (:KaiE:)]

Note: You can get this feature as of today, using external gnupg to manage your secret key. See the thunderbird smartcard howto:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

This bug requests to implement optional individual passphrase protection directly inside TB, without having to depend on external GnuPG.

Comment 5

[Magnus Melin [:mkmelin]]

I suggest wontfix.

Comment 7

[mdedonno1337]

I would like to know why thunderbird is not configured to use the gpg-agent on the system, letting gnupg make the signature/encryption, and hence letting him deal with the password expiration and management ?

Comment 8

[Stefan Neufeind]

@Kai: Thanks you mentioned how to use GnuPG instead (according to the Smartcard-howto). That looks promising for people who prefer to centrally use GnuPG on their system (possibly used by other applications as well) and not store keys separately in thunderbird.

My +1 to have separate password per key in the internal key-management of Thunderbird, like GnuPG uses it. And with a configurable cache-expiry for the entered password?

Comment 9

[mozilla]

I came here from a blog post about how to set a master password for Thunderbird in order to avoid storing the private key password in clear text.

I guess more people will stumble across this bugreport. I’ve written a blog post about how to avoid setting a master password and use the builtin GnuPG keyring instead. Check it out here, I am happy for every feedback!
https://blog.nicohood.de/use-thunderbird-78-with-system-gnupg-keyring

Comment 10

[Gus Andrews]

Bringing feedback from a meeting with the Internet Freedom Festival community:

Our Thunderbird user base works on human rights internationally as journalists, NGO employees, and activists. Many of them face arrest or confiscation and search of their devices.

For these users, not being able to depend on a strong unique password they have to enter themselves is literally the difference between life and death or loss of liberty. An attacker could easily confiscate their device and use the access to their email to build a case to keep them in prison or execute them, or pretend to be them, wreaking havoc on the trustworthiness of efforts to protect people worldwide.

We need the option to enter a password to encrypt and decrypt. In a community feedback session, a number of our users reported trusting Thunderbird less when they no longer had that option. Losing this option erodes user trust and is likely to lose Thunderbird a very dedicated userbase.

Comment 11

[mdedonno1337]

I have solved the issue by using the external GPG agent as follow:

Use the Thunderbird config editor (found at the bottom of preferences/options), and search for mail.openpgp.allow_external_gnupg. Set the value to true.

Enabling this preference will cause Thunderbird to attempt to decrypt a message using GnuPG, whenever the internal GnuPG fails to decrypt a message with the secret keys that are available inside Thunderbird's key storage.

Note: The private keys shall be removed from the internal Thunderbird keyring; only the public keys need to be there to enable the draft encryption. Moreover, we need to reconfigure the End-To-End Encryption settings for each account (setting the correct key ID).

Note: To be able to send an encrypted email, the public key of the recipient shall be present in the internal keyring of Thunderbird.

Note: It is not possible to use a expired key for signing. Moreover, the expiration is set per subkey: this means that, even if the main key is not expired, the encryption can not be done if the encryption subkey is expired. The default expiration change procedure only changes the main expiration date, and not the subkey one.

Comment 12

[Nicolas Falquet]

Thunderbird has a Master Password feature than can protect secret key (and other sensitive info):

https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_how-is-my-personal-key-protected

https://tails.boum.org/doc/anonymous_internet/thunderbird/openpgp_migration/index.en.html#master-password

Instead of (or before) reintroducing a key password, we could encourage people to set up a Master Password while setting up OpenPGP for their account. My understanding is that it would provide the same level of security of users at risk of physical threats. And it's already implemented :)

I'll mention this on the mockups that Ura is working on.

Comment 13

[Ferenc Veres]

As a user of these I'd add: the Master Password management window (list of saved passwords) does not indicate whether the OpenPGP automatic generated passkeys (that protect the GPG keys) are also protected by Master Password or not. They could even appear maybe there in the window and user would have the option to delete them.

And related discussion is the strength of Master Password implementation (bug linked below). If this is used the strength should be hopefully similar to use of GPG key passwords. (I've seen articles on the net stating FF/TB Master Password is very easy to bruteforce, so any short random password works as good as a long complex password: protects from those only who would read the plain text, nobody else. I can't find that reference. I don't know whether direct GPG key passwords are also prone to that or not.)

https://bugzilla.mozilla.org/show_bug.cgi?id=973759

Comment 14

[Magnus Melin [:mkmelin]]

(In reply to Gus Andrews from comment #10)

An attacker could easily confiscate their device and use the access to their email to build a case to keep them in prison or

a number of our users reported trusting Thunderbird less when they no longer had that option.

People in high risk environments need to take extra precaution, such as using full disk encryption. For a scenario where the attacker has physical access to your hardware and is willing to physically harm you, it's futile to discuss whether they would get access to your data. There's no way Thunderbird (or other applications) can protect you from that. It would be counter productive to let users think otherwise.

Comment 15

[Magnus Melin [:mkmelin]]

(In reply to nf from comment #12)

Instead of (or before) reintroducing a key password, we could encourage people to set up a Master Password while setting up OpenPGP for their account. My understanding is that it would provide the same level of security of users at risk of physical threats. And it's already implemented :)

Agreed, we should add a note to inform people about this option. Depending on your setup, you may or may not want to use it. It's far from "free" though: big time usability problems, lockout with no way to recover if you can't remember the password etc..

Comment 16

[Oliver Kluge]

A master password for TB is NOT the same as passphrases for accounts!

a) Because it is 1 master password for N mail accounts together instead of N passphrases
b) You force users to enter the master password EVERY TIME when they only want to read/write mail from mail accounts without passphrases, greatly (!) encumbering users.

Does no one think of users that have a multitude of mail accounts for different purposes, each being secured or not secured as necessary for that purpose?

If you want to make Thunderbird replace Enigmail, then introduce the same (!) or better functionality. Currently, Thunderbird offers more ease of use, at the loss of security. Let users make that choice!

Comment 17

[Gus Andrews]

(In reply to Magnus Melin [:mkmelin] from comment #14)

(In reply to Gus Andrews from comment #10)
People in high risk environments need to take extra precaution, such as using full disk encryption.

Absolutely. Our users know that. Those who are able to take that precaution do.

For a scenario where the attacker has physical access to your hardware and is willing to physically harm you, it's futile to discuss
whether they would get access to your data. There's no way Thunderbird (or other applications) can protect you from that. It would
be counter productive to let users think otherwise.

Having worked with this community for close to a decade now, I can tell you it's counterproductive to use the word "futile." We should not encourage anyone using encryption into a feeling of learned helplessness, lest they simply give up. We see that happen.

There's more use cases here than just "highly sophisticated attacker has physical access to your device." There's also "less-sophisticated attacker or malicious personal contact has momentary access to user's Thunderbird and uses it to send out defamatory messages." Many of our users share devices with their families or colleagues because they're in areas where procuring additional devices is prohibitively expensive.

Honestly, it's patronizing to talk about "letting users think otherwise." Users think what they think. They know their use cases better than we do as white, well-educated, Western longtime users of this technology. I would not necessarily have prioritized development of the option to enter a password when you send, but multiple users requested that in community events and user testing. I am adding their voices to this discussion because I think you, as the project manager who ostensibly prioritizes development of features for this software, need to hear them. Particularly in order to stave off abandonment of Thunderbird by a user base that has been loyal for years.

Giving the option to enter a password every time is, to some extent, a matter of making your users comfortable with the tool you develop. A product issue. Which perhaps should be deferred until Thunderbird hires a product manager, as I understand you are planning to do. This is not the kind of decision that should be left to devs.

Comment 18

[Nicolas Falquet]

I think that we should reject this issue in favor of Bug#1741042, for which Kai already has a patch.

Comment 19

[Kai Engert (:KaiE:)]

(In reply to nf from comment #18)

I think that we should reject this issue in favor of Bug#1741042, for which Kai already has a patch.

There's a test build, if you'd like to try and give feedback.

Comment 20

[Kai Engert (:KaiE:)]

I've closed bug 1741042 and want to rather work on this one.

Comment 21

[Kai Engert (:KaiE:)]

After having been busy most of the TB 102 development cycle with other tasks, and after having mostly completed the work on bug 1627956, I'm trying a "last minute sprint" to make progress on this bug, and potentially get it included into the upcoming 102 release. I'm not sure if we will succeed, but let's try.

I'd like to try to implement the spirit of the request as good as possible, but given time constraints, I'd like to suggest a middle ground solution.

The solution I want to offer isn't based on what I consider ideal. It's based on pragmatism. It's what we might be able to implement quickly, and based on the technical constraints of our code.

The default configuration would remain as it is today.

However, users could set a global pref in private/security settings, independent of primary password, to enable the use of a separate passphrase for OpenPGP secret keys.
(In other words, it would be allowed to have any combination of primary password and OpenPGP passphrase enabled.)

If enabled, use a single OpenPGP passphrase for all OpenPGP secret keys managed by Thunderbird.
(Don't support separate passphrases for separate OpenPGP secret keys, to reduce UI complexity.)

If "separate-passphrase" option is configuration, we'd show an additional new user interface element, for example a button in the status bar.
The button would either say "OpenPGP secret keys are locked" or "OpenPGP secret keys are unlocked" (the latter with visual highlighting to indicate that you are in the "hot" state).

While unlocked, a single click on the button would immediately lock all your OpenPGP secret keys.

Locking could be manual (click the button), or automatic, with an additional option to lock automatically after N minutes. For users who are worried, I'd suggest a value of 1 minute. I wouldn't recommend a value of zero, because then you'd have to unlock again when replying to a message. But if there's demand, we could allow that immediate lock after use.

Unlocking can be done manually (click the button), or triggered automatically, when trying to read an encrypted message or trying to send a signed message.

For a person who needs maximum protection, the workflow could be:

• start thunderbird, you're in locked state initially
• click an encrypted message, it's shown as "cannot decrypt, keys are locked"
• we might automatically trigger an unlock prompt
• if user enters passphrase successfully, decrypted message is shown
• user accepts that the keys remain unlocked, or know that it will be re-locked after N minutes,
  or notice the visually highlighted "keys are unlocked" button,
  and could click it to immediately lock it again

When locked, and you try to send a signed message, you'd have to unlock, too.

Would you consider this an improvement to what we have today?

Comment 22

[Kai Engert (:KaiE:)]

Attachment: WIP: Bug 1679278 - work in progress.

Comment 23

[Martin]

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

Hi Kai,
It is great that you're looking at this and I understand the constraints you have to work through/around.

The solution I want to offer isn't based on what I consider ideal. It's based on pragmatism. It's what we might be able to implement quickly, and based on the technical constraints of our code.

However, security is never something that should be done "as quickly as possible" ; just look at Masterlock padlocks! Please consider that this "bug" has been open for 2years + and so an extra year or so to have this architecture constructed safely and securely would be what everyone who is aware of this bug would prefer over a quick-n-dirty fix just to get this ticked off the neverending list of things to fix.

Locking could be manual (click the button), or automatic, with an additional option to lock automatically after N minutes. For users who are worried, I'd suggest a value of 1 minute. I wouldn't recommend a value of zero, because then you'd have to unlock again when replying to a message. But if there's demand, we could allow that immediate lock after use.

I would suggest that timed locking (typically 3- or 5- minutes without access to the PGP keys being made) should be a REQUIREMENT rather than an option, so that even if they wanted to, someone can not unlock their PGP emails, then go and make a coffee, disable their screensaver and have anyone access their PGP emails 24 minutes later.

The default configuration would remain as it is today.

...

For a person who needs maximum protection, the workflow could be:

I read between the lines here that fundamentally the broad overview even after many, many years still hasn't been updated - it should be EVERYONE needs maximum protection, but most people are unaware of it. Being unaware you need something doesn't mean you don't need it (like, you know, medication, or email security). I would gently ask that the point of view can be adjusted that EVERYONE needs maximum protection and then build workarounds (if you wish) for people who are the exception -- who DO NOT want PGP security on their Thunderbird-based emails.

• start thunderbird, you're in locked state initially

-- YES

• click an encrypted message, it's shown as "cannot decrypt, keys are locked"
• we might automatically trigger an unlock prompt

-- The flow would be logical that this notice is displayed along with a prompt to enter the PGP key unlock passphrase.

• if user enters passphrase successfully, decrypted message is shown

-- YES, further, (as I believe Enigmail did) if more than three bad passwords are given to unlock keys then an increment throttle timer is triggered (ie wait +10, +15, +20 seconds before retrying the master passphrase.

• user accepts that the keys remain unlocked, or know that it will be re-locked after N minutes,

-- Keys should always be relocked X minutes after unlocking or after key access is required to decode a message. This can be set in a setting for example between 1 and 15 minutes or another maximum time, with recommended/default something under 10 minutes (5 is advisory)

or notice the visually highlighted "keys are unlocked" button,
and could click it to immediately lock it again

-- YES

When locked, and you try to send a signed message, you'd have to unlock, too.

-- YES

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

Would you consider this an improvement to what we have today?

It is a tall order, but Thunderbird MUST store a locker of PGP Keys as securely as the PGP keys themselves are; else if thunderbird can access and use the keys and they're not securely stored this is a HUGE reduction in the safety of PGP (which, by all standards is STILL one of the safest protections available), therefore Thunderbird needs to secue the keys at that level.

Thanks again for updating us and looking into this large and nuanced topic.

Comment 24

[Kai Engert (:KaiE:)]

(In reply to Martin from comment #23)

just look at Masterlock padlocks!

What does that mean in this context?

Please consider that this "bug" has been open for 2years + and so an extra year or so to have this architecture constructed safely and securely would be what everyone who is aware of this bug would prefer over a quick-n-dirty fix just to get this ticked off the neverending list of things to fix.

I got the feeling that waiting for another year would be bad. The major deadline for a yearly release are the user interface strings, which need to go through localization, and we only do this effort once a year for the yearly release - and that deadline is end of next week. It the design of the user interaction can be completed by that time, the strings could be included, and a little more time could be taken to test the implementation - with the option to enable it in a 102.x release.

I read between the lines here that fundamentally the broad overview even after many, many years still hasn't been updated - it should be EVERYONE needs maximum protection, but most people are unaware of it.

There are users who would disagree with you. Some users might rather stop using encryption at all, than being forced to repeatedly be bothered to enter a passphrase.

Thunderbird is a flexible tool, and needs to offer a choice. Users need to decide if they want to rely on full disk encryption and OS lock (on a personal machine), or if they rather want to use a lock in Thunderbird (on a shared machine).

I understand that there are users who want to have repeated prompts for the passphrase, and locking after a short amount of time, and I'm fine to offer this functionality. It's an easier approval process with the Thunderbird product owners, if this functionality is optional, and not made a requirement for all users.

if more than three bad passwords are given to unlock keys then an increment throttle timer is triggered (ie wait +10, +15, +20 seconds before retrying the master passphrase.

thanks for this reminder

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

I don't fully understand this, it's not clear to me what you're referring to by "TB cabinet code".
With the suggested implementation, the TB primary password (formerly called master password) would still be used to protect all application secrets like accounts passwords and the S/MIME secret key. If it's enabled, it must be entered on TB startup to login to servers.
If the new separate OpenPGP passphrase is configured, you'd be asked for that when required for decryption or signing, if you aren't yet in the unlocked state I've described.

Thunderbird MUST store a locker of PGP Keys as securely as the PGP keys themselves are; else if thunderbird can access and use the keys and they're not securely stored this is a HUGE reduction in the safety of PGP (which, by all standards is STILL one of the safest protections available), therefore Thunderbird needs to secue the keys at that level.

The keys would be managed by the RNP library, in a keyring file managed by that library. Thunderbird wouldn't re-invent that storage format.

Comment 25

[Kai Engert (:KaiE:)]

Maybe you weren't aware, but from what I saw from the latest version of Enigmail - it didn't force you to use any protection at all. You could set up Thunderbird 68, install Enigmail, and it would automatically create a key for you, without asking for any key protection at all. Adding a passphrase to protect the use of the OpenPGP secret keys was already optional at that time.

Comment 26

[Martin]

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

Further, and I use several keys; I would like an option whereby to use a particular key (once the TB cabinet is unlocked), I MUST enter the PGP passphrase itself, as well as the Thunderbird Cabinet code -- because then I am forced to enter the PGP passphrase and memorise it, else I will maybe remember the Thunderbird code (through repetition) but will gradually loose memory of the actual PGP passphrase itself because of never actually needing to write it in, this can be a massive headache (literally) when using something else using the same keys, such as Kleopatra etc.

I don't fully understand this, it's not clear to me what you're referring to by "TB cabinet code".
With the suggested implementation, the TB primary password (formerly called master password) would still be used to protect all application secrets like accounts passwords and the S/MIME secret key. If it's enabled, it must be entered on TB startup to login to servers.
If the new separate OpenPGP passphrase is configured, you'd be asked for that when required for decryption or signing, if you aren't yet in the unlocked state I've described.

To rephrase; I have several PGP keys each with their own passphrases. My understanding of your quoted message was that there would be a Thunderbird master password that would be used to access and use ALL keys within the access, and I had (erroneously) termed this the "TB Cabinet" -- so to use a TB passphrase to gain access to the PGP keys.

If this was what you meant, my thoughts on it was that there is a potential that users can add keys, memorise their TB master password and use that to deal with their keys without ever needing to remember the key's own passphrase. Thus in the fullness of time this may well be forgotten, I think it would be useful to (at least have the option) to confirm the key passphrase when using any particular key.

Apologies if my understanding of your post concept is awry.

Comment 27

[Martin]

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

Maybe you weren't aware, but from what I saw from the latest version of Enigmail - it didn't force you to use any protection at all. You could set up Thunderbird 68, install Enigmail, and it would automatically create a key for you, without asking for any key protection at all. Adding a passphrase to protect the use of the OpenPGP secret keys was already optional at that time.

I was not aware of that (or maybe I simply forgot it over time) but I would hope/assume that everyone with a PGP key would be understanding that the human is the weakest part of any security and set a passphrase accordingly.

Comment 28

[Kai Engert (:KaiE:)]

(In reply to Martin from comment #26)

I suggest to enforce that the same passphrase is used for all OpenPGP secret keys that are imported into Thunderbird (or generated by Thunderbird).

With this approach, if the user uses multiple keys for separate accounts, or has old revoked/expired keys in addition to current keys, entering a passphrase would be sufficient to make use of all your keys.

All OpenPGP secret keys are locked and unlocked at the same time.

This avoids having to prompt multiple times for passphrases. It avoids a user interface that has to explain what specific key the user is supposed to unlock. It avoids the complexity that users need to wonder which of their keys are unlocked and which ones aren't yet. It makes it possible to have a status indicator that says "secret keys are unlocked".

My hope is that this simplification is still a sufficient protection mechanism. If users really require separate passphrases for separate secret keys inside Thunderbird, they could use the Thunderbird profile manager to have two or more Thunderbird profiles.

Let me explain that again in the context of what is possible today, and in relation with the Master/Primary password setting. (For the remainder of this text, I will assume everyone of you is aware that the master password has been renamed to primary password).

Today, by default, you have no protection at all. This has always been the case in Thunderbird, even if you were using S/MIME secret keys.

Today, you already can enable the primary password. If you do, all your secrets will be protected. An automatically created passphrase is used to protect all of your OpenPGP secret keys, too. You currently cannot influence what that passphrase is. It's simply a level of indirection, because we must technically store the OpenPGP passphrases in a file that is separate from the other secret keys and account passwords.

With the suggested implementation, you'd have the option to enable the use of a separate OpenPGP passphrase. That would move the OpenPGP secret keys out of the scope of the Primary Password. This means, if the user has existing OpenPGP secret keys that were previously protected using the primary password, and the user discovers the new setting and enables the use of the "separate OpenPGP passphrase", we'd perform a migration to the new passphrase. We'd ensure the user has the main storage unlocked using the primary password, then we'd prompt the user for the new OpenPGP passphrase (with explanations), and then we'd change the protection of all existing OpenPGP secret keys: the protection by the previous automatic passphrase is removed, and the protection using the OpenPGP passphrase is activated.

A user could also decide to disable the primary password, and only use the passphrase protection for the OpenPGP secret keys.

Comment 29

[Kai Engert (:KaiE:)]

Because in comment 10 and comment 17 several example scenarios were given, and it was requested to have strong protection, for users who risk their life and their liberty, I think it's necessary to again describe what level of protection we're discussing in the scope of this bugzilla ticket.

For at risk users, who risk their life or their liberty, who must use a machine on which they cannot enable full disk encryption, the protection mechanism requested here will NOT protect them against an sophisticated attacker, who can confiscate the device while it's turned on, who can keep the confiscated device active, and who can do a forensic analysis of system memory to find copies of entered passphrases or secret keys (from a time when they were previously unlocked).

It means, users who are willing to risk life and liberty, need to be aware that having a passphrase for the secret keys as the only level of protection may only help against less sophisticated attackers, who only try to copy files found on the disk, or try to use Thunderbird interactively.

If we offer this functionality, will it be clear to affected users that this risk remains, and do you think the users would accept this remaining risk? Would they be willing to accept the risk, based on an assumption or hope that they'd only ever encounter less sophisticated attackers?

In my understanding, the intention of the request here is to provide a basic level of protection, that will help against simple attacks, only. It would protect encrypted data from a friend or colleague or family member who is allowed to use the same device, but who will not perform a forensic analysis, who will not collaborate with a sophisticated attacker, and who will not install a key logger. It would protect against a random person who is able to momentarily access your device and could be tempted to look at encrypted messages or use the device to send out digitally signed messages in your name.

Do we all agree on the scope?

Comment 30

[Arvidt]

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

For at risk users, who risk their life or their liberty, who must use a machine on which they cannot enable full disk encryption [...]

What are the scenarios for this?
I can only imagine that the user does not own the machine, does not have control over it.

I would urge to educate users whose life and liberty is at risk, not to make their life dependent on a foreign computer they do not control, even not at TB on their own (internet connected) computer at all.

As I had written in bug 1627956 comment 2
users with high security demand should be given an education text like
"Please create Your private key, compose and encrypt Your text on a plain installed seperate offline device (with a secure operating system like Tails and the recipients public key verified in person), and use internet connected TB only for transporting the offline encrypted attachment file."

See Snowden's magic carpet- that's professional. Noobs risking their life by using foreign machines or any other internet connected machines? Please no.

Comment 31

[Kai Engert (:KaiE:)]

Arvidt, the scenarios are shared machines, or machines that cannot use full disk encryption. Please read comment 10 and comment 17. I fully agree that it's dangerous to not use full disk encryption. But because computers are expensive, not everyone can afford a separate device for that.

We have been asked to provide this level of protection anyway, even if it isn't perfect.

Comment 32

[Ferenc Veres]

Thanks for the great explanations and working on this. As a long time PGP user, I think Kai's proposed solution in comment #21 is a good improvement over what Thunderbird has today. It gives an extra protection layer for those messages that are encrypted. While the TB is continuously open with a Primary Password.

If different keys would be encrypted with separated passwords, that would not make it more complex for users. You could let users set a password per-key while importing it (if this is technically possible in TB), and if one password cannot unlock all keys, then TB would silently unlock as many as it can. At time of opening one key (for reading or sending). If a message is opened which does not have an open key, it would ask for one more password. And possibly open one or more further keys again.

This way users could set the same password per-key as it is in their OpenGPG. (As Martin described.) (However noting that the keys and passwords will be then used on two totally different encryption mechanisms, which might weaken security.) (Martin: the original PGP passwords are not used by TB. They are removed and the keys are re-encrypted with another method and protected with automatically generated, fairly complex password. Which password is then protected by the Primary Password. Or not protected at all, if you have no Primary Password.)

The "lock indicator" would not need indicate whether one or all are open. Just open (one or more) or not open (none), and allow to close (all). (A tooltip might give more info.)

The "unlock indicator" could open the key which belongs to the currently selected account (plus silently more if they accept the same password). Or there would be no way to "manually open" them. Just at time of sending or reading, automatically. As I remember, that's how Enigmail worked and it was OK.

User may still choose to use one password, in that case user experience would be just as you described.

Regarding timeout: that sounds good. But when the timer would start? At time of entering the password? Or last use of any PGP key while working with TB? (I.e. reset timer with each use of a PGP key? In this case working with many encrypted messages is more convenient and similar to current behavior.)

Computer sleep or screen lock should also lock this.

Comment 33

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Refactor to minimize entry points for OpenPGP secret key import. r=mkmelin

Depends on D146779

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a621f83b8c42
Refactor to minimize entry points for OpenPGP secret key import. r=mkmelin

Comment 35

[Oliver Kluge]

(In reply to Arvidt from comment #30)

I would urge to educate users whose life and liberty is at risk, not to make their life dependent on a foreign computer they do not control, even not at TB on their own (internet connected) computer at all.

I must in very strongest of terms reject the derogatory wording "urge to educate users". This must imply that such users are un-educated, or that you are in possession of a higher truth. This is the arrogance that drives ordinary users away from technology. Don't use such words. If you are not in a situation as such users are, do not judge their judgement. Didn't the thought cross your minds that there are situations where you must rely on foreign equipment because there is no alternative?

Comment 36

[Martin]

(In reply to Ferenc Veres from comment #32)

Regarding timeout: that sounds good. But when the timer would start? At time of entering the password?

Yes. The timer starts at the last point the system can prove the authorised human last accessed it -- ie by entering the keypass for the PGP key.

Computer sleep or screen lock should also lock this.

I agree. But this should be superceded by above, if nessecary.

(In reply to Oliver Kluge from comment #35)

(In reply to Arvidt from comment #30)
I must in very strongest of terms reject the derogatory wording "urge to educate users". This must imply that such users are un-educated, or that you are in possession of a higher truth. This is the arrogance that drives ordinary users away from technology. Don't use such words. If you are not in a situation as such users are, do not judge their judgement. Didn't the thought cross your minds that there are situations where you must rely on foreign equipment because there is no alternative?

Agreed. It's not Thunderbirds place to educate anyone. Not least without first understanding their situation.

Comment 37

[Kai Engert (:KaiE:)]

I suggest, let's skip the "who said what" and "who attempts to educate whom" part of the discussion.
We're listening. We're trying to help. We've started to work on this.

Comment 38

[Martin]

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

In my understanding, the intention of the request here is to provide a basic level of protection, that will help against simple attacks, only. It would protect encrypted data from a friend or colleague or family member who is allowed to use the same device, but who will not perform a forensic analysis, who will not collaborate with a sophisticated attacker, and who will not install a key logger. It would protect against a random person who is able to momentarily access your device and could be tempted to look at encrypted messages or use the device to send out digitally signed messages in your name.

Do we all agree on the scope?

Yes, while it's not going to be as strong as core PGP protection, it would allow Thunderbird to implement secured PGP encryption of messages.

The real risk with email communication is not the end device, but the transportation.... every single server node that handles an email can read its contents, and this as a factor is far more important than an end user . It also helps protect end users from server admins who can snoop into emails, because that does happen.

TL/DR: I am on Thunderbird 68 because I can't use V78+ until there's a suitable system for managing PGP in place that doesn't release my encrypted emails if my device gets stolen or my server gets compromised. So I would be looking forward to developments as described by Kai :)

Comment 39

[Kai Engert (:KaiE:)]

Martin, I'm not sure if you're fully aware of the functionality that Thunderbird 78+ ALREADY provides. In my understanding, Thunderbird already provides the functionality you're asking for.

If you set a primary password in Thunderbird, your OpenPGP secret keys will already be locked using that primary password, too. Assuming you don't have any unprotected backups of keys on your computer, and you have a primary password set, your secret keys are already protected if your computer is stolen (if the computer is locked or shut off).

A complaint that has been reaised is that the keys will remain fully unlocked for the remainder of the Thunderbird session,
and another request was the ability to use separate passwords, so a simpler primary password could be used for protection account passwords, and a stronger passphrase for the protection of OpenPGP secret keys.

This bug/ticket here is about the following improvements:

• use a passphrase that is SEPARATE from the existing primary/master password mechanism
• offer a way to LOCK AGAIN the use of your OpenPGP secret keys. After you have used them
  to decrypt a message, go back to locked state, to require that the user must enter the
  password again to decrypt.
• Instead of locking after every decrypted message, my suggestion is to instead implement
  an automatic timeout that can be configured to one minute, and will automatically lock
  again after one minute, plus a new button on screen that can be used to lock immediately.

Comment 40

[Martin]

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

Martin, I'm not sure if you're fully aware of the functionality that Thunderbird 78+ ALREADY provides. In my understanding, Thunderbird already provides the functionality you're asking for.

As I understood when I used V78 when it came out ( a while ago now), the master password meant I didn't need to use the PGP passsphrases when writing an encrypted email. However my memory is imperfect and this is an aside to this bug discussion.

Comment 41

[Kai Engert (:KaiE:)]

(In reply to Martin from comment #40)

As I understood when I used V78 when it came out ( a while ago now), the master password meant I didn't need to use the PGP passsphrases when writing an encrypted email. However my memory is imperfect and this is an aside to this bug discussion.

Background:
You never need to use your secret for pure encryption, because when creating an encrypted message, your secret keys are not required.
However, the default is to send an encrypted and signed message. And for creating the signature part, your secret key is required.

Regarding master password:
If you have a master password set, and you have entered/unlocked using the master password on startup, then you don't need to enter the password again as long as Thunderbird is kept open.
That means that currently, if you send an encrypted and signed message, you don't have to enter the password again.

With the suggested improvement in this bug, if you will activate the separate passphrase for OpenPGP secret keys, and if you activate the timeout, and the timeout has passed, or you have manually locked, then you would be required to enter your passphrase again for sending an encrypted and signed message.

(You would be never be prompted for sending an encrypted but not signed message, because pure encryption doesn't require the use of your secret keys.)

Comment 42

[Kai Engert (:KaiE:)]

... and of course, the same applies for decrypting a message. After the timeout has passed and your secret keys were locked automatically, or if you have locked them manually, you'd also have to enter the passphrase again for decrypting a message.

Comment 43

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Land strings that will be required for the OpenPGP passphrase feature. r=aleca

Comment 44

[Kai Engert (:KaiE:)]

I made a mistake in the refactoring patch. One function rename is done in the main patch, and needs to be backed out.

Comment 45

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Revert parts of refactoring to fix a regression. r=mkmelin

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7af9f75b4d27
Revert parts of refactoring to fix a regression. r=mkmelin

Comment 47

[A]

(In reply to Magnus Melin [:mkmelin] from comment #14)

People in high risk environments

Forget about high risk environments. Why does the UX of the OpenPGP implementation in Thunderbird not replicate Enigmail exactly?

I have a number of users on Thunderbird 76(?) which I am unable to upgrade, precisely because of these differences. I though I was good to go after stripped key support was finally implemented, but now this is another showstopper.

Comment 48

[A]

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

(In reply to Martin from comment #26)

I suggest to enforce that the same passphrase is used for all OpenPGP secret keys that are imported into Thunderbird (or generated by Thunderbird).

With this approach, if the user uses multiple keys for separate accounts, or has old revoked/expired keys in addition to current keys, entering a passphrase would be sufficient to make use of all your keys.

No, no, no, no.

Using multiple keys is precisely how I know that I am sending from the right account, encrypting with the right key, and actually committing the act of signing the message (in my neck of the woods, the legal act of signing requires a positive action).

All OpenPGP secret keys are locked and unlocked at the same time.

This avoids having to prompt multiple times for passphrases. It avoids a user interface that has to explain what specific key the user is supposed to unlock.

This is precisely what I need, what I expect, and what it used to be like. Why would you force me and my users to re-learn something that they had been using successfully for close to seven years now.

It avoids the complexity that users need to wonder which of their keys are unlocked and which ones aren't yet. It makes it possible to have a status indicator that says "secret keys are unlocked".

What complexity? Can you point to one bug report that says "I can't use OpenPGP because I don't know which keys are unlocked"?

My hope is that this simplification is still a sufficient protection mechanism. If users really require separate passphrases for separate secret keys inside Thunderbird, they could use the Thunderbird profile manager to have two or more Thunderbird profiles.

😳

I have two email addresses from two different companies (in addition to my own private email). Are you really suggesting that I should restart Thunderbird with a different profile depending on which account I want to send email from?

Today, by default, you have no protection at all. This has always been the case in Thunderbird

Not true. This didn't happen with Enigmail.

An automatically created passphrase is used to protect all of your OpenPGP secret keys, too.

Why was this done? I can't think of a single reason why this would be a good idea. If you want "convenience", just remove the passphrase.

With the suggested implementation, you'd have the option to enable the use of a separate OpenPGP passphrase. That would move the OpenPGP secret keys out of the scope of the Primary Password. This means, if the user has existing OpenPGP secret keys that were previously protected using the primary password, and the user discovers the new setting and enables the use of the "separate OpenPGP passphrase", we'd perform a migration to the new passphrase. We'd ensure the user has the main storage unlocked using the primary password, then we'd prompt the user for the new OpenPGP passphrase (with explanations), and then we'd change the protection of all existing OpenPGP secret keys: the protection by the previous automatic passphrase is removed, and the protection using the OpenPGP passphrase is activated.

You lost me here. What is the Primary Password? Is that the same as Thunderbird's master password? Or the "let's use the same made-up passphrase for all PGP keys" mechanism that you mention above? And is the above paragraph describing a one-off migration (back to what it used to be in the first place for those of us who actually used OpenPGP) or is this some kind of repeated process?

Comment 49

[A]

(In reply to Gus Andrews from comment #17)

Sorry for the noise, but I agree with much of Andrews' comment. To summarise:

They know their use cases better than we do

That is so indeed.

Particularly in order to stave off abandonment of Thunderbird by a user base that has been loyal for years.

That is also so. It has been a low priority task of mine to migrate users to an email client that meets our requirements since the demise of Enigmail (TB 72? 67? I forget) meant that newer versions of TB are no longer adequate for our needs, and the compliant version is getting long in the tooth.

Giving the option to enter a password every time is, to some extent, a matter of making your users comfortable with the tool you develop. A product issue.

I'd say it's more than a matter of comfort. It's a matter of making Thunderbird usable again, for existing users.

Which perhaps should be deferred until Thunderbird hires a product manager, as I understand you are planning to do.

Product manager or product owner? Either way, not sure a green newcomer to the project would help in any way. On the other hand, you sound like the sort of chap that could be useful in that position.

This is not the kind of decision that should be left to devs.

I am puzzled by the fact that the existing OpenPGP implementation is so different from Enigmail, which was the standard, time-tested tool that we were all using. Is it documented anywhere why the functionality was not exactly duplicated?

Something else that I wonder is if any of those involved in the development of the Enigmail replacement do actually use signing and encryption themselves. I'm not talking about simply signing / encrypting out of habit, but for instance approving expenses or concluding contracts simply by replying with a signed email (as opposed for instance an unsigned reply seeking further clarifications, negotiating, etc.)

Please don't just make stuff up. Go out, physically meet and talk to users, find out what their actual needs are, not what you think those are.

Comment 50

[Kai Engert (:KaiE:)]

If independent passphrases per secret key are preferable, we can consider to offer that approach instead.

The master password feature has been renamed to primary password in newer versions of Firefox and Thunderbird, it's the same thing.

I understand your frustration that Thunderbird now behaves differently than Enigmail, but we had no choice.
I don't want to justify, just mention a few of the reasons.
The Enigmail developer was no longer able to continue to maintain it, because of Mozilla platform architectural changes, driven by Firefox, which Thunderbird developers couldn't influence, but which Thunderbird developer were required to adopt.
And because of licensing issues, Thunderbird could no longer use GnuPG as the default underlying OpenPGP engine.
And time was very short to create an alternative implementation.

In case you didn't know, it's possible to use GnuPG as an alternative engine for secret keys.
This way, locking/unlocking secret keys is driven by GnuPG.
It requires manual configuration. This page describes how to do so:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

Comment 51

[A]

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

If independent passphrases per secret key are preferable, we can consider to offer that approach instead.

For my use case, they're more than preferable: they are a must.

Please note that the secret keys are used in multiple places, not just Thunderbird but also for document signing, instant messaging and for some users (I think, not sure) remote login. While some of my users are technically savvy enough to understand that they might have to use different passphrases in different software / devices, I can assure you they're not going to be amused.

The master password feature has been renamed to primary password in newer versions of Firefox and Thunderbird, it's the same thing.

Thanks.

I understand your frustration that Thunderbird now behaves differently than Enigmail, but we had no choice.
I don't want to justify, just mention a few of the reasons.

Thanks, I was aware of the architectural issues (XUL deprecation, was it?) but my question was about why the functionality (aka UX) was not replicated? Because of time constraints, I guess?

And because of licensing issues, Thunderbird could no longer use GnuPG as the default underlying OpenPGP engine.

I wasn't aware of that.

[ Details for the next reader: TL;DR: Thunderbird's MPLv2 is not compatible with OpenPGP's GPLv3+ and devs didn't want to make gpg a dependency (source: https://www.zdnet.com/article/thunderbird-to-add-built-in-support-for-openpgp-email-encryption-standard/). ]

In case you didn't know, it's possible to use GnuPG as an alternative engine for secret keys.
This way, locking/unlocking secret keys is driven by GnuPG.
It requires manual configuration. This page describes how to do so:
https://wiki.mozilla.org/Thunderbird:OpenPGP:Smartcards

That didn't work during my first migration attempt a couple of years back but I'll give it another go, thanks.

Comment 52

[Kai Engert (:KaiE:)]

(In reply to A from comment #51)

Thanks, I was aware of the architectural issues (XUL deprecation, was it?) but my question was about why the functionality (aka UX) was not replicated? Because of time constraints, I guess?

It was a mix. It would be have been impossible to fully re-implement all backend functionality offered by Enigmail in the time that was available to provide an alternative implement, in order to ensure that Thunderbird at least can offer basic OpenPGP support.

That was seen as an opportunity to simplify the user interface, remove things that are expert-level, in an attempt to make the functionality more easily understandable for a wider set of users. Note that the user group switched away from those who had opted in to deliberately install an Add-On for OpenPGP, to now being a default functionality for all Thunderbird users. My impression is that we didn't fail there. While it's true that we got complaints from experienced Enigmail users, we have also gotten praise for the new simpler implementation.

Comment 53

[A]

While it's true that we got complaints from experienced Enigmail users, we have also gotten praise for the new simpler implementation.

I suppose it would be interesting to dig into those latter cases. In particular, I wonder if those users are using PGP deliberately or opportunistically.

More specifically, I know that end to end encryption is all the rage these days (we'll leave for some other time the discussion of its actual usefulness in the age of on-device interception via Pegasus, etc.) and the opportunistic use case possibly serves those users well, but I'm just guessing.

However, for actual formal use where, at least in my use case, signing is more important – or at least more common – than encryption and we need more control over PGP operation (stripped keys, maintaining the original passphrases, etc.), the new implementation falls pretty short at the moment. It's possible that this is what other experienced Enigmail users were also doing, but I can only speak for myself.

I will be looking into giving the GnuPG integration another go, perhaps that will solve my problems for the time being. What puts me off a bit is the redundancy and increased administrative workload of still having to import the public keys into Thunderbird. If Thunderbird used GnuPG for both decryption/signing and encryption/verifying then life should be good. This could possibly also let you concentrate on offering a "simplified" PGP experience for opportunistic uses while offloading the relatively more advanced use cases to GnuPG?

But this is probably a subject for a different bug report.

Comment 54

[Ferenc Veres]

@A: (mainly re: Comment #47 but others too)
I don't know if you looked at current Thunderbird versions, but the PGP implementation is excellent in it. Very user friendly. Totally not comparable to what we used in Enigmail for a 10-20 years. So I don't see why would we want anything like that again. EXCEPT, of course, the original bug description here -> more user control over keys and signing (passwords, key protection), and maintain it separately from Primary Password. (I think we all agree - those who follow this bug.). (That would probably also satisfy your requirement - as I understand.)

Comment 55

[A]

My users and I make extensive use of OpenPGP, not just within Thunderbird, but also in LibreOffice, Kleopatra, and a couple of signing and verification scripts with a GUI frontend on the desktop, plus OpenKeyChain + Conversations + K-9 on Android.

With Enigmail, the UX was consistent everywhere: the GnuPG keyring was used everywhere on the desktop and the same keys exported to Android were managed in an equally consistent manner by OpenKeyChain.

Now Thunderbird has gone its own way without properly considering that it doesn't exist in a vacuum but it's part of a wider environment. Trying to use Thunderbird's OpenPGP implementation doubles the support workload, requires retraining existing users, and requires training new users on two different approaches to using OpenPGP.

Engert has explained the constraints that have shaped Thunderbird's current OpenPGP implementation, but sadly right now our workflow would be broken by moving away from Enigmail (another consideration is the possibility of weaknesses in a fresh implementation, compared to GnuPG's maturity, but that is manageable).

One possible compromise, to minimise disruption, could be to detect if GnuPG is already present in the system and if so, to offer the user a choice of using it or the internal implementation; provided that GnuPG is used for both decryption/signing and encryption/verifying, as already mentioned.

Comment 56

[Kai Engert (:KaiE:)]

I have a new solution for the original request in this bug: To support locking secret keys with a user-defined passphrase.
I will explain that below.

However, recent comments have also complained about GnuPG integration. At least for this bugzilla ticket here, it's out of scope. We need to discuss potentially better integration of GnuPG separately.

Comment 57

[Kai Engert (:KaiE:)]

Based on the comments that were given above, you have convinced me that my earlier suggestion for solving this bug shouldn't be done.

To summarize, I had earlier suggested to introduce a new global, common passphrase that would cover all OpenPGP keys. I no longer want to do that.

Instead, I want to offer the behavior that users know from GnuPG, that each secret key may be protected using an independent passphrase. That is, it's user choice whether the user wishes to use the same passphrase for all their keys, or separate passphrases for their keys.

Now, the challange for me was, how would I implement this mode.

Because Thunderbird currently supports the modes "protection based on a global primary password" and "no protection if no primary password is set", I cannot drop those modes. Note that those modes were pre-existing in Thunderbird, they had been always used with secret keys for S/MIME certificates. So initially, for consistency, it was easiest to use the same behavior for OpenPGP secret keys, too. (Justification, because at the time we had to integrate Enigmail, there were too many work items, and I had to simplify wherever possible.)

This means, going forward, Thunderbird will have to support different protection modes for OpenPGP secret keys in parallel.

I have worked on an enhancement, which implements the following behavior:

Using TB's OpenPGP Key Manager, when viewing the details of a key pair, the current passphrase protection mode for the key is shown.

For all existing keys from past TB operation, it will display it either as "unprotected" (which in fact means an automatic passphrase is used for the underlying key storage, but that passphrase can be accessed automatically), or as "protected using Thunderbird's primary password".

That screen, which displays the current status of passphrase protection, will offer the user to change the protection mode for this particular key (including its subkeys).

Once a key has been changed in that way, and an individual passphrase has been set, TB will prompt the user to unlock the key, prior to signing/decrypting or other private key modifications (e.g. revoking or changing expiration).

I have an initial implementation that seems to work. The following parts are not yet implemented:

• timeout based caching for passwords.
  Currently, if a used defined passphrase is configured, it must be entered for each operation

• once timeout based caching is implemented, a global way to clear the cached passwords

• asking the user for their preferred mode of passphrase protection when importing or generating a new key

I want to implement those remaining pieces. I just don't know if I complete everything in time for this year's 115 release.

We have a "user interface string freeze" on May 11. I want to try to get all necessary strings into shape before that date. If I succeed, I might have time until early June to finalize the functionality.

I couldn't work on this earlier, there were too many other priority work items waiting for me during the past year. But at least we're making progress. So, should I fail to get this feature done in time for this year's major 115 release, there's hope that it would be available in the Beta versions that we release throughout the following year.

Of course, this all also depends on acceptance of this new approach, both from TB's code and UI reviewers, and I'd also like to listen to you, the community, whether this now appears to be better approach, an approach that makes sense to you.

I'd like to provide a test binary with this functionality, with the current (incomplete) implementation, and I'd appreciate feedback, based on the combination of this explanation and the functional behavior that you can test.

Comment 58

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Backend code to support user-defined OpenPGP passphrases. r=mkmelin

Comment 59

[Kai Engert (:KaiE:)]

Test binaries, as explained above. Feedback welcome.

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ag62x5fPTjm3HUylxO_69Q/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E0GESvSKSaC27RbbI961LQ/runs/0/artifacts/public/build/target.zip

MacOS:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/VIgHnoVQSmyew_xZIHj4ow/runs/0/artifacts/public/build/target.dmg

(To use the macOS build, you'd have to override security protections, execute the command xattr -cr on the downloaded and extracted app. Use at your own risk.)

Comment 60

[Kai Engert (:KaiE:)]

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

The following parts are not yet implemented:
...

• asking the user for their preferred mode of passphrase protection when importing or generating a new key

I've updated the patch, which implements the above, with the following logic.

When generating a key, the form that prompts for key options has an additional section, which asks for the secret key protection.

If currently NO primary password is enabled, then the prompt will offer the following, with the second choice pre-selected

• do not protect the key
• use the following passphrase (user must enter and repeat)

If currently a primary password IS enabled, then the prompt will offer, with the first choice pre-selected

• protect using primary password
• use the following passphrase (user must enter and repeat)

When importing a key, the user will NOT be asked how to protect the key. The following logic is used:

If the imported key is saved without any passphrase protection, it will be imported with TB's automatic mechanism. (Which means, either no protection, or protected using the primary password.)

If the imported key already has a passphrase set, then TB will prompt the user to unlock all secret keys. However, that unlocking is just done as a test, to confirm the user knows the passphrase. If the user is able to unlock, the key is imported, and the existing passphrase protection is kept.

I hope this makes sense.

Comment 61

[Kai Engert (:KaiE:)]

updated test binary:

linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PZJUO0C_TtyaA-isSk7NLQ/runs/0/artifacts/public/build/target.tar.bz2

windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/N8xdQuJBRZy89k8hUivQBw/runs/0/artifacts/public/build/target.zip

macos:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Wvu6f37TTteTGsvrbq5XXg/runs/0/artifacts/public/build/target.dmg

Comment 62

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - UI strings for the separate OpenPGP passphrase feature. r=aleca

Comment 63

[Ferenc Veres]

Thank you Kai, great work! Looks good to me. A few small feedback. Testing on Linux.

• When I create a new key, there is the "Secret key protection" selection with two options: the old way, and the password protected way. The first option (old way) has no label, just the radio button.
• It always creates 3 years expiring key, even if I choose no expiry.
• When I am asked to enter the password on an encrypted mail, the button OK says "Sign in", which is not the best.
• Sometimes this window asks for the password twice, but hard to reproduce. I think this is when I open my SENT mails and the currently selected mail is encrypted. But not always asks twice, so I'm not sure about this.
• In one case it didn't resolve the "..." subject after entering password. I needed to select another message and then this "..." message again. (I'm not sure if anybody can reproduce this, happened only once.)
• When I tried to export the secret key (backup secret key) from my Account Settings (End to end encryption section), it asks for a password, but does not create any file. Exporting pub key creates the pub file. (Tried twice.)

I think I tested most options: with and without primary password. Unlocking the key in GPG key manager, locking it again. To me these look well fit into the system.

Comment 64

[Kai Engert (:KaiE:)]

Ferenc, thanks a lot for your feedback!

(In reply to Ferenc Veres from comment #63)

• When I create a new key, there is the "Secret key protection" selection with two options: the old way, and the password protected way. The first option (old way) has no label, just the radio button.

I see two checkboxes. I will attach a screenshot of what I see. Does your screen look different?

Comment 65

[Kai Engert (:KaiE:)]

Attachment: screenshot for comment 64

Comment 66

[Kai Engert (:KaiE:)]

Attachment: another screenshot for comment 64

This is what I get with primary password turned off.

Comment 67

[Kai Engert (:KaiE:)]

(In reply to Ferenc Veres from comment #63)

• It always creates 3 years expiring key, even if I choose no expiry.

Confirmed. That's an independent bug even, in stable version 102. I've filed bug 1830094.

• When I am asked to enter the password on an encrypted mail, the button OK says "Sign in", which is not the best.

Agreed it's not ideal. Currently this code uses a standard prompt mechanism from the backend. To get a different label with a password entry field, we'll have to implement our own prompt dialog (not reuse a standard prompt).

• Sometimes this window asks for the password twice, but hard to reproduce. I think this is when I open my SENT mails and the currently selected mail is encrypted. But not always asks twice, so I'm not sure about this.

I cannot immediately reproduce, but that's a disdavantage of having a "prompt every time" mode, as it's currently implemented. We should a implement a passphrase caching mechanism, with a couple of seconds as the bare minimum settings. Would everyone agree that caching for a couple of seconds would be acceptable for everyone, even for users who want a "prompt every time" behavior?

• In one case it didn't resolve the "..." subject after entering password. I needed to select another message and then this "..." message again. (I'm not sure if anybody can reproduce this, happened only once.)

We're working on a regression bug related to ... no longer being replaced. I thought we already landed sufficient fixes.
I think this should be unrelated to this new functionality.
It should be possible to reproduce the same behavior with the official Thunderbird Daily build.
If you could try, that would be appreciated.
If you get the same behavior, a separate bug report would be helpful, cross referencing bug 1819499.

• When I tried to export the secret key (backup secret key) from my Account Settings (End to end encryption section), it asks for a password, but does not create any file. Exporting pub key creates the pub file. (Tried twice.)

I have not yet tested that, I might have to improve the patch to fix that, thanks for reporting.

I think I tested most options: with and without primary password. Unlocking the key in GPG key manager, locking it again. To me these look well fit into the system.

Note that the unlocking in key manager is intended only for the purpose of possibly changing the passphrase, or switching to a different protection mechanism (none or primary password). The key will be automatically locked once you close the dialog for viewing the key details.

Comment 68

[Kai Engert (:KaiE:)]

(In reply to Ferenc Veres from comment #63)

• When I tried to export the secret key (backup secret key) from my Account Settings (End to end encryption section), it asks for a password, but does not create any file. Exporting pub key creates the pub file. (Tried twice.)

Indeed, the previous patch did not yet have the required chances.
Meanwhile, I've updated the patch, and here are updated experimental binaries:

Linux 64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HKm9YSc6S7WXUCpU_DhsPQ/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/c0xrfZG-Rl288_pcmJbBIQ/runs/0/artifacts/public/build/target.zip

macOS:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SBTm_gakRqiTlQ6qMA6Jxg/runs/0/artifacts/public/build/target.dmg

The backup procedure doesn't provide helpful step-up-step explanations.
It will start by prompting for the destination filename.
Then it will prompt for the backup password - all exported secret keys will be protected with that, regardless of their existing protection.
Finally, the user will be prompted for each passphrase that's necessary for unlocking each selected key.
If the user cancels at any point (possibly after not being able to enter a correct passphrase for one of the keys), the operation will be aborted, and no file created.

Comment 69

[Ferenc Veres]

Attachment: Missing label screenshot, in reply to comment #66

Thanks for the answers and fixes.
This is what I get on Linux, even with the binary in comment #68. (However this screenshot is from the previous binary.) I think this is in both cases when Primary Password is set or not set. I didn't notice any other missing labels in the program. (This is X11.org, IceWM, AntiX Linux 22 (Debian based), without systemd. But I have some other Linuxes too if I'll need to try.)

Comment 70

[Kai Engert (:KaiE:)]

(In reply to Ferenc Veres from comment #69)

This is what I get on Linux, even with the binary in comment #68. (However this screenshot is from the previous binary.)

Strange. Do you get any error message in the error console (open with shortcut CTRL+SHIFT+J) at the time you open this dialog?

Comment 71

[Kai Engert (:KaiE:)]

I intend to make an addition to the secret key import dialog.
I want to add a checkbox with roughly the following text:
"Keep pre-existing passphrase protection for imported secret keys."
and I'd enable the checkbox by default.

The idea is, if a user really wants to use the old style mode, no protection, they can get it, by explicitly disabling that checkbox on import.

Comment 72

[Ferenc Veres]

re comment #70 : no sorry, there is no message on Ctrl-Shift-J console when I open that window or if I change between those two options.

re comment #71 "pre-existing" could be "existing" or just "Keep passphrase protection for imported secret keys". To me "pre-existing" is confusing. As I can see it keeps the password which is on the backup file, so what the user enters for opening it. I'm not sure if that's what everyone wants, but at least It keeps this simple. But! The previous Thunderbird experience would be that this checkbox is unchecked by default.

Comment 73

[Kai Engert (:KaiE:)]

(In reply to Ferenc Veres from comment #72)

re comment #71 "pre-existing" could be "existing" or just "Keep passphrase protection for imported secret keys".

Ok, thanks, I'll use that text, pending review.

The previous Thunderbird experience would be that this checkbox is unchecked by default.

I've updated the patch in the following ways:

• all choices are set to the classic behavior
• a new pref is introduced to keep this new functionality hidden
  (This allows us to keep the new functionality hidden until we're confident it's working fine)

Comment 74

[Kai Engert (:KaiE:)]

Attachment: passphrase-prompt.png

This is how the prompt for entering the passphrase looks like, when the application needs access to the secret key for performing an operation, e.g. decrypting or signing a message, changing the properties of a key, backing up a key.

Comment 75

[Kai Engert (:KaiE:)]

Attachment: import-confirm.png

This shows the modified secret key import confirmation dialog, which adds a new checkbox at the bottom, to control the passphrase protection after import. If checked, an existing user-defined passphrase protection on the imported keys will be kept (if any).

Comment 76

[Kai Engert (:KaiE:)]

See comment 65 and 66 for the create-new-key screen and their new strings/choices.

Comment 77

[Kai Engert (:KaiE:)]

Attachment: current-unprotected.png

This shows the new tab in the lower half of the "OpenPGP key detail" view, which is shown for secret keys, only.

This view shows a key that doesn't have a user-defined passphrase, and no primary password set.

Comment 78

[Kai Engert (:KaiE:)]

Attachment: current-pp.png

This view shows a key that doesn't have a user-defined passphrase, but the global primary password is turned on.

Comment 79

[Kai Engert (:KaiE:)]

Attachment: has-passphrase.png

This view shows a key that is protected with a user-defined passphrase.

Comment 80

[Kai Engert (:KaiE:)]

Attachment: user-passphrase-unlocked.png

This view shows a key that is protected with a user-defined passphrase.

The user has already used the Unlock button (from the previous screenshot), so the key is ready to be changed, using the shown actions, if the user wishes to do so. (The user can simply do nothing, in which the key will be re-locked when the dialog is closed.)

Comment 81

[Kai Engert (:KaiE:)]

Latest experimental build:
Linux 64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/T_tj-O0uTEmkFSaNCaBbaw/runs/0/artifacts/public/build/target.tar.bz2

Win64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/DRal0XjETMaq0yMgLnKyXg/runs/0/artifacts/public/build/target.zip

Win32:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Zsbhz9uNRCmLX6ND7FAfWw/runs/0/artifacts/public/build/target.zip

macOS:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JLOSFZW6QpOhiAAoTaF1qg/runs/0/artifacts/public/build/target.dmg

To see the new feature with this build, use settings, config editor, and set mail.openpgp.passphrases.enable to true

Comment 82

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Frontend code to support user-defined OpenPGP passphrases. r=aleca

Depends on D176341

Comment 83

[Kai Engert (:KaiE:)]

(In reply to Ferenc Veres from comment #69)

Missing label screenshot, in reply to comment #66

We found the cause. It happens if key generation is opened from account settings.
(It works when opened from OpenPGP Key Manager.)
We'll fix that.

Comment 84

[Kai Engert (:KaiE:)]

New test build with updated code and strings and UI:

Linux64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Gmrg7DtJS9y1IQW9xtOu-Q/runs/0/artifacts/public/build/target.tar.bz2

Win64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/QnnWQ3DUTaGPvAEeC9o-xg/runs/0/artifacts/public/build/target.zip

macos:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XCW3ilTbRj2z0vSEV-uvmw/runs/0/artifacts/public/build/target.dmg

Comment 85

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/515ce5849081
UI strings for the separate OpenPGP passphrase feature. r=aleca DONTBUILD

Comment 86

[Kai Engert (:KaiE:)]

Magnus asked for manual test instructions.

• Of course, use a build with both patches (frontend and backend), for example the build from comment 84.
• Use config editor to set pref mail.openpgp.passphrases.enabled to true
• Use account manager e2ee or OpenPGP Key Manager to generate a new key, and you should see a choice for optionally setting a passphrase. The first choice will look different, based on the primary password setting.
• Use account manager e2ee or OpenPGP Key Manager to import a key from a backup, and when being presented the list of found keys, there is an additional checkbox, which optionalls offers the user to keep the passphrases that are currently set on the imported keys. (This will be ignored if the key has an empty passphrase. Such keys (empty passphrase) will always be brought into the automatic protection (none or primary password).)
• Using OpenPGP Key Manager, open the details of a private key (row shown in bold). The key details dialog will have an additional tab, "passphrase protection". In this tab you can see the current level of protection for the private key. If at least one private key (the primary or a subkey) cannot be unlocked using Thunderbird's classic automatic mechanism, the tab will inform that it is protected using a passphrase. If a passphrase is currently set, the dialog offers to unlock the current password. After unlocking, it's offered to change the passphrase, or to remove the currently set passphrase, which will change the key either to being unprotected, or to be protected using the primary password. If no protection is currently active, it's immediately offered to set a passphrase, without a prior need to unlock.
• When trying to decrypt an email, or when sending a signed/encrypted email, and the required private key is one that has a passphrase set,
  the user will be prompted to enter it. If the user cancels, no decrypted message will be shown, or the send operation will fail.
• When trying to change the expiration date of a key, or when trying to revoke a key, or when trying to backing up a key, the user will also be prompted to unlock passphrases, and the operation can succeed only after the user has entered the correct passphrase.
• If the user does not set the pref, or the user never choses to set a passphrase, the behavior should remain exactly as in earlier versions of Thunderbird.

Comment 87

[Kai Engert (:KaiE:)]

Attachment: Bug 1679278 - Tests for user-defined OpenPGP passphrases. r=mkmelin

Comment 88

[Kai Engert (:KaiE:)]

The accepted 3 patches are ready for landing.

Comment 89

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/66c5ab097834
Backend code to support user-defined OpenPGP passphrases. r=mkmelin
https://hg.mozilla.org/comm-central/rev/0b9dac2dbec5
Frontend code to support user-defined OpenPGP passphrases. r=aleca
https://hg.mozilla.org/comm-central/rev/e40b03f2e5d1
Tests for user-defined OpenPGP passphrases. r=mkmelin

Comment 91

[Wayne Mery (:wsmwk)]

Everyone ... "NOW is the time", as the saying goes.

Everyone, please post your response in this bug to the developer's comment 86 . In case it wasn't obvious, this is your opportunity to help with the feature which the developer has kindly provided. Let us know if you have difficulty testing.

Comment 92

[Kai Engert (:KaiE:)]

I've filed bug 1834577 to track the implementation of a cache for entered passphrases.

Comment 93

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #91)

Everyone ... "NOW is the time", as the saying goes.

Everyone, please post your response in this bug to the developer's comment 86 . In case it wasn't obvious, this is your opportunity to help with the feature which the developer has kindly provided. Let us know if you have difficulty testing.

Correction, please post your feedback in the thread at https://thunderbird.topicbox.com/groups/e2ee/Tdc427a8b0255b85a-M4db1a36a093cb3486c5149c8