​Why is End-to-End Encryption Important?

We often take it for granted that good encryption is mathematically strong encryption. On a really basic level, this is true. Compare a ROT13 piece of text to the Vigenère ciphertext for an example that can be worked out on paper. In industry, the shift from using DES to Triple-DES years ago is another simple, if outdated, example. However, a cipher being hard to crack is actually not the most important operational aspect of encryption. In live deployments, the operational security of a cipher is critical. To make this clear, imagine three online messaging services.

PlainTxt Inc operates just like normal SMS: you type a message, and that whole, unaltered message gets sent naked along the wire; it might be hard to intercept that message, because connecting to those wires in between is not necessarily simple, but if you have access to the wire, you have access to everyone's messages. This is obviously insecure.

CentralCrypt Co uses state of the art ciphers to encrypt messages, even maybe guaranteeing that they're quantum-computer proof--solidly encrypted so that even a highly advanced computer capable of computations unlike our current machines could not break the cipher. To do this, they use a centralized cipher where their servers hold the main keys, and each client uses a key the server grants. This is a useful scheme in some ways, because it allows users to back up message histories independent of their devices, because the keys to those messages are kept by the service. If a user loses a tablet or forgets a password, their messages can be recovered somehow.

AnarCrypt operates differently, and is admittedly a little harder to use, because the server cannot read messages; users connect to the service and it helps clients establish a connection to each other, even when they're offline, but messages on the server are identified only by a destination crypto key, and the contents of each message can only be decrypted by the intended recipient. This is a little inconvenient, because if a user loses their phone which has all their keys on it, they lose those messages. (It is possible to have backed them up somewhere using some other encryption, but this is secondary to our example.) So, when you send a message on this service, only you and the person you send it to can read it, and the service only sees gibberish. This is what is meant by end-to-end encryption (the message is encrypted from the sender's end through to the recipient, with no decrypted or compromised form in between).

It's probably obvious to anyone who uses a VPN that PlainTxt Inc is not a desirable messaging service. However, most people rely on Text Messaging, which is incredibly insecure, instead of a proper messaging service like Discord, Telegram, or Signal. Unfortunately, convenience tends to overrule security for most people. Apart from text being ubiquitously available, people rarely stop to ask themselves about its security. However, services that use a model like CentralCrypt Co are the norm here. And, like with text messaging, most people don't bother asking themselves what the issue is with the service holding a backdoor decryption method for your messages.

This is for many reasons, but the number one is, perhaps shamefully, convenience: as noted, CentralCrypt Co can backup your messages automatically, and smoothly move them from one device to another. You just log in and your messages are there, and most people cannot read them--besides, in most cases you probably don't have to worry about CentralCrypt Co reading your messages, as it isn't especially helpful for their business model. However, with this centralized model, the problem isn't the company itself (though it can be; we'll get to that), but third parties and that operational security.

Centralized encryption schemes are not necessarily mathematically weak; indeed, they're usually exactly the same as a decentralized cipher. However, because CentralCrypt Co holds the keys to your messages (indeed, to everyone's messages--even if they use multiple keys across different users, those keys are still in one place), those keys are a sitting target. It's unlikely, however, that someone is going to break CentralCrypt Co's encryption; but what is much more likely is the way that almost all encryption is compromised: human fallibility. It is a sadly frequent occurrence that a careless developer leaves a database publicly accessible with either default or easily guessable credentials. On top of this there are numerous phishing schemes that are quite successful, especially with larger companies, that involve simple cons like calling someone pretending to be technical support of some kind. There are additional attack surfaces in employee users who may have poorly formed passwords--for instance using the same or similar passwords on different services including internal work services, meaning that if one password is breached for an unrelated service (the employee's Netflix password for instance, maybe even innocently shared with a roommate), then critical work services are readily compromised. That user may not have direct access to important data, but having access to their internal resources could make it easier for an attacker to gain access to important data.

There are so many possibilities for how a company's encryption could be *illegally* breached when all their encryption eggs are in one basket, but there is another important exception here too. Law enforcement branches of government can readily request and gain access to data that is otherwise encrypted by a company. It is possibly questionably legal, and indeed I would personally consider it immoral (and that it should be illegal), but the unfortunate current reality is that most companies will just cave immediately to law enforcement requests for data, even without seriously considering the reasons for the request. This leaves a gaping hole in any centralized encryption scheme. There is much to be said on the topic of abuse of investigative power, and it is indeed a hairy topic, but even if we assume a complete integrity in how this power is used by legitimate authorities there is still a breach. The organizations that operate law enforcement must still themselves depend on similar systems to those that these messaging companies use--all the way down to how they store data. And, like the messaging companies, these organizations will have operational gaps in security that an attacker could compromise and use to exploit data requests from companies. Or, to put it more concretely, an attacker could possibly compromise systems in, say, local police in Seattle and use electronic systems to send what might look like a legitimate legal request for encrypted data from Amazon (headquartered in Seattle); because Amazon hosts many services supplied to companies for their own systems, this could possible enable compromising multiple systems. However, this does rely on all of these services using a centralized encryption scheme, where keys are produced top-down.

While, sadly, this is the commonly accepted method of arranging encryption deployments, it is not the only way. AnarCrypt doesn't have some of those bells and whistles, but it does offer maximum user security. By keeping the keys with users, messages are as secure as the users, and cannot be compromised centrally. So, an attacker wishing to read messages between many users would have to attack each user separately rather than just compromising central keys. It's not that the attacks discussed above couldn't be used effectively on each user, but since many users can't be compromised simultaneously, it's much harder for an attacker to gather mass data. Additionally, since it would take so much time for the attacker to crunch through each user, it's possible that the attacker (or at least the attack) would be identified and measures could be taken to address the attack. For instance, if the attacker has a list of users and is going down it alphabetically, perhaps the first ten users fell to phishing attacks, but before the next could, a user reported the phishing and the company could notify users of the phishing, perhaps nullify the attack method by changing some detail of operations, or even just have each user rekey their messages.

This distributed key model does place a burden upon users of having their keys properly accessible, and makes a process like adding a second device to an account slightly more onerous. It is possible to automate some of these tasks, however, for instance by informing an old device of a new device so that old messages can sync device to device, without passing through a central location or central encryption. So, this way of performing encryption is viable in a more convenient way, but it does require some tricks and is harder to deploy. However, these drawbacks are part of the operational security of end-to-end encryption, and for the future of security they are necessary sacrifices of convenience.