What is end-to-end encryption and why does it matter?

Encryption protects your data. But there are many kinds of encryption, which can be very confusing. What are public and private keys? SSL, TLS, HTTPS? Where do client-side, server-side and end-to-end encryption fit in? A recent report from Forrester named data encryption as one of the top global Cybersecurity trends for 2017, so this is a big deal! We will try to explain some of the most important terms here, especially with regards to end-to-end encryption and why it matters.

The basics of encryption

The basic goal of encryption is to turn a piece of readable information (text, files, images…) into an unreadable format in such a way that the transformation can be reversed using a ‘key’. People without the key should not be able to turn the garbled format back to its original form.

Say you want to sent a letter to somebody else. You could turn the letters of the alphabet into random numbers. So a is 138, B is 080, c is 013, D is 165 and so on. To ‘encrypt’ a text, you agree with the recipient on a ‘key’ (relation between letters and numbers), use it on your side turn to the text into a string of numbers by replacing all letters, and go to the post office to sent the ‘encrypted’ format. The recipient gets the letter and uses the key to get back the original text.

This can be ‘cracked’ relatively easy so computers use far more complicated schemes than this, but the principle is similar.

What is End-to-End Encryption?

End-to-end Encryption is usually associated with communication channels, think chat or video calls. Signal, Telegram and lately WhatsApp employ end-to-end encryption. So what does it mean?

The main property of end-to-end encryption is that the data is encrypted on the one end and decrypted on the other end, so only the sender and receiver can read it. In our letters-to-numbers example, we used essentially end-to-end encryption. Imagine not doing the transformation of numbers to letters yourself but letting the post office employee do it before sending the data: this wouldn’t be ‘end-to-end’ anymore, the post office can read the message. But anyone between the two offices can’t read it.

As an example, take the Nextcloud Video Calls app. When you share a link for a call and the other person joins, the Nextcloud Server essentially gives the other user the address of your computer and helps you connect to each other. It will also send signals when others join the call, when you mute and so on. But the actual call takes place between your system and that of your conversational partner, directly. And before your voice and video are sent out, your browser will encrypt the data for the other side to decrypt. This way, nobody in between, like your internet provider or even the Nextcloud server itself, can listen in!

The main downside of the term is that the definition of that ‘end’ can vary: you can say that normal https encryption is ‘end-to-end’, defining one end as the browser and the other end as the server. Think again of the post office: you could encrypt the letter for the post office to decrypt, which then encrypts again for the other post office. While the data is encrypted between you and the post office and between post offices, it isn’t end-to-end! This brings us to the difference between server-side and client-side encryption.

Server-side encryption

Server-side encryption serves to protect data on or going through a server: as soon as the data arrives, the server encrypts it. Typically, the data was also encrypted ‘on the way’ to the server, using https. In the post office example, you’d perhaps have a storage depot on the way between two post offices. If the data was encrypted in the office, it will be secure from anyone in that storage depot trying to read your letter.

This can be very useful: when you use a cloud storage like Amazon S3 or a Dropbox account or a FTP server at another office with Nextcloud, our Server-side Encryption encrypts the data before it gets sent to the storage and decrypts it only after it has been retrieved. Server-side encryption thus protects your data from access by a third party storage solution.

Note that encryption in the browser is essentially server-side encryption: the code that does the work comes from the server and thus the server controls what is going on. In the post office example, it would be like this if you used keys provided by the post office. While you encrypt yourself, the post office has access because they have the key. If a server is compromised and you use browser side encryption, the attacker (or evil system administrator, government agency, or…) can simply make a minor modification to that code so it gives them access to your encryption key!

So the limitation of server-side encryption lies in what it does not protect you from: the server (post office) being compromised.

Client-side encryption

This is why server-side encryption is often contrasted with client-side encryption, which is what is employed by the end-to-end encryption Nextcloud introduced today. Where server-side encryption happens after transmission to the server, we encrypt the data on the Android, iOS or desktop client already, just like you could encrypt a letter at home before going to the post office. Then, only at the receiving end, it is decrypted again. That receiving end can be another device owned by the same user or a device owned by another user who has been given access to the data. But not anyone in between or otherwise not authorized! This is sometimes also called a zero-knowledge privacy: at no point in time can the server have any knowledge of the data.

The process of creating keys

A little bit about keys

Usually, public and private keys are used for the encryption and decryption. How does that work?

Everybody has a set of closely related keys, a ‘public’ and a ‘private’ key. They work a bit like a mail box in front of your house or in your front door works: anyone can throw a letter in the box, but only the owner can open and empty it. The public key is, as the name implies, public. Anyone can use it to encrypt something. But to decrypt the result, the private key is needed!

Nextcloud generates a public and private key pair the first time a user enables end-to-end encryption in their client. The server creates a ‘certificate’ to verify the user identity (our Cryptographic Identity Protection feature) and stores it there. This allows other users to encrypt files that they wish to share with you. The private key gets encrypted with a locally, app-generated very secure and very long (12 word!) passcode which is displayed to the user and then the encrypted key gets stored on the server as well.

Another device owned by the user can download the private key, the user can enter the 12 word passcode to decrypt it, and this device will then also be able to encrypt and decrypt files. That is how you add your phone and desktop after you enabled end-to-end encryption on your laptop.

You can learn much more about exactly how the encryption and decryption work on the end-to-end encryption web page we made as well as the whitepaper you can download there.

Enterprise challenges

While consumers use end-to-end encryption for chat for years, larger organizations like companies and governments have struggled to find solutions that protect their sensitive data without disrupting productivity and legal requirements for, for example, audit logs or control by system administrators.

Indeed, many solutions create a new layer over existing solutions like Box and Dropbox or have poor key management, making sharing cumbersome and less secure. A real enterprise solution needs to take the burden of complexity away from users and, if it needs to be anywhere, put it on the shoulders of the system administrators. Nextcloud has done exactly that, not even allowing users to create their own, potentially insecure password and making adding devices easy. The 12-word passcode can be recovered from any of the devices an user owns and it is possible to enable a system wide recovery key. If enabled, users will get warned of this and the system administrator gets to see and note down the key once and only once. After that, the code is destroyed and no attacker would be able to steal it, provided the server administrator puts it in a safe location: we’d recommend an actual safe.

Another important feature for enterprises is support for a Hardware Security Module which could be used to generate user certificates. Without it, our design does not allow users to switch identities (as this could be abused by an attacker with control over the server) but this restriction can be relaxed if a secure HSM is in the mix.

We wrote about the needs of enterprise users earlier.

You can learn more on our webpage about end-to-end encryption!