The Problems With End-to-end Encryption
Why End-to-end encryption isn’t the solution for everything.
What Is End-to-end Encryption?
End-to-end encryption is a way to ensure only the sender and recipient of a message can see it. The message is encrypted on the sender’s device and can only be decrypted once it reaches the recipient. Although the message may be sent through one or more servers, it’s only stored in its encrypted form. When properly implemented, even the company hosting the service couldn’t read the messages even if they wanted to.
How It Works
End-to-end encryption makes use of something called asymmetric encryption (often RSA). This form of encryption makes use of two keys: a public key, and a private key. Either key can be used to encrypt data, and that data can only be decrypted with the other key. Generally speaking, data is encrypted with the public key and decrypted by using the private key. Because of this, the public key can be available for all to see without the security being compromised.
Here’s a simplified explanation of how end-to-end encryption would work for a messaging app:
- Upon setting up the app, a public and private key pair is created and the public key is uploaded to a server
- To send a message, the sender requests the public key of the recipient from the server
- The sender’s device then uses the recipient’s public key to encrypt the data on the device, ensuring the non-encrypted version never leaves the device
- The message is then uploaded onto a server in its encrypted form
- The recipient’s device pulls the encrypted message from the server
- Using their own private key, the recipient decrypts the message
This example is overly simplified, and probably has at least a few missing steps. For example, RSA doesn’t deal well with large messages, and is therefore rarely used by itself to send things such as images. Instead, a symmetric cipher is used (a cipher for which the same key is used for both encryption and decryption), and the asymmetric cipher is used to securely share the keys for the symmetric cipher.
This Sounds Great
While end-to-end encryption sounds great on paper, it’s not so great in real life. It does have many legitimate uses, and there are plenty of messaging services that do use end-to-end encryption behind the scenes, but it’s not perfect. Here are a few of the problems with end-to-end encryption:
End-to-end encryption is much harder to set up than using no encryption, or using non-end-to-end encryption. It may simply not be worth it for some services to implement end-to-end encryption. There may be other features the company feels are more important, which means they divert resources for those instead of building end-to-end encryption.
Remember that end-to-end encryption is not the only type of encryption out there. It’s significantly easier to just send the message over HTTPS to secure it during transit, and store the messages on an encrypted disk to secure the data at rest. This prevents anyone from intercepting the messages while being sent, and ensures that even if a server is physically stolen from a data center the messages can’t be recovered. Encrypting data like this may seem good enough, and I’d argue that it is for more casual forms of communication (like an online chatrooms).
If you forget the password to your phone, you just lost all of your messages. As the private key exists only on your device, resetting your phone’s password means losing everything on it, including the private key. For all other data, which is backed up in the cloud, resetting your phone isn’t much of a problem. But, as the private key exists only locally (or, at least, it should), there’s no way to recover your messages. Although the private key can be backed up along with all of your other data, this negates many of the benefits of end-to-end encryption in the first place. For example, if the government gets a warrant to access your data, all they need is to retrieve the private key from wherever it’s backed up, and they can then decrypt your messages. If the private key only exists locally, there’s nothing they can do, assuming you have a secure password on your phone.
The way to fix this is to either, as previously mentioned, back up the private key, or just not use end-to-end encryption at all. If your messages are encrypted via a combination of HTTPS and disk level encryption, you can reset your password without losing access to your messages.
Although it is possible to implement group chats with end-to-end encryption, it’s even more complicated than with one recipient. One approach is to encrypt each message sent with the public keys of each recipient, which requires more processing power on your phone, along with more storage and network bandwidth among other resources. Even other solutions, like generating a symmetric encryption key, encrypting that will everyone’s public key, then just using the symmetric key for encryption still incurs additional overhead. On top of that, with end-to-end encryption, if you add someone to a group chat, they can only see what you sent since adding them as everything sent before that wasn’t encrypted with their public key. In many cases, this is how you expect group chats to behave in the first place, but what if you want a new recipient to have access to everything sent up to that point (such as a group chat used for sharing important dates)?
End-to-end encryption requires that more work be done on the client, which can slow down older devices. While modern CPU’s can encrypt data relatively quickly, the slowdown may be noticeable on older hardware. Think of schools or businesses which may be relying on computers made more than a decade ago; how fast do you think those CPUs can encrypt messages?
End-to-end Encryption Is Important
Regardless of its flaws, I do believe end-to-end encryption should be used more often than it is. In a world where more and more of our data is being sent over the internet, it would be nice to know what I send to someone can only be read by them. But, I do understand the significant amount of time and effort it would take to implement it, and some of the drawbacks that would have.