Electronic mail (email) is currently a standard and necessary medium in the daily life of people in most countries. More than half of the world’s population uses email communication [56], and billions of emails are sent every day [57]. An email address is a common part of contact information not only in personal areas of life, but also in business, education or government.
The long-term intensive usage of email yielded many additional features besides pure text communication. Some of these, like email attachments, introduced a lot of potential attack vectors. Common threats of email communication include:
- eavesdropping due to lack of data-in-transit encryption,
- unauthorized data access on servers or server data leaks,
- malicious email content, • man-in-the-middle attacks due to lack of authentication or
- modification of data in transit.
The basic practice is to encrypt data during its transport over the Internet. There are two encryption layers of electronic communication: transport-level and end-to-end encryption.
Transport-level encryption
Simple Mail Transfer Protocol (SMTP), defined in RFC 5321 [58], is the standard communication protocol for email transmission over the Internet. SMTP transports data from user email clients and between individual mail transfer agents. Internet Message Access Protocol (IMAP), defined in RFC 9051 [59], or Post Office Protocol (POP3), defined in RFC 1939 [60], are protocols for email retrieval from mail servers to the recipient user email clients. The core design of these protocols uses an unencrypted TCP/IP connection.
SMTP, IMAP, and POP3 data are commonly wrapped into the Transport Layer Security (TLS/SSL) cryptographic protocol to establish an encrypted channel between mail transfer agents and email clients.
TLS is the successor of the obsolete SSL, with the current approved version 1.3 defined in RFC 8446 [61]. The TLS protocol provides confidentiality, integrity and authentication via TLS certificates. Therefore, a channel secured by TLS remediates the problems of eavesdropping or modification of data between mail servers and unauthenticated communication. TLS communication is a common practice nowadays – according to the transparency report by Google [62], over 80% of incoming mail is transferred over TLS.
Since individual pairs of servers in the transit establish a shared key for the TLS channel, the email data needs to be re-encrypted on each relay. Malicious third parties can thus access email data in plaintext if the mail server is compromised. The email history is also commonly stored on the mail servers to allow synchronization between devices, making the servers a convenient target for attackers and putting sensitive data at risk.
End-to-end encryption
End-to-end (E2E) encryption secures communication over a network preventing third parties from accessing the data in transit. Such encryption takes place at the origin endpoint and decryption at the receiving endpoint, all above the transport layer. This approach ensures that data is always encrypted – even on untrusted mail servers or if a server does not support the TLS/SSL protocol and communicates in plaintext.
The benefits of E2E encryption are debatable. While it is favourable for individuals to protect their privacy, encryption poses a threat to the investigation of criminal activity since the data is unavailable. The problem of security through and despite encryption is still open and has raised suggestions to ban E2E encryption in the future. Another drawback directly related to user privacy is the destruction of spam and malware filtering. Depending on the software, some applications might rely on server-based scanning and phishing protection, which is impossible with E2E encrypted data.
The most common protocols for E2E email encryption are OpenPGP and S/MIME.
OpenPGP
OpenPGP is a standard for email encryption defined in RFC 4880 [52]. The protocol uses symmetric and asymmetric cryptography to provide confidentiality, authentication, non-repudiation and key management to Internet communications and key storage. It is derived from Pretty Good Privacy (PGP), a software developed by Philip R. Zimmerman, and serves as a basis for other email encryption software, e.g., GnuPG.
In contrast with S/MIME, OpenPGP uses a decentralized trust model based on the exchange of public keys between peers with key fingerprint authentication. S/MIME uses a centralized model built on certificates, which requires issuing a trusted certificate by third parties to establish encrypted communication between peers. OpenPGP is more suitable for personal use by regular users in the scope of this work – the establishment of communication is more straightforward than using S/MIME.
OpenPGP prescribes a variant of Cipher Feedback (CFB) mode of a selected symmetric cipher for symmetric encryption, where the selection depends on actual OpenPGP implementations. Possible ciphers include AES, Twofish, Blowfish or TripleDES.
For asymmetric cryptography, OpenPGP prescribes Elgamal for encryption and DSA for signatures. Implementation of keys defaults to RSA, but implementation based on elliptic curves is also allowed.
Even though the first OpenPGP RFC originated in 1998, E2E email encryption is still an infrequent practice. The usability of PGP software was first tested in 1999 by Alma Whitten and J. D. Tygar. The conclusions of their work pointed out several usability errors and overall user failure to establish encrypted communication securely [63]. Thanks to this work, the study of usable security has significantly developed [64, 65, 66, 67], and more effort has been made to develop secure software usable by the general public.
However, the main usability drawbacks remain with OpenPGP implementations, even after 20 years. The keys usually have to be operated by users manually to share the public key with other peers or move the keypair to different devices for synchronization purposes. This manipulation creates a threat of publishing private parts of the key. Since just one key is typically used for all emails, whole communications could leak if the private key gets captured. Several security experts and cryptographers recommend against using PGP, asking for it “to die” [68].
E2E email encryption can be recommended to regular users only if the software implements easy-to-use key management, which would not pose a burden in learnability and allow users to make critical mistakes. Only then users could perform the encryption correctly without expert assistance [64].
Ideal email client
The testing is focused mainly on email encryption options and usable security to describe a privacy-protecting email client. An ideal client should provide all the essential functionality that users expect based on their previous experience.
The essential functionality includes:
- managing IMAP and POP email accounts,
- customizable email filtering and folders,
- a usable email composition editor, and
- email synchronization.
Ruoti and Seamons summarized the research on usable security of email encryption [64]. They defined several desirable properties of the email client interface, which should protect users and ensure they would not give up encryption. This research posed as a template for evaluation and results are shown in Table 5.1.
Candidates
The set of selected and tested email client candidates consists of Thunderbird, Evolution, KMail and Claws Mail. Mailvelope and FlowCrypt browser extensions were tested for webmail E2E encryption.
Only Thunderbird description is included in this section as a recommended option. All other candidates are described in Appendix C. The usability comparison can be found in Table 5.1 and an overview in Table C.1.
Thunderbird
Thunderbird is an open-source email client licensed under the Mozilla Public license version 2. Support is provided for Windows, macOS and Linux systems.
Thunderbird provides all the essential functionality, including numerous possibilities for customization. Additional features are offered by extensions.
End-to-end OpenPGP encryption is the built-in functionality of Thunderbird. It was introduced in version 78.2.1 by replacing Enigmail, the previously used add-on delivering OpenPGP support. Email encryption is not used by default – the OpenPGP key needs to be generated or imported in the settings and encryption enabled in the separate window dedicated for writing individual emails.
Thunderbird uses RNP, an actively developed open-source library, to implement the OpenPGP encryption standard. A fair amount of key setup is hidden from the user: OpenPGP key can be generated in the application GUI directly, yielding a 3072-bit RSA keypair with a three-year validity period by default. It is possible to switch to either 4096-bit (RSA) key size or a 3072-bit ECC key. The key is saved automatically into the Thunderbird profile folder, located in the user home folder on Linux systems separated from Thunderbird program files.
The key is sufficiently protected from within the client against user errors. To establish encrypted communication, only the public key can be extracted to file or sent as an email attachment. If the user wants to back up the whole key, Thunderbird exports a password-protected file encrypted by AES and does not provide an option to store the key in plaintext. However, it lets the user choose a weak, brute-forceable password.
Public keys for other email addresses can be imported from a file using the OpenPGP Key Manager functionality. To authenticate a user during key exchange, Thunderbird recommends connecting with the second party over a different channel and reviewing key fingerprints manually.
By default, encryption is not enabled even if Thunderbird stores the recipient’s public key. On the other hand, if the user enables required encryption, emails will not be sent to users whose public key is not saved and recognized by Thunderbird.
Additional security-enhancing features of Thunderbird include a setup wizard, built-in phishing protection and warning about spoofed URLs in messages, automated updates of the client or automated blocking of remote images to avoid potential malware infection.
Comparison of OpenPGP software usability
| Thunderbird | Evolution | KMail | Claws Mail | Mailvelope | Flowcrypt | |
|---|---|---|---|---|---|---|
| essential functionality* | 🗸 | 🗸 | 🗸 | 🗸 | 𐄂 | 𐄂 |
| tight integration* | 𐄂 | 𐄂 | 𐄂 | 𐄂 | 🗸 | 🗸 |
| tutorial* | 𐄂 | 𐄂 | 𐄂 | 𐄂 | 𐄂 | 𐄂 |
| trustworthy design* | 🗸 | 𐄂 | 🗸 | 𐄂 | 🗸 | 🗸 |
| easy key management* | 🗸 | 𐄂 | 𐄂 | 𐄂 | 🗸 | 🗸 |
| secure key management* | 🗸 | 𐄂 | 𐄂 | 𐄂 | 𐄂 | 𐄂 |
*
Essential functionality is described in Section Ideal email client.
Tight integration means that email encryption fits within users’ existing workflows, such as the GMail webmail client.
Tutorial provides guidance of first-time users through the process of sending encrypted email.
Trustworthy design allows users to see that email will be encrypted before sending.
Easy key management means that it’s automated.
Secure key management does not allow users to export a private key in plaintext without password confirmation.
Overview
| license | latest version as of May, 2022 |
supported platforms | |
| Thunderbird | Mozilla Public license 2.0 |
V91.9.0 May 3, 2022 |
Linux, Windows, macOS |
| Evolution | LGPL | V3.44.1 Mar 18, 2022 |
Linux |
| KMail | GPLv2 | V5.20.1 May 12, 2022 |
Linux |
| Claws Mail | GPLv3 | V3.19.0 Apr 2, 2022 |
Linux, Windows |
| Mailvelope | AGPLv3 | V4.5.2 Apr 4, 2022 |
Linux, Windows, macOS |
| FlowCrypt | FlowCrypt | V8.2.7 Mar 25, 2022 |
Linux, Windows, macOS |
Email communication recommendations
The problem with the usability of E2E email encryption persists. Most modern implementations still require an understanding of the concepts to preserve intended security.
Thunderbird was evaluated as the most suitable solution for beginner and intermediate users keen on security and privacy. The built-in OpenPGP support does not allow leakage of private keys from within the client, and the key management has acceptable learnability, even though it requires some user effort to adjust to the new concept. Another vital advantage against other clients is the built-in phishing protection, which includes spam filtering, blocking potential viruses and warning about potentially spoofed URLs. The protection is important since the spam scanning on mail transfer agents is ineffective on E2E encrypted communication. Other software relies on third-party phishing protection tools, which usually require additional, potentially non-trivial setup.
If the user decides to stick to a webmail provider like Gmail with E2E encryption by a browser extension, it is crucial to disable automatic usage statistics and crash reports for the browser provider. The reports can include private keys [69].
Instant messaging (IM) application were not included in our studied categories. The choice of an IM client is influenced by multiple factors and clients implement several different E2E protocols. However, it is appropriate to mention some IM clients supporting E2E encryption as OpenPGP implementations are far from ideal. Herzberg and Leibowitz analysed usability of establishing E2E communication using several IM clients [67] and illustrated, that utilized protocols are simpler and more usable than using OpenPGP implementations since they require less user intervention. Noteworthy open-source IM clients supporting E2E include Telegram[1], Signal[2] or Keybase[3].
Appendices
Evolution
Evolution is an open-source email client included in systems with the GNOME desktop manager, licensed under the LGPL license. The client can be installed on Linux systems with a different desktop manager and Windows and provides essential functionality.
Evolution provides built-in support for OpenPGP encryption based on GnuPG.
GNOME Seahorse application (Passwords and Keys) manages GPG keys, which means that keys cannot be generated or imported from within the client directly. Seahorse is, however, included in GNOME systems by default as well.
Seahorse generates 2048-bit RSA GPG keys by default without an expiration date. Elliptic curve keys cannot be generated.
The encryption process is not described in the application. Users have to figure it out themselves or from different sources. Only one encryption key can be used per account since Seahorse chooses the key automatically, and users cannot specify which one to use. Furthermore, the export option in Seahorse does not describe which part of the key is being exported – the options must be accessed differently to export the public or private key. Exporting the private key in plaintext is possible after entering the key password, without any warnings.
The overall email encryption using Evolution and Seahorse is not intuitive, requires a trial-and-error approach and should not be recommended to regular users. Evolution also recommends using third-party spam filtering tools and does not provide this functionality natively.
KMail
KMail is a default email client for the KDE Linux desktop environment, licensed under the GPLv2 license. This client is supported on Linux systems only.
In terms of email encryption, KMail is very similar to the Evolution client. The configuration and usage of GPG keys are not ideal. On the other hand, KMail has some additional features on top, like the attachment of public keys without importing them from a file or the built-in generation of password-protected keys. KMail even displays a warning when a weak password is used to protect the key. When composing an email, the user is informed sufficiently whether the email will be encrypted or signed. If multiple keys corresponding to one identity are found, the user can choose a specific one as well as choose specific keys for both encryption and signing. Keys can be exported using the local keyring – either KWallet on KDE systems or Seahorse on GNOME systems.
Similarly to Evolution, developers of KMail recommend using external specialized spam filtering solutions like Bogofilter or SpamAssassin.
Claws Mail
Claws mail is an open-source lightweight email client available on Linux and Windows, licensed under the GPLv3 license.
The client is highly customizable, with all the essential functionality included. A setup wizard is launched to set up the client effectively with TLS/SSL encryption enabled by default.
Google denies authenticating users to the Claws Mail client. To enable Gmail access from within the client, users must confirm agreement with “lesser secured applications access” in their Google account[4]. It is an insecure practice with the Google account and not trivial to perform.
E2E encryption is not included in the core client application, and dedicated plugins must be installed to provide E2E email encryption based on GnuPG implementation. An additional plugin needs to be installed to enable spam filtering as well.
Mailvelope
Mailvelope is an open-source browser extension licensed under the AGPLv3 license. It provides OpenPGP encryption in Chrome, Firefox and Edge browsers. It is compatible with various mail providers, including Gmail.
By default, Mailvelope uses OpenPGP.js implementation of the OpenPGP protocol, but it can be implemented by GnuPG if it is present on the user system. Generation and export of keys are included. 4096-bit RSA keys are generated by default with an option to switch to experimental ECC.
Mailvelope is focused on usability and tries to make OpenPGP bearable for regular users. Unfortunately, users are allowed to make critical mistakes with the key management, e. g. set a one-character password for the key or export the private part of the key into a plaintext file easily.
FlowCrypt
FlowCrypt is a browser email encryption extension designed for integration with Gmail. It is licensed under the FlowCrypt License.
Similarly to Mailvelope, this extension is designed for simplicity. The integration with Gmail is similar to its native design. Generation of the OpenPGP key yields an ECC key – the encryption settings are not available, and regenerating a new key is impossible. The user cannot choose a weak password, with the strength evaluated by their password quality meter. The user also needs to confirm that the password was written down and stored in a safe place. The key is automatically backed-up encrypted in the Gmail server inbox.
Unfortunately, the private key can be exported into plaintext with just one click without further user confirmation.
- https://telegram.org/faq#secret-chats ↑
- https://signal.org/ ↑
- https://keybase.io/ ↑
- Google announced to enforce denial of authentication to applications via username and password only from May 30, 2022 [85]. ↑