Differences in email encryption
As the importance of email encryption constantly rises, more and more email services claim to encrypt. But what are the differences and what kind of encryption is the best?
In the past, email encryption used to be very complicated and, thus, was barely used. This has changed with the rise of encrypted email services like Tutanota. Our users already encrypt two thirds of their emails end-to-end.
Other email providers also have options to encrypt emails, but the differences are huge and not always clear at first sight. So let’s take a look at what kinds of email encryption there are and how these are applied.
First off, we need to consider a few things when comparing different kinds of email encryption:
Encryption in transmission
- Who encrypts (client/server)
- With what is the data encrypted (public key for end-to-end encryption or TLS)
Encryption at rest
- Who encrypts (client/server)
- With what is the data encrypted (user password or common key)
We also always need to look at what data is encrypted: This can be the email content or metadata such as sender names and subject lines.
Each of these methods must be considered when comparing encrypted email services. For maximizing the security of your data, it’s best if the service provider encrypts as much data as possible and has no access to the encrypted data.
Differences in email encryption
Encrypted transmission of emails
To send an email securely, the bare minimum is TLS encryption for transmission.
This is protection against passive eavesdroppers like ISPs. The encryption method is to build an encrypted tunnel between mail servers so that the emails can’t be spied upon while they are sent from server to server. No email in 2020 should be sent over plaintext, i.e. without TLS encryption, period.
For maximum security, end-to-end encryption should be applied as well. For this, the data should be encrypted with the private key that is solely accessible to the user so that any third party is kept out of the conversation.
This is the case if you use PGP and manage the private key yourself. This is also the case if you use Tutanota where your private key is encrypted with the help of your password on the client so that Tutanota can manage the key for you while making sure that only the person knowing the password (=you) is able to decrypt the private key.
For end-to-end encryption to be effective the private key must be owned by the user and unaccessible to the provider. This can be achieved by protecting the private key with the user password like in Tutanota, but some providers don’t do this properly.
For instance, Gmail enables its users to upload their ‘private keys’ to the servers with Open PGP as Gmail has abandoned its project for true end-to-end encryption long ago. Like all server-side encryption, this is not really trustworthy.
When the data is encrypted on the client, the encryption takes place before it is being sent. This way no third parties, not even the server of the email provider sees your emails. If all clients that handle the encryption are open source - which is the case with Tutanota - tech-savvy people can also verify that the encryption is done properly and can’t be backdoored.
Such end-to-end encryption where the private key is solely accessible to the user is much preferred to relying on TLS encryption only.
What’s more, with Tutanota you can send an encrypted email in seconds. Check here how.
Encryption at rest
When the emails have reached the end point - the server of your email provider, the data can be stored encrypted. This is encryption at rest.
Most providers encrypt everything with one key. That’s the bare minimum if the provider wants to protect your email data from malicious attackers. Encrypting at rest doesn’t protect from the service owners themselves, doesn’t protect from legal orders but possibly can help if the disk itself is stolen.
For “at rest encryption”, providers can also encrypt the data with the user password, but on the server side. This method seems to be secure as the user gets the impression only he himself with his password can unlock the private key. However, every time the user logs in, the server needs to be trusted to send the decrypted data to the user - but there’s no guarantee that the decrypted data is not being sent elsewhere simultaneously.
Riseup uses this method to encrypt data at rest. This method of encryption is better than nothing and can probably help the provider for not being forced to comply with some legal orders. Yet, it requires the user to ultimately trust the service provider because one cannot verify what is taking place on the server side. This kind of encryption also doesn’t help much if the server itself is compromised.
What data is encrypted
It is also important to look at what data is encrypted. For example solutions based on OpenPGP such as Protonmail can only encrypt parts of the emails: body and attachments. This approach is a historical artifact and leads to numerous security vulnerabilities as shown by efail.
Tutanota does not rely on PGP to ensure that your data is kept secure. This way Tutanota can also encrypt much more data: body, attachments, subject lines, and sender names. The only remaining data in Tutanota that is not yet encrypted are email addresses and times of emails.
We have achieved to encrypt all meta data, including times of when events are taking place, with our encrypted calendar, but with emails this is more complicated due to the way the email protocol works.
On top of the encryption, it is also important that an email provider takes care of lots of other security measures such as two-factor authentication, stripping of IP addresses, not loading images automatically, and more. Learn here which security measures are essential.
At Tutanota we work hard to develop the most secure email service possible.
Happy encrypting. 😀