Encryption

This article is adapted from an older one published 15 June, 2022 on the Portsmouth Point blog, titled End-To-End Encryption. It’s more new than old, with lots of the technical details fixed or updated (thanks a lot to John Ozbay for taking the time to explain them to me), and some of the conclusions and opinions changed to reflect my current views.

Nowadays, when data is sent over the internet or stored on a server, it’s almost always encrypted beforehand. This scrambles the data into seemingly random combinations of characters, using an encryption key. Using this same encryption key¹ however, the data can be unscrambled back into its original form. This means that private information is kept private; nobody who gains access to and reads the encrypted information is able to make sense of it. With the number of possibilities that the standard 256 bit encryption entails, using brute force to unscramble this data (that is, to try out every combination of decryption keys to find the right one) using current computers would take roughly 200000000000000000000000x as long as the universe has existed. Quantum computers might one day pose a threat to some of our current encryption algorithms², although there are already approaches to defend against this, but for the time being, encryption simply cannot be broken.

Most of the time, data is first encrypted during transit (eg using TLS) between your device and an app’s servers, using a temporary, randomly generated encryption key to do so. It’s then typically encrypted by and stored on these servers, which is referred to as server-side encryption. This means that said servers are able to decrypt and read this data, which for a lot of use cases makes sense. You’d expect your banking website to be able to read your requested transactions and update their records, for example. But sometimes, the data you're sending is not intended for the service you’re using, but just for yourself - such as note taking, or for another person that you're communicating with - such as messaging. Using server-side encryption, this data can be read by whatever service you’re using. They can choose to do whatever they like with your information: sell it to advertisers, use it to build up a profile of you, and perhaps use it to target other products and services at you. But even if you trust this service not to misuse your private information, you can’t trust that others won’t. If a 3rd party is able to get into their systems somehow (through illegal or legal means) and access the stored encryption keys alongside your data, then they’ll be able to decrypt and read it. Data leaks like this are hardly uncommon, whether through state-sponsored/political attacks, criminals in search of money, human error, or simply people with too much free time on their hands.

The obvious solution to this is a system where encryption keys are not known by the service you’re using, but just by you. This means that it is physically, mathematically impossible that anyone else is able to access your data unless you choose to share it with them, or unless you or your own device are compromised. The technical term for this is zero-trust, as you don’t need to trust the service you’re using to safeguard your data given that they are unable to access it. Unfortunately this term is rarely used outside of the industry. I assume that when launching the first mainstream zero-trust services somebody from the marketing team went ‘look, I’m really sorry but we just can’t call our secure messaging app “zero-trust”, that’s going to put everyone right off’, and instead they co-opted the term end-to-end encryption³, as well as the more sensible but less common client-side encryption.

Let’s start with client-side encryption. Client-side encryption means that data is encrypted by the client (your device), using a key which is not known to the server. A great example of this is the note-taking and photo-storage app Cryptee⁴. When creating an account, you also create an encryption key, which is used to encrypt your data. This encrypted data is then sent to and stored on their servers⁵. Cryptee never has access to the encryption key and cannot read your data. Likewise, the modern definition of end-to-end encryption is a closely related concept, as data is similarly encrypted on-device and inaccessible to the server. The difference is that it’s used for communication services. End-to-end encryption nowadays means that only you and other participant(s) have the decryption key to be able to read your messages or listen in on your calls. A well-known example of this is Signal, who’s open-source protocol is now used by many other services as well⁶.

On the surface of it, zero-trust encryption is great! Nobody except you and other users you communicate with can access your data. Even if the service you’re using experiences a data leak, third parties will only be able to view encrypted meaningless data. However, these systems do come with some drawbacks. From a technical perspective, it is a bit harder to implement. As well as needing your login details/phone number to sign in, you also need your encryption key to access your data. Encryption keys are typically 256 bits long. There are methods to securely derive this key from a password-length key that the user remembers^{5, 6}, but this still effectively means that two passwords need to be remembered or saved. Passwords, and more generally human error, are famously one of the weakest links in security - the average person at any one time has 0.8 correct passwords in their memory. Solutions to this can involve password managers, which I’d strongly recommend everyone use⁷, or passkeys, which are in principle a great idea but currently a bit of a mess. However, many zero-trust services instead assume that users do not want to manage their encryption key, and indeed do not let them do so. Signal and WhatsApp for example store your encryption key on-device, and if you wish to use them on another device you need to first link that device to your “primary device”, such as by scanning a QR code. This does manage to hide the complexity of zero-trust encryption but it also significantly reduces the flexibility of them. Should you wish to access your data/account but not have access to the primary device it can be near-impossible to do so⁸.

Still, while more complicated, zero-trust encryption can be used in place of traditional server-side encryption, and already is in many places. The other side of the equation is the ethical side of things. As with many tools, this kind of privacy can be used for good, or for bad. It can be used for example for organising protest and resistance under authoritarian regimes, or it can be used for planning and carrying out crimes. It can be used to protect those who are in danger due to their sexuality, religious beliefs, or political views, or it can be used for child sexual abuse material. And so on and so forth. The problem is that it’s not possible to separate out these use cases. Many governments and organisations have proposed doing so, introducing so called backdoors to allow them access to people’s data, but nobody else. But any kind of backdoor - any kind of security hole - is a security hole that will eventually be exploited by others. And even if you trust your government to always do the “right thing”⁹, there’s many which surely cannot be trusted. Even the UN states that privacy is a human right. This is not to say that you can’t report things to law enforcement and provide evidence to them or to others if you so wish. You still have access to your data of course, so if you want to share it as part of this process you can. “Report” buttons can still work under these systems, sending the data which you have access to to the relevant agencies. But this should be something which you have control over, rather than something which has the potential to be exploited and accessed by anyone with the technical means to do so.