It is assumed that the reader is familiar with fundamentals of public-key ("asymmetric") cryptography. A good introduction to those fundamentals cab be found in the Wikipedia article on public key cryptography. An alternative is a less technical text: An Introduction to Hybrid Cryptography Systems.
Thunderbird ("mail-client emeritus") is the most common and best known "e‑mail client" program. It is available on Microsoft, Apple and Linux family of operating systems. It is free, "open‑source" and under active development.
With version 78.x, published in late 2020, Thunderbird introduced "built-in" ability to encrypt e‑mail traffic. The developers wisely decided to make Thunderbird "inter-operable" with OpenPGP mail encryption "eco-system", and equally wisely - or even more so - to bypass the arcane and impractical "web-of-trust" (WoT) mechanism of public key attestation by a network of interdependent "key signatures", in favour of requiring the mail users to devise their own methods of securely disseminating their own and verifying correspondent's public key "fingerprints". (see below, under "Public Key Distribution and Verification").
With that development, encrypted e‑mail users have been provided an "e‑mail client" application that is simple enough to use, and that offers a high degree of privacy. If operated with care and discipline, it also provides a reasonable degree of security, as both the content of their messages and the decryption keys are stored nowhere but on their own computer.
The steps required to encrypt‑and‑send and receive‑and‑decrypt e‑mail traffic, as well as those required to perform various key management operations can be found in Thunderbird's OpenPGP documentation. However, following them without good understanding of the fundamentals should never be done if the consequences of the exposure of message content can result in significant monetary loss, reputation damage or worse.
What follows in this text should be considered as some practical advice additional to the documentation provided by Thunderbird developers. There is, however, an important difference between this text and Thunderbird documentation:
Gnupg (the application) and OpenPGP (the standard) assume that the private/public key-pair participates in the web-of-trust network of public key attestation signatures, and consequently, a public key that has collected a number of third-party signatures is of significant value by itself, and will be used by a number of different applications, for multiple security/encryption purposes. Thunderbird documentation implicitly makes the same assumption.
In contrast, this text assumes no participation in WoT, and assumes that a particular private/public key‑pair is simply "a feature of" an e‑mail account. It has no use outside of its use to encrypt and decrypt messages to one specific address (or a group of e-mail addresses, see below, under "GnuPG interoperability").
Before any encrypted messages can be sent or received, the sender must generate a private/public key pair, and must ensure that the public part of the pair is passed on to the correspondents without being maliciously modified by an adversary.
Thunderbird's key generator is invoked by clicking on the [Add Key] button on the End-To-End panel of the [Account Settings] of the e‑mail account already set-up in Thunderbird. When generating the key, the user is presented with several options:
"Your Name": Before generating the key‑pair, set the Your Name entry box either to an empty string, or to a the mail-address user name (i.e., the part of the mail address before the "@" character). Once the key‑pair is generated set it back to whatever you want it to be. The reason for this is to avoid anything other than the e‑mail address "baked-in" as key owner's identity into the generated key.
Key expiry, type and size: Expiry default of only three years is probably too short, 5 or even 10 years might be a better option. Unless you know specific reasons not to do so, keep the type as RSA (the default). However, unless the key is to be used for encryption on old and very slow hardware, or on a server with a large number of simultaneous encryption/decryption processes running in parallel, increase the key size to 4096 bits.
Once created, the key‑pair will be stored in Thunderbird's key‑ring file, located in the profile directory hierarchy.
Private Key back-up: A lost public key can in most cases be obtained using the same method that was used to obtain it originally. Lost or compromised private key can be a much more serious problem. It is therefore common practice to use the key manager to create a backup of it, in form of a digital file, and store that file on a medium or a different computer, preferably at a different location. Since that file must be protected from access by an adversary, it is itself encrypted by a pass‑phrase that must be supplied when the private key is "exported". In order to maintain backward compatibility with other OpenPGP applications, that encryption is not as strong as it could be. Therefore, even though encrypted, it is advisable to guard the private key backups from the adversary.
If the correspondents are only concerned with the security of their messages after they leave or before they are received on their own computers, there is no need to take any special measures in order to protect the secret keys stored as files on their computers. However, in many instances, the computer can be stolen or seized by an adversary, or the adversary can install on the computer malware that can, unknown to the user, expose his private keys. Thunderbird offers the option of encrypting the all private keys with a pass‑phrase that must be entered every time the program is invoked and a message is decrypted. Alternatively, the directory in which Thunderbird stores all its data (Thunderbird "profile") can be placed on an encrypted volume that is not accessible when the computer is powered off.
Mass Surveillance and opportunistic malware: No personal computer, running a "general-purpose" PC operating system (Microsoft's Windows or Apple's MacOS) connected to the Internet, with multiple "Internet-aware" applications, can be easily secured from "opportunistic" malware. The likelihood that such malware will specifically attack or expose Thunderbird encrypted communication is difficult to estimate; mostly because only a very small fraction of e‑mail users encrypts their e‑mail messages.
Targeted Attacks: No personal computer connected to the Internet can be secured against targeted surveillance or attacks performed by malware planted by an adversary with high level of technical competence, especially considering the possibility that such adversary has either voluntary or coerced cooperation of the operating system vendor. Securing the communication against such adversary requires the use of encryption, decryption and clear-text manipulation on computer isolated from the Internet. If the identity of communicating parties must be protected as much (or often even more) than the content of communication, e‑mail is simply not the best method of message exchange.
In order for your correspondent to be able to encrypt messages before sending them to you, they must be provided with your public key, so it can insert it in their Thunderbird key storage. The most common way to provide the public key to a correspondent is attaching it to an e‑mail message. Thunderbird provides such option in "Security" list when a new message is composed. The key can also be posted to any arbitrary file sharing server on the 'net over which the key owner has the control, or it can be written to a file on a USB memory device and given to the correspondent in person. All those methods are fully supported by Thunderbird's key manager.
Key Servers: Another method of public key distribution is to upload the key to the Internet constellation of OpenPGP public-access "key-servers". An example is MIT PGP Public Key Server
Key servers should be avoided. There are two very good reasons for this. First, once a public key (often including user's full name and invariably including the e‑mail address) is uploaded to any server, it becomes impossible to remove it. This is due to the fact that the networked public key servers continuously exchanges keys with all other servers. The second reason is quite quite simple and obvious: since the servers are accessible by anyone, they are an endless source of valid, actively used e‑mails: a great benefit to every spammer and phisher on the Internet.
Even if, despite the above, you decide to upload your own public key to the key server(s), never upload a public key that belongs to somebody else. (Surprisingly, nothing in the design of the server software or in the operational rules and policies of server operators prevents anyone from uploading public key for which he does not possess a corresponding private key).
Public Key Verification:Man-in-the-middle attack is the main problem facing users of public key ("asymmetric") encryption.
However, an adversary intent on such attack faces considerable difficulties. In most instances, his actions are quite easy to detect: all that the owner of public key must do is to publicize the fingerprint of his key on a "public board" on some kind, one that can be accessed anonymously. This puts the adversary in a quandary: he must forge the publicized key fingerprint when it is accessed by the target of his attack, but only then, forging it when it is accessed by the owner (or by someone who received it in person from the owner) will result in the exposure of the attack. For instance, a suitably ornamented photograph that includes the lettering of key fingerprint, posted to almost any web "photo-sharing" service goes a long way toward preventing the active key-swapping, aka. MITM attack.
Public/private key pair can be used for two separate functions: message encryption and message signing.
Digitally "signing" a message is performed by first deriving a "cryptographic hash" of a computer file - for instance the file that represents an e‑mail message. Such hash is a concise and unique derivative of the file. Hash would change substantially even if a single character in the file has been changed. The sender can encrypt the hash with his private key. After receiving the message and the encrypted hash, the recipient can decrypt the hash using sender's public key and compare it with the hash he has derived himself. If the hashes match, the message was indeed "signed" by the sender's secret key.
Note that when signing a message the public and private keys keys are used to perform the exact opposites of what each of the two keys is used when a message is encrypted.
In most instances all e‑mail traffic should be encrypted; if for no other reason, then to deny the adversary the knowledge of which messages are worthy of his attention and which are not. In contrast, message signing should only be done only when it is of some concrete benefit to the recipient, and non-repudiation of a message can not bring additional harm to the sender.
If an attachment is included with an encrypted e‑mail, it will be encrypted, just like the message text is.
Message "headers" (with the possible exception of the "Subject:" line) are not encrypted. To make things worse, SMTP server that accepts the message from Thunderbird and sends it on its way over the Internet, will add additional headers with information that reveals to the attacker additional information not required for the message transportation, but of considerable interest to mass surveillance operators.
"Subject:" line, while technically one of the message "headers", is a special case. Its content has no influence on message transportation and the mail-client program can encrypt it. This is an "option" in Thunderbird, but one that should always be exercised; the only reason not to do so might be interoperability with out-dated mail client programs which have no ability to decrypt the "Subject:" line.
At the time of this writing, Thunderbird requires that the e‑mail address in the public key matches exactly the address in the Thunderbird mail account. The ability to work with public keys that do not include an e‑mail address or to decrypt the messages that do not include the e‑mail address is on the "to-do" list of Thunderbird developers. If and when implemented, this document will be revised.
There is long list of web-mail service providers that claim to use encryption and observe their users' privacy. All such claims should be taken with considerable skepticism. What makes ProtonMail somewhat special is that it gives its users, including those at their "Basic account" (i.e., free) service level the a ability to export their OpenPGP public key by attaching it to an outgoing message, as well as the ability to "ingest" an external user's public key that is attached to a signed incoming message. The procedure is relatively straightforward, and described in ProtonMail's "knowledge base" article.
With that ability, those that have no option but to use a "web-mail" service for their e‑mail (and are not prepared to trust various browser "plug-ins"), ProtonMail provides a viable method to interact with correspondents that encrypt their e‑mail using an OpenPGP capable mail-client program on their computer.
Key creation and maintenance functionality in Thunderbird is quite basic. However, Thunderbird can "import" both private and public keys created and maintained by Gnupg. When private keys are imported, their WoT signatures are not used by Thunderbird, but are tolerated - unless their volume exceeds certain limit. It is thus advisable to remove all such signatures from a public key before sending it to a correspondent for inclusion into his Thunderbird public key repository. This will not be an issue when Gnupg is used only as a "key-generating" application for keys to be used exclusively by Thunderbird mail encryption.
The most common reason for using Gnupg (instead of Thunderbird) to generate the keys is to minimize the information that the public key provides to an adversary. While the present design of Thunderbird makes the recipient's e-mail address inclusion in the public key mandatory, items such as key creation date and the list of all addresses one key is used with should not be part of the public key. In addition, Thunderbird will always create an additional "signing" key instead of using the same key for both encryption and signing. The rationale for this is to enable key-escrow of decryption key - for instance to the corporate entity or government agency - but not do so with the signing key. In most use-cases an entity that demands key surrender (or escrow) is extremely unlikely to make any distinction between two keys.
The following example/procedure has been tested under Linux, with GnuPG version 1.4.23. This is the last gpg version that can be used as Linux "command line" program with no installation. Most Linux distributions will include it in "standard" or "minimum" set of applications, along with the GnuPG version 2.x. If it is not installed, it will be in Linux distribution application software "repositories" from where it can be installed. When both versions are installed, 1.4 executable program will usually be named "gpg1" and 2.x executable will be named simply "gpg".
In addition to the directives provided by interactive user input, gpg program will observe additional specifications provided in a configuration file, named gpg.conf and located in the same directory as the key‑rings. It is suggested to override the default symmetric encryption preference (since this is included in the public key) and to force gpg to display 8 rightmost bytes (16 hex digits) of key fingerprint as the key-id (instead of only 4), by adding the following two lines in the configuration file:
personal-cipher-preferences TWOFISH AES256
keyid-format long
(see gpg1 documentation for details. If the gpg1 is installed,
on most Linux systems it can be displayed by entering either
"man gpg1" or "info gpg1" in the console.)
The instructions that follow assume the reader is familiar with the
features and operation of gpg and with running Linux shell ("command line")
programs - the procedure will be very similar under MacOS or MS Windows
operating systems. (Console display typography note:
First, confirm that gpg1 is installed:
Copyright (C) 2015 Free Software Foundation, Inc...
$
Use a formatted USB device, insert it, change the working directory to
the root of the mounted device and copy the binary to that directory:
(assuming USB device was auto-mounted at "/media/userxyz/usbxyz").
Confirm again the program will execute (change the file permissions
if necessary):
For additional security, key generation and manipulation should be performed on a computer that is not connected to the Internet. The next step and steps that follow should either be performed on a network isolated computer, or on the same computer as was used by previous steps, by disconnecting it from the network and then re-booting it.
Plug USB device into the computer, change to the root directory of USB
device, and create a directory for gpg public and private key‑rings:
We will next generate a single RSA key‑pair (i.e., one key‑pair, used for
both encryption and signing) that has a random key-generation date
(in this case 1737 days before the day of the program run), and a "dummy"
e‑mail address:
The program will start the execution, interactively asking for responses to
its prompts. These should be answered as indicated below:
...
(8) RSA (set your own capabilities)
Your selection?
Possible actions for a RSA key: Sign Certify Encrypt Authenticate
Current allowed actions: Sign Certify Encrypt
Your selection?
What keysize do you want? (2048)
...
Key is valid for? (0)
...
Is this correct? (y/N)
...
Real name:
"noname <noname@example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
(enter a passphrase character string)
The program will harvest random bytes, create the key‑pair, and report:
...
Key fingerprint = 2112 22C0 D2AC 4870 5347 A8AD 21C1 DAA8 F09A A1F2
uid noname <noname@example.com>
As a result of the above key-generation procedure, we have two key‑ring files (pubring.gpg and \secring.gpg) in gDir directory. The keys have only a "dummy" name/e‑mail address (noname, noname@example.com) in them.
A quick note on Key-id: by default, gpg1 uses only 4 rightmost bytes
(8 hex digits) of key fingerprint (2112.....21C1 DAA8 F09A A1F2 ...
4096R/F09AA1F2) as the key ID. If the configuration file
specified "keyid-format long", or if the keys are generated
using gpg v.2.x, 8 rightmost bytes (16 hex digits) would be displayed
instead (4096R/21C1DAA8F09AA1F2).
We can now add all user‑id's/e-mail addresses that the ptivate (decryption) key will be used with. The procedure for adding user‑id's to the key‑pair is simple. It is performed by using gpg in interactive mode, just like in the key generation procedure:
...
gpg>
gpg>
(the same would be done for all e‑mail addresses the key will be used for:
e.g., uglyMustang@posteo.net, angryHedgehog@yandex.com...)
Next, the private key should be exported to an "ASCII-armored" file,
to be imported into recipient's Thunderbir key repository, Since that
(private!) key will never leave recipient's possession, it can contain
all e‑mail addresses it will be used with:
The file (allnames_21c1daa8f09aa1f2_private.asc) is ready to be imported in
Thunderbird key manager and used to decrypt the messages received to all
e‑mail messages that are included in the private key.
Next, create a backup copy of both files, with all e‑mail addresses:
The keys can now be edited, in order to obtain a number of public keys, each containing a single e‑mail address. Such public key file can be sent to one or more correspondents, in order to encrypt messages to the e‑mail address that they use to communicate with the key‑owner.
To delete a user ID from the key‑pair:
...
[ultimate] (1). aardvark <sleepyAardwark@gmail.com>
[ultimate] (2) noname <noname@example.com>
gpg>
...
[ultimate] (2)* noname <noname@example.com>
gpg>
[ultimate] (1). aardvark <sleepyAardwark@gmail.com>
gpg>
The user ID delete procedure should be performed for all addresses, except
for a specific one. Once that is accomplished, the public key should be
exported as an "ASCII-armored" file, ready to be sent to the correspondents
that use the e‑mail address left in the public key file:
The public key file (aardvark_21c1daa8f09aa1f2_public.asc) is now ready to be sent to all correspondents that use sleepyAardwark@gmail.com e‑mail address. This can be done either by importing it into Thunderbird key manager and attaching it to an outgoing e‑mail message, or by some other means. It goes without saying that an out-of-channel public key authentication method should be employed by the correspondent before the key is trusted.
The same procedure should be repeated for other e‑mail addresses that have been added to the key‑pair. Before deleting, the original key‑ring fies, containing all e‑mail addresses should be restored from the backup.
The list of the e‑mail addresses (user ID's) in either the public or
private exported files can be checked as follows:
and
uid aardvark <sleepyAardwark@gmail.com>
uid mustang <uglyMustang@posteo.net>
uid hedgehog <angryHedgehog@yandex.com>
If and when more e‑mail addresses (i.e., user ID's) are added to the key‑pair, the key‑rings should be restored from the backup, one (or more) addresses added, private key with all e‑mail addresses exported and imported into Thunderbird key manager and the key‑rings with all addresses backed up. After that, the public key should be "scrubbed" before sending it to the correspondents that use the newly added e‑mail address or addresses.