The ends of encryption

Today’s security headlines feature data breaches, backdoor debates, and privacy concerns. Some companies sell information about their customers while others stack up multiple measures to protect privacy. One of the defenses employed by the latter is called end-to-end encryption. If done right, end-to-end encryption nullifies the impact of a data breach, makes backdoors unusable and is the ultimate solution to customer privacy. This technique is a potent tool and, like everything else, is a tradeoff. The goal of this post is to discuss E2E encryption: what it is exactly? How does it work in practice? And most importantly, is it even worth it?

What is end-to-end encryption?

To best answer this question let’s take a look at the parts. Encryption is the act of transforming a message using a secret key. For anyone not in possession of this key, the message is unreadable. Some encryption schemes go as far as making the resulting encrypted text indistinguishable from random noise. Encryption makes it possible to have secure communications over non-secure channels. One party can encrypt a message, send it over the wire, and have the receiving party decrypt it. Any adversary over the wire only sees the encrypted message gaining no information.

So what’s the end-to-end?

Well, this is a bit tricky. In theory, this means that one party encrypts a message and only the designated receiver can decrypt it, no one else.

Doh, this is how encryption works anyway, what makes end-to-end special?

CC0 image by Silvia & Frank

All right, I will cut to the chase. Think of the following analogy: you write a postcard and would like to send it to your friend. Since the letter is intended for your friend, you do not want anyone else to read it. Hence you need to find a secure delivery method. Luckily the postal system provides such a way. They guarantee to protect the confidentiality of your letter. So, how does the postal service fulfill such guarantee?

Here is a diagram. It clearly illustrates the points you’ll read about next.

Confidentiality by the postal services

First, you have a locked mailbox where you can place your letter for pickup by the mailman. While your message is sitting there it is protected, no one can open that mailbox, but your mailman.

Eventually, the mailman comes and carefully places all the letters from the box into his locked bag. He does not carry a key to his bag, so it can only be opened at the post office.

Finally, your letter reaches the postal office where it is processed by a clerk. Once the sorting is finished, your mail is dispatched via a truck. Again, the truck is protected by a lock.

At the destination your mail is processed once more and then arranged for delivery.

The local mailman puts your message into his locked bag and finally delivers it to your friend’s house. There, he places it in your friend’s mailbox.

At the end, your friend unlocks her mailbox, reads your letter and happily contacts you in seconds using modern technology. It is the 21st century after all.

Quite a journey, so what’s happening behind the scenes?

The letter’s confidentiality was guaranteed by placing it in locked boxes, where only the next destination is capable of opening the box. This is indicated by the differently colored locks beside each step. Think of this as encryption. The postal service fulfills your confidentiality requirement by “encrypting” your letter during the transfer protecting it from prying eyes.

Whenever your message is in motion or is stationary; it cannot be read. There is a twist though, you may have noticed, there are times when your letter is not in a locked box. So what happens at the different processing points?

Well, as it turns out, the postal service protects your letter from everyone with one small exception, themselves. During processing, postal workers may freely read your message and process it as nothing happened.

This is where end-to-end encryption comes in. Think of this as a special envelope that cannot be opened by anyone except your friend. When you send the letter, you place it in such a container, shielding it from the postal service itself. That is the power of end-to-end encryption.

The postal service needs some information about the letter to process it, so you attach some metadata to it. Such metadata is usually the recipient’s name and address. This is the metadata you hear about in surveillance debates.

(End-to-end) encryption in practice

CC0 image by FOX

The following scenario is roughly the digital equivalent of the above.

You open your browser, visit You type in your mail, click send and your friend’s phone whistles, and she begins to read the email you just wrote. All this is happening in under a few minutes. So, was this communication end-to-end encrypted?

Well, it depends on where you place the two ends. If we sneak around a bit , we immediately see that Google makes an extraordinary effort to encrypt your content for you.

