A Cryptographer's Guide to End-to-End Encryption

End-to-end encryption, the tech to make sure only you can access your data, is getting traction recently. Even if you're not familiar with privacy-friendly services like Signal, you're still using end-to-end encryption while you're sending messages in WhatsApp, iCloud or Messenger, which means billions of people are using it worldwide.

The adoption of end-to-end encryption is also growing in business tools: companies now have the option to switch to that when using Zoom or Microsoft Teams, besides choosing services that come with built-in end-to-encryption. But what is exactly end-to-end encryption, how does it protect your data and why is it superior to all other types of encryption out there?

Read below for an overview of the different types of encryption, and some fun facts you may or may not already know.

What is the definition of end-to-end encryption?

The US federal standard of end-to-end encryption is as follows:
“The encryption of information at its origin and decryption at its intended destination without any intermediate decryption”

Why is this definition problematic?

The above definition has now become problematic because it is:

Outdated
Open to interpretation
Given the various personal interpretations of encryption floating around the market, we always stick with ‘end-to-end encryption’ as our universal go-to definition for what Tresorit delivers to its customers.

Not all encryption is created equal. What are the different types of encryption available?

To answer this question, we’re going to get a little creative.

At-rest encryption
Imagine that you are checking into a hotel. You’re on a business trip to deliver important documents to a client. You want to find a safe place in your room to put your documents before meeting your client for a meal. Where should you leave them?

Leaving the documents in your room is an option, but that puts a lot of weight on your trust in the hotel’s staff. It also leaves the documents vulnerable to a breach in the hotel’s own security – like a thief who makes off with a master key, or a hotel cleaner gone rogue.

The set-up we’ve described is called at-rest encryption. It is intended to prevent access to the physical infrastructure (in this case, your hotel room). With this set-up, your documents are encrypted, but the keys to unlock them are stored in the same environment, so…. easy work to decrypt should they fall into the wrong hands.
Session encryption
Session encryption provides a higher level of protection than at-rest encryption - the files are encrypted by the server, and the encryption key is stored in an encrypted format on this server for a short time.

In the unfortunate event a system using session encryption is breached, only the users online during this period are compromised (the equivalent of only having your documents stolen from your person if you happen to be in the hotel at the time of theft). So… mixed reviews from us on this one.

(Fun fact: Zoom actually sold this type of session encryption - which allowed their server to access and decrypt content - as end-to-end encryption to their customers. Lesson learnt the hard way.
In-transit encryption

One way of reducing the risk of your precious documents being stolen in transit is to find a secure channel to deliver them to your client from the hotel, like a taxi or (if you’re not looking to travel discretely) a convoy of armoured vehicles. This approach is called in-transit encryption, and functions well up until a point your vehicle gets apprehended or a weak link in your convoy is exposed.
Client-side encryption
To keep our hotel metaphor just a little bit longer, an example of client-side encryption would be a hotel room safe housed within your hotel room. Safes allow us to safeguard important documents with a code that is only accessible to the owner and the people he or she shares the code details with.

Sounds like client-side encryption is where I want to be, how do I get started?

Not so fast. There are a couple of issues with client-side encryption. First up, if you’re using a mainstream cloud solution, you have to encrypt your files before uploading them which, much like bringing a safe to your hotel room you’re staying in, is pretty inconvenient.
Another problem is the terminology of client-side encryption – which is mostly used for storage systems, not transactions. This means that the safe combination may not match up with the information that the client is able to access, creating a whole new set of problems in the process.

What’s the solution then?

We believe that end-to-end encryption is encryption in its purest form – and, semantically speaking, the easiest way to articulate what we provide our customers as an ultra-secure service.

What are the defining characteristics of E2EE?

We believe that a system can be called ‘end to end encrypted’ if it fulfills the following 6 criteria as much as practically possible (Tresorit disclaimer: it’s pretty much impossible to apply all of these criteria at once in a business setting, but all 6 can and should be taken into account).

Architecture criteria. The encryption happens between two (or more) parties, whereby the intended origin encrypts the message, and the intended destination(s) decrypt the message without being disturbed. In this case, a ‘party’ could be an organization (not just a private individual) and applies to any system which is under full control of the organization? Make sense? Great, let’s move on…
Key exchange criteria. If the key exchanges for your encryption are done in a way that only allows the parties (that we described above) access, then you’ve got yourself some end-to-end encryption!
Key generation & management criteria. Same approach, but applied to the management and generation of keys this time around. If a third party (even a trusted one) has access to these even temporarily, then your system is not end-to-end encrypted!
Key back-up criteria. The parties private keys need to be backed up in a format that no one else has access to. Pretty straightforward.
Binary authenticity criteria. The parties need to ensure that the software they are using is infection free, backdoor free and purchased from the original trusted vendor.
End-point authentication criteria. Both parties need to be 100% certain that the public keys belong to their respective counterparts.

How can we execute E2EE?

One of the most popular ways to execute E2EE involves an application server in the middle. This is a set up popularized by both messaging apps such as WhatsApp and VoIP systems.

Pro tip: from the provider side, it’s crucial to ensure that there is no available access to the application server when building this type of system. Failure to secure your central routing element = bad news.

How does E2EE work for businesses?

Making E2EE work within a business environment depends on being able to control or ‘trust’ the server being used to transfer information. And… the good news is that this doesn’t necessarily mean investing in your own cloud infrastructure – 3rd party cloud storage options can be brought into play provided that the gateways to this storage are controlled by the company doing the encryption/key exchange.

One Last Thing…

We realize that not every aspect of cryptography (and what makes E2EE secure) can be distilled or described simply, and that even end-to-end encryption is still subject to very high-level definition. Nevertheless, we believe it’s important for everyone who handles confidential information (as an individual, or as part of a business) to have an overview on how to share securely.

We believe that E2EE is the best possible way to achieve this – whether you’re a legal firm or a non-profit – and we hope that this insight into our world inspires you to dig a little deeper yourself.