Concept:End-to-end encryption

End-to-end encryption (E2EE) is a method of private communication in a way where only the sender and the intended recipient can read and decipher the communication back and forth. Importantly, the content of the communication is inaccessible to any third party, including network providers and service providers facilitating the connection or service.

Criticism of 'going dark' and its refute

With the increasing of crimes, law enforcement agencies often criticize and shirk responsibility to the end-to-end encryption conversations and softwares. The claim that E2EE has made it impossible to use legal tools such as warrants to monitor the communications of a person suspected of a crime. They call this 'going dark'.

However, no there are credible studies have been able to find any correlation or causation between the rise of end-to-end encryption and crime. In fact, violent crime has famously been in decline in the US since 1991. On the other hand, end-to-end encryption has only risen since then.

An exceptionally short primer on encryption

w:Cryptography and w:encryption are vast and complex fields, far outside of scope of this wiki, however, we will aim to introduce you with the most basic terms.

Symmetric encryption

See also: w:one-time pad

Symmetric encryption is when two parties agree on a shared method (shared secret) which allows them to modify the information they wish to protect (plaintext) in a way that the recipient will be able to undo, but another third party who does not posses the shared secret will not.

For example, imagine a situation where Alice wants to secretly tell Bob what her net worth is. Prior to this however, they had agreed to add the number 3419817552058 to whatever the actual net worth is. So Alice takes her actual net worth, $22 000, and adds the shared secret, arriving at $3419817574058 (this is called ciphertext). Receiving the ciphertext, Bob takes away the agreed upon number, and arrives at the plaintext (Alice's actual net worth). A third party, Charlie, has seen and recorded the ciphertext, but without knowing how much to take away, he cannot be sure what the net worth is.

This is of course a very simplistic method, but it does illustrate the core point: assuming that the shared secret is truly random and truly secret, and no operational slip-ups have happened (like Bob writing down the shared secret and Charlie finding it), the encryption is unbreakable as Charlie has no way of guessing what the shared secret is. It could be any number between 1 and infinity.

Asymmetric encryption

What if we are unable to establish a shared secret? What if we are physically distant or have never met? This is where asymmetric (aka public key) encryption steps in.

Asymmetric encryption relies upon the fact that certain mathematical processes are easy to do one way, but hard to do in reverse. Imagine if somebody asked you which two w:prime numbers multiply to 143. Finding the answer to that is very hard, and there is no better way than just trying by multiplying numbers that may be suitable, either in order or ones that multiply to approximately required number, until you happened to stumble into the solution. Now imagine if the number you were given is not 143, but a number that is very large, and may have a thousand digits. It is an impossible task.

But, if somebody asked you to multiply 11 and 13, doing so is trivial even for school children. And if somebody gave you two very large numbers to multiply, it will still be very easy. Thus we have a function which is easy to do in one way, but very hard to reverse.

Using such w:one-way functions it is possible to generate a pair of keys (numbers) which do not at a glance share anything in common, but are able to reverse each other's encryption. This allows you to publish one of them publicly (the "public key") and keep the other one secret (the "private" or "secret key"). Now anyone can use the public key to encrypt a message and send it to you, safe in the knowledge that only you can read it (because only you have the private key).

Key exchange

We can combine the characteristics of symmetric and asymmetric encryption to arrive at a system which possesses the benefits of both. Let's go back to Alice and Bob.

Imagine Alice selects a random number, let's say 33. The Alice encrypts it with Bob's public key and sends the ciphertext to Bob. Likewise, Bob also selects random a number (17 for this example), encrypts it with Alice's public key, and sends it to Alice.

Alice knows which number she sent (33) and has decrypted the message Bob sent and found 17 in it. Alice knows that the communication system requires them to add the two numbers, so she adds 33 and 17 and arrives at the shared secret which is 50. Bob, knowing his own number 17 and receiving 33 from Alice, adds them both up and also arrives at 50.

Both Alice and Bob now know the shared secret, and anyone observing them cannot reliably guess the shared secret number. Now Alice and Bob can switch back to symmetric encryption using the shared secret, as described in the symmetric encryption section.

Things that may hinder end-to-end encryption

The key fact that the above description is meant to illustrate is that encryption, including end-to-end encryption, is just math, the same indisputable, immutable math that tells us that 2 + 2 is 4 or 5 < 10. There's nothing magic about it, it is just an agreed upon system that two parties can use to transform their conversation into something nobody but them can understand.

Another important point is that like all math, anyone who knows and understands the principles can use the methods to their own ends. Just like you cannot prevent your enemy from using math against you, you cannot prevent your adversary using the above methodology to communicate securely. It is a nonsensical idea that anyone could ban or outlaw math, just as one cannot outlaw colour purple out of existence. However, this is exactly what many law-enforcement agencies and lawmakers are proposing all over the world. The idea of a "law-enforcement backdoor" or a "backdoor for the good guys" has been a hot topic in many lawmaking circles these days, but we believe that this is an impossible demand.

Backdoor?

You can modify the encryption method to allow a third party to peek into the contents of the messages, but you cannot modify it in such a way to make sure that only a specific third party has access to it, and nobody else. You can create a backdoor, but you cannot create a law-enforcement specific backdoor. A weakness, once introduced, can be exploited by anyone who knows it. Yes, you can classify the existence of the backdoor/weakness, but the question is how long can you keep that a secret from internal leakers, independent researches who may independently discover it, or an adversary that may be able to throw money at the problem. Of course, once the cat is out of the bag, all the ordinary people who trusted your crippled encryption scheme have now had their private data breached.

A common example include ProtonMail, since the encryption and decryption are done by JavaScript in the browser, ProtonMail can easily access your messages via backdoored JavaScript.

Define 'legitimate law enforcement use'

Defining 'legitimate law enforcement use' is one of those issues that start off very easy but become murky very quickly.

On the extremely clear side we have uses which no reasonable person would opposed to, such as protecting children from predators or protecting victims we know to be in imminent danger of violence. But, as usual, the road to hell is paved with good intentions. Should we use it to spy on organised crime? Probably. Known perpetrators of domestic violence? If we have probable cause, yeah, sure. But what if we don't?

Should we use it against our country's enemies, foreign and domestic? Probably. But how do we define an enemy? Is does the definition of the enemy include an opposing party I disagree with which seeks to take our country in a fundamentally different direction we disagree with? Do we spy on our allies, even if we don't suspect them of dishonesty, just to be sure? Do we spy on violent protesters looting and burning public property? Do we spy on peaceful protesters? How do we separate the two as they're often intermingled? Do we spy on a political opponent we suspect of breaking a law? Where does this end?

The grim reality is that it does not. These tools, once available, trickle down to lower and lower levels of law enforcement until they're used to prosecute trivial offences and fines.

Setting the precedent

Let's say that regardless of the copious reasons why this is a bad idea, we still decide that the trade-offs are worth it and we pressure phone and app makers to introduce a backdoor into their products. Soon, other countries will want this level of access too. If you're an anglophonic person, you may be okay with the notion of Western nations having access to those tools but once again the question is where we draw the line. Should we give access to this backdoor to Turkey, who has historically been a reliable Western ally but has recently taken interest in oppressing the very Kurds that Unites States supported in the fight against w:Islamic State of Iraq and the Levant? Do we give it to China to spy on Uyghur Muslims and place them in w:Xinjiang detention camps? Parties like China already heavily control and often outright ban Western companies' operations in China, refusal to share this access would be the end of their China operations.

How confident are we that your average tech CEO focused on the next quarterly report would have the moral fortitude to stand up to China?

Conclusion

Even if we are willing to accept all the above-mentioned compromises regarding our privacy, it would still be all for naught. The cat is out of the bag and the horse has well and truly bolted. Criminals would still be able to use readily available end-to-end encrypted apps headquartered outside of our legal jurisdictions, or would even roll their own secure communication networks. All the while, your average citizen would be at a mercy of a panopticon government where their every move is recorded and kept on permanent record for when the political winds change and some abusive institution can arrest them for a thought crime.

Nothing gained, everything lost.

Evaluating encryption protocols and services

It is very common to encounter apps and services that claims to be encrypted/secure/private or some other combination of security or privacy buzzwords. Here's a checklist of things to consider when evaluating such claim.

• Free and open source - is the product's source code available for inspection and scrutiny by independent experts.
  • Don't forget about the server. If the product uses w:client-server architecture, server software should ideally also be open source and readily available. Although well designed E2EE encryption can to some degree resist a hostile server, there are still many things that a hostile or compromised server could to do affect the service.
    • This is why we recommend against Telegram as it all the messages are saved in a centralized server.
  • Look for w:reproducible builds. It is one thing to have a source code published online, and quite another to be sure that the binary running on your device is product of the published source code. Reproducible builds are binary software builds which, given same source code always result in the same binary output.