Your browser connected to via a secure channel. The content of your email was sent over this channel. Hence it was encrypted. Check.

Google uses TLS and ALTS to protect its traffic between services. Check.

It also uses TLS to deliver your email to its final destination. Check.

Your friend connects to her mail server via a secure connection. Check.

It appears as everything is indeed encrypted. The devil is in the details. Think about the following: was there any point in time when anyone else besides your friend could have peaked into your email?

Well, yes of course, multiple occasions. Whenever Google processes your message, it has cleartext access to it. Yes, the message is encrypted whenever it is in transit, but once it arrives at a midway destination, it is decrypted and re-encrypted for storage or further transportation with another key. True end-to-end encryption protects your message from everyone, even the service provider, Google in this case.

Therefore, your message is not end-to-end encrypted between your friend and you. It is end-to-end encrypted between you and Google’s edge servers. It is end-to-end encrypted between Google’s edge servers, and its Gmail infrastructure. It also travels encrypted between mail servers.

To sum this all up, end-to-end encryption primarily depends on where the two ends are. Lots of times we only think there are two ends very far apart (you and your friend). In reality, there are multiple ends closer together.

This brings us to the next topic.

Encrypting data in its various states

The above scenarios focus on data encryption in transit. There are, however, three states of data and each requires different handling. They are in transit, processing, and at rest.

Encrypting data in transit refers to encryption used during data transfer. TLS is the best example of this kind of encryption.

Encrypting data during processing is a lot trickier question. There are some technologies where it is possible to process data without knowing what it is. This is called homomorphic encryption, and it is a very active research area. As of this writing, you have to look hard to find real-world applications.

Encrypting data at rest is used during data storage. Samples include disk encryption and encrypted filesystems.

True end-to-end requires encryption at every state. This is no easy task. That is why so few products offer true E2E encryption.

True end-to-end encryption solutions

Those that offer it set it as their primary business goal. It takes enormous effort to provide such services. Moreover, it also means the service provider is not capable of reading your content. Take the following two real end-to-end encryption services.

CC0 image by Paula

Signal is open-source and aims at genuinely private conversations. They took extreme care in using encryption and deployed it well. There is no point in time when Signal could access the contents of your communication.

Tresorit is an end-to-end encrypted file storage and sync. Think of Dropbox, but truly encrypted end-to-end. Tresorit protects customer data in a way that makes it impossible for them or anyone else without the keys to read any of it.

In short, it is possible but not at all mainstream. This begs the question.

Is end-to-end encryption worth it?

There is profit in privacy and its growing fast. End-to-end encryption offers excellent values and, from a business perspective, costs a fortune. A better question is, does end-to-end encryption makes sense for your use-case?

Let’s say you need to process a high amount of personal information asynchronously. You decide to use a cloud provider for queueing. The queue, based on some metadata routes the messages it receives. For high availability, it is configured to be persistent, and there are also backups of the queue items every 5 minutes to make sure recovery is fast and easy. It is important to note that for the queue to function it does not need access to the message’s contents.

With this setup, the cloud provider processes, stores and even transfers personal data on your behalf. By applying end-to-end encryption to the contents of the queue messages, you suddenly make this data entirely opaque to the provider, essentially shielding it. This move will likely save you much hassle with data protection regulations and company compliance. In this case, both ends of the encryption are in your application.

Another excellent example of end-to-end encryption applied is Facebook’s secure email communication feature. Facebook allows you to upload your public key to your profile and it will use that key to encrypt messages it sends to you. Even though the email passes through some relying parties, they only see an encrypted blob. This completely secures the messages between Facebook and you, the two ends.

In conclusion, by strategically placing the ends of encryption, this tool can be one of your best allies. Do not forget though, this is just another trade-off. Its cost may be so high or the benefits so small, that it does not make sense to deploy it. Understand how it works, add this pattern to your repertoire and see where you can apply it to benefit.

This post originally appeared on the Craftlab blog.

comments powered by Disqus