Email is often used to reset passwords to your Internet accounts, or to communicate with government agencies or companies. Unlike secure instant messaging, e-mail is universal: you can send an electronic message to anyone who has an e-mail address, regardless of their provider. Given its universality, each of us has at least one, and more often several, email addresses for our various uses.
Important, official information and documents pass through this channel, so given its sensitivity, we assume it's secure... **Really?
Let's remind ourselves of the basics:
Step 1
You write a message in your e-mail client, which is then “unencrypted” because the application you are using is not encrypted (Outlook, GMail, Thunderbird, etc.).
Step 2
To send it to the recipient, you upload it from the mail client to the mail server using the SMTP protocol. This protocol uses ports, which are like “gates” to identify the location of data to be delivered between a client and a server. These ports are numbered from 1 to 65,536, and each is used to transmit a specific type of information.
The ports for mail protocols are :
Step 3
Your provider's mail server forwards your message to the recipient's mail server. (Often passing through the intermediate servers of each provider).
Step 4
The recipient's e-mail client will load the received message onto the server using the POP protocol, or read it on the server using IMAP.
E-mail wasn't created to be secure, just to communicate. If you don't do anything about it, it's the weakest link in your confidentiality (content readable at several stages) and security (modifiable by a third party at the same stages).
Let's list the different existing safety levels according to the means used:
Level 1 : Email is not secure at any stage:
=> “classic” messaging and unsecured protocols.
The 1st thing to do is to make sure that your messaging system uses TLS encryption protocols during transport (see your application's settings).
Level 2 : Email is secure during transport, but not on clients and servers:
=> “classic” messaging and secure protocols.
The next step is to deploy an email content encryption solution.
Level 3 : Email is secure during transport and on servers, but not on email clients:
=> “classic” messaging, secure protocols, active encryption.
The next step is to deploy an end-to-end encrypted messaging solution.
Level 4 : End-to-end email security:
=> the use of “classic” messaging is not possible in this configuration.
Now that TLS encryption protocols are generally natively enabled, let's see how to take the next step and encrypt the content of e-mails passing through your usual e-mail protocols: These are PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions).
The disadvantage of these solutions is threefold:
1- It needs to be implemented on your current mail system.
2- It's not “automatic”, as it requires you to have the recipient's public key.
3- It doesn't solve the problem of unprotected mail clients (not E2EE).
This encryption method dates back to the 90s, and is a hybrid cryptography (symmetrical and asymmetrical) that can encrypt and sign, is open-source and decentralized. It can encrypt any type of data (including files, not just e-mails).
To use PGP, you need to install an add-on or choose a messaging service that offers PGP by default. PGP generates a pair of keys: a public key, which is used only for encryption, and a private key, also known as a session key, which is used for decryption. Users must transmit their public key to their contacts. The sender uses the recipient's public key to encrypt the e-mail, then sends it to the recipient. The recipient uses his or her private key, to decrypt the e-mail.
Distributing one's public key can be a real challenge: if you send it via an “unencrypted” email, there's no guarantee that an attacker won't replace it with his own, and you'll never know. To overcome this problem, either send a digitally signed e-mail including your public key to the recipient, or use a key server on which you can publish and search for public keys (e.g. keys.openpgp.org). You can also use an encrypted file transfer or messaging service.
There are computer applications (GPG Suite/Tools for Mac Os), third-party applications and browser extensions, all open source and free (or not). Let's start with implementations in native IOS apps, and take a look at the only free, open-source app that integrates with Mail of IOS : PGPro.
The PGPro app lets you encrypt/decrypt an email by switching from the third-party app to the Mail app quite easily. The prerequisite is the generation of a key pair using the “Keychain” menu and the integration of your recipients' public keys.
1- From PGPro, in the “Encryption” tab, select the recipient (i.e. his public key) and write a message, then click on the closed mail icon.
2- This automatically switches you to the Mail app, where the encrypted message appears.
3- Send the message as usual in the Mail app.
1- From the Mail application, receive the encrypted email and copy its contents.
2- Open PGPro's “Decryption” tab. Select your private key and copy the encrypted content.
3- Decrypt the message by clicking on the open mail icon.
I can see some of you making a face: installing an additional app, managing keys, copy/pasting, not being able to just sign a message, skipping attachments... Ok, some features are missing, but let's not be unfair, what this app does is encrypt/decrypt in the Mail app, and it does it well!
As I anticipated the comment, we'll see that there's a well-known third-party application that uses PGP encryption natively: Proton Mail. But first, let's take a look at what S/MIME allows you to do to keep in line with the native mail application's encryption approach.
This standard also dates back to the 90s, and allows you to sign and encrypt your messages. Unlike PGP, it is centralized and proprietary (this is one of the reasons that led to the development of an open source solution in the form of PGP).
S/MIME uses public-key cryptography: a certification authority issues an X.509 certificate which, once implemented in the messaging client, enables the use of asymmetric cryptography. Unlike PGP, this format is designed for e-mail only.
Key exchange constraints, although similar to those encountered with PGP, are a little more flexible. The sender's certificate is pinned to the digitally signed message, enabling the recipient to save it in his or her keychain. What's more, with S/MIME, this signed message remains “in the clear”, unlike the one signed with PGP. The sender therefore doesn't need to be in possession of the recipient's public key for the latter to be able to read it. The recipient can then reply to the message by encrypting/signing it, thus completing the key exchange cycle.
That said, let's take a look at how to integrate S/MIME into IOS.
We mentioned earlier that this format is centralized and therefore expensive, and therefore generally better suited to organizations as well as individuals. Most certification authorities provide X.509 certificates on a subscription basis or free of charge for very short trial periods. However, there is one reputable certification authority that offers free certificates for annual periods: Actalis.
Once you've registered using the personal information requested, you'll receive a 1st message confirming your e-mail address, followed by a 2nd with a PKCS12 certificate valid for 1 year.
Installation is very simple:
Sign : Yes
Encrypt by default : Yes
When the email is received, the signature symbol appears next to the sender's name, indicating that the message has been signed.
Clicking on the signature symbol will download the certificate, enabling you to add it to your keychain and send an encrypted e-mail to your contact.
(When enabled and if you have the recipient's public key).
When sending or receiving e-mail, the encryption symbol (the padlock) appears next to the sender or recipient name, indicating that the message is encrypted.
Otherwise, the message will not be encrypted and an “Encryption impossible” alert will be displayed.
Implementing email encryption is the maximum level of security achievable with “classic” email, but does not enable end-to-end encryption:
=> Messages are secure in transit, but remain unencrypted in the messaging application.
To correct this weakness, the only solution is to change your habits and migrate to a specific application, specially designed for security.
If you're not using an end-to-end encrypted application, it's highly inadvisable to send confidential data by email. Instead, use an instant messaging application such as iMessage, WhatsApp, Signal or Olvid.
So, you've decided to take the plunge and leave the dark side of Gmail, Outlook and Apple Mail for the light side.
The criteria to consider when making your choice will probably be: Security - Confidentiality - Ease of use - Price. If you do a little research, your final selection will probably include Proton Mail and Tuta Mail.
Without going into the details of how these messengers work, let's remember that while their design is very different, their use is similar:
Proton Mail has the merit of having democratized end-to-end encrypted e-mail. Launched in 2013, it boasts a very large community of 100 million users, it surfs on a very complete ecosystem including messaging, Cloud storage, password manager, VPN and reventique its installation in Switzerland, which on the other hand guarantees nothing as their Transparency Report indicates. We'll focus here solely on messaging, which offers advantages and disadvantages depending on your point of view...
As mentioned above, Proton Mail is based on the PGP encryption method:
Advantage:
- End-to-end encryption of the message body and attachments, and compatibility with “classic” messaging encryption systems.
Disadvantagess:
- No encryption of metadata, especially the subject line.
- No PFS (Perfect Forward Secrecy): compromise of the encryption key gives access to the decryption of all past messages.
- Not resistant to quantum computers.
Password reset is possible using a backup email or phone number, which is a problem if these channels are compromised, but an advantage in terms of ease of use.
Advantagess:
- Complies with the RGPD directive and does not collect your data (with the limit of judicial requisition mentioned above).
- Replaced Google's reCaptcha with its own, thus removing this anomaly that remained.
Disadvantage :
- The existence of an IMAP bridge with traditional messaging services means that messages can be stored in clear text on these third-party email clients.
Advantages :
- Imports from third-party mailboxes possible.
- Configurable auto-delete emails.
- IMAP bridge, enabling you to use your usual e-mail client (see above for the disadvantage in terms of security/privacy).
- Very large user community, which increases the probability that the recipient will receive the message directly in E2EE.
Disadvantage :
- No access to the thread for a “non Proton Mail” user in E2EE.
Advantages :
- Possibility of using a free account. Access to scalable paid packages offering, Cloud space, email aliases, custom domain support, VPN, password manager.
Disadvantages :
- Access to the IMAP bridge, aliases and personalized domain requires subscription to a paid package.
- Offers are expensive (€3.99/month for access to the IMAP bridge and 10 e-mail addresses, €9.99/month for the offer with 15 e-mail addresses and unlimited aliases, 500 GB Cloud and full VPN).
Tuta Mail has been around since 2011, longer than Proton Mail. Yet its user community is 10x smaller, with a total of around 10 million. It only offers a messaging service, but after all, that's what it's all about! Its servers are located in Germany.
Advantages :
- Message security: Quantum-secure hybrid encryption algorithms combining a post-quantum key encapsulation mechanism (CRYSTALS-Kyber) and Elliptic-Curve-Diffie-Hellmann key exchange (x25519).
- Encrypts the entire e-mail (body and attachments) as well as metadata (including the subject line).
- Enables PFS (persistent confidentiality).
Advantages:
- Complies with the RGPD directive and does not collect your data (with the same limitations as Proton Mail).
- Uses its own open source Captcha and therefore does not provide data even indirectly to Google.
- Open source desktop clients and mobile apps.
Advantages :
- Thread access for “non Tuta Mail” users in E2EE.
- White-label messaging available.
- Secure contact form (unfortunately not available for all paying accounts).
Disadvantages :
- No mass import of third-party messaging (although this has been announced for several years).
- No self-destruction of messages.
- No compatibility with third-party clients.
- Limited user community, limiting the probability that the recipient will receive an email natively in E2EE.
- No Passkey connection.
Advantages :
- Possibility of using a free account. The offer allowing the use of a personalized domain name and 15 aliases remains less expensive than Proton (3€/month).
Disadvantage :
- The recent tripling of the price of the pay-as-you-go offer may give cause for concern (or reassurance about the resilience of the service, depending on how you look at it).
If we balance the pluses and minuses, we can summarize as follows:
Tuta Mail only provides an E2EE messaging solution (and that's what it's asked for), but it does so without compromising on its trademark security. Its rise to prominence requires that the addition of features expected by the community not be delayed too long.
While Proton Mail offers an E2EE messaging solution, it focuses more on features that facilitate day-to-day use (interoperability, rich ecosystem). Only time will tell if this is the right solution, and how it will cope with post-quantum cryptography, which is clearly this solution's biggest challenge.