What is End-to-End Encryption (E2EE)?
End-to-End Encryption (E2EE) is a communication system designed to ensure that messages are readable only by the communicating parties. The fundamental principle is that the key used for encryption and decryption is known only to the endpoints, i.e., the users’ devices.
This is different from non-E2EE systems, such as traditional email or certain messaging systems without E2EE enabled. In a non-E2EE client-server model, a message from Bob to Alice goes through an intermediary server. Bob encrypts the message with a key he shares with the server, the server decrypts the message (meaning the server can read it), and then re-encrypts it with a key it shares with Alice before sending it to her.
With E2EE, the server still acts as an intermediary for transporting messages, but it does not possess the key needed to decrypt the messages. The server receives only the encrypted text, which appears as random noise.
The main advantages of E2EE are:
- Privacy: Only the intended recipients can read the messages.
- Security against Interception: Anyone intercepting the traffic between endpoints (e.g., on a router) will only see unreadable encrypted data without the key.
- Security against Server Compromise: Even if the server handling message transport is breached or a government requests the data, the company operating the server can credibly claim they cannot provide the content of messages because they do not hold the decryption key. Sources indicate that compromising a non-E2EE server could expose all unencrypted messages, which E2EE prevents. This allows companies like Facebook, Apple, or Google to state that they cannot hand over user data to authorities like MI5, Russian secret police, or Chinese security police, because they only have the ciphertext, and only the endpoints have the key.
How E2EE Works (Key Exchange)
A core challenge in implementing E2EE is how two communicating parties (like Alice and Bob), who might never have met, can establish a shared secret (a symmetric encryption key) over a potentially insecure channel.
The standard solution is the Diffie-Hellman (DH) key exchange algorithm. Published in 1976, DH allows two parties to jointly create the same secret key by exchanging only public information.
Imagine that Alice and Bob want to communicate secretly, but they’ve never met and are talking over a channel that anyone can listen to — like shouting across a crowded square. Still, they have a clever math trick that lets them create a shared secret together without ever actually sending the secret itself.
1. They agree on two public numbers
Alice and Bob start by agreeing on two numbers that everyone is allowed to know:
- A very large prime number, called n
- A generator g, which is another number chosen with special mathematical properties.
Think of these two as shared ingredients — public and visible to anyone.
2. Each picks a private secret
- Alice picks a secret number, let’s call it a.
- Bob picks his own secret number, b.
They keep these secret — no one else is allowed to know them. These are their private keys.
3. They each compute a public value to send
Now they each use their private number together with the public ones to create something to send to the other:
- Alice computes g^a mod n and sends that to Bob.
- Bob computes g^b mod n and sends that to Alice.
These are like disguised messages — they look like gibberish, but carry hidden structure.
4. They each compute the same shared secret
Here’s the clever part.
Each of them takes what they received and raises it to their own private number:
- Alice takes Bob’s value (g^b mod n) and raises it to the power of a ? she gets g^(ab) mod n.
- Bob does the same with Alice’s value and his b ? he also gets g^(ab) mod n.
Even though they did different math, the result is exactly the same: they both end up with the same shared secret, without ever directly sending it.
5. Eavesdroppers can’t figure it out
Anyone listening can see g, n, g^a mod n, and g^b mod n.
But without knowing either a or b, they cannot figure out the shared secret g^(ab) mod n.
Why? Because to go backward from g^a mod n to a is called the discrete logarithm problem — and that’s incredibly hard to solve when the numbers are large enough. It would take so long that it’s effectively impossible with today’s computers.
In short: Alice and Bob build a secret key together, in public, and no one watching can figure it out.
Combination of Diffie-Hellman with Public Key Cryptography (RSA)
While Diffie-Hellman is effective for creating a shared secret, the basic algorithm is vulnerable to Man-in-the-Middle (MITM) attacks if used alone. An attacker (like “Sean” in the sources) can intercept the communications between Alice and Bob and establish separate shared secrets with each of them. The attacker intercepts Alice’s g^a, sends their own g^sto Bob, and intercepts Bob’s g^b, sending their own g^s to Alice. As a result, Alice and the attacker establish g^as, and Bob and the attacker establish g^sb. The attacker now knows both keys and can decrypt, read (and potentially modify), and re-encrypt all messages passing between Alice and Bob without either of them knowing. Basic Diffie-Hellman does not intrinsically authenticate the identities of the parties.
To counter this vulnerability, Diffie-Hellman is often combined with public key cryptography (also known as asymmetric cryptography), such as RSA. Public key cryptography uses a pair of mathematically linked keys, one public and one private. Data encrypted with one key can only be decrypted with the other. The public key can be freely distributed, while the private key must be kept secret.
In modern practice, especially in protocols like TLS (used for HTTPS), public key cryptography is used for authentication. For example, a server (Bob) uses its RSA private key to digitally sign the Diffie-Hellman parameters (g^b) it sends to Alice. Alice, who has Bob’s public RSA key (typically obtained through a digital certificate verified by a trusted Certificate Authority), can then verify the signature. This verification process confirms that the DH parameters came from the legitimate Bob, not an attacker, because only Bob possesses the private key necessary to create a valid signature that matches the public key. This combination prevents the MITM attack.
The keys established via DH exchange (sometimes called “ephemeral” keys because they are generated frequently, possibly for every message) are then used as symmetric keys for algorithms like AES or ChaCha20 to encrypt the actual message data. This is faster than using asymmetric encryption for the entire message.
Problems Related to Backdoors
In the context of E2EE, the term “backdoor” typically refers to a mechanism that allows a third party, often a government or law enforcement agency, to gain access to encrypted communications despite the E2EE design. This contradicts the core principle of E2EE, which is that only the endpoints can decrypt the messages.
Sources discuss several ideas or methods that could function as backdoors or compromise the security E2EE aims to provide:
- Key Escrow or Trusted Third Parties: This model requires users or services to provide a copy of the decryption key to a trusted third party, such as a government agency or a designated company. This was proposed in the past (e.g., the Clipper chip in the US, proposals for trusted third parties in Britain).
- Problem: This design fundamentally breaks E2EE by allowing a third party access to the keys. It creates a single, centralized point of failure. If the server holding these keys or the trusted third party is hacked, or if their security is otherwise compromised, all stored keys could be stolen, allowing attackers to decrypt vast amounts of communication data. This risk of catastrophic data breaches affects everyone, not just the specific individuals under surveillance.
- Weakening Cryptographic Standards: This involves influencing the design of cryptographic algorithms or standards to include deliberate weaknesses or flaws that are known only to the party inserting the backdoor.
- Dual EC DRBG Example: The Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC DRBG), a standard published by NIST, is strongly suspected of containing a backdoor. Cryptographers found that if there was a secret mathematical relationship (‘e’) between the public parameters (P and Q) of the algorithm, someone knowing ‘e’ could predict the future output of the random number generator after observing a small portion of its output. Since cryptographic operations (like generating DH private keys or nonces) rely on unpredictable random numbers, predicting these numbers would allow an attacker to compromise secure communications. The fact that the NSA provided the parameters without explaining how they were generated, coupled with later revelations about money changing hands between the NSA and companies implementing the standard, led the cryptographic community to a strong consensus that this was indeed a backdoor. If such a standard is widely adopted or mandated, it compromises the security of everyone using it, not just targeted individuals.
- Weak Key Generation or Predictable Randomness: Even without an explicitly designed backdoor in the algorithm itself, if the keys are generated using weak or predictable random number sources, it can create a vulnerability that functions similarly to a backdoor.
- Problem: If an attacker can predict or guess the ‘random’ private keys used in protocols like DH or RSA, they can compromise the communication. For example, using RSA keys where the prime factors (P and Q) are too close together makes factoring the public modulus (N=P*Q) easier using methods like Fermat’s factorization algorithm, thereby revealing the private key. While not always an intentional backdoor, weak randomness or key generation creates exploitable weaknesses. LFSRs on their own, while fast, are not cryptographically secure for generating key streams because their state can be predicted from observed output.
- Implementation Errors: Mistakes in the software or hardware implementation of a cryptographic algorithm can create side channels (like cache timing attacks or power consumption analysis) that leak bits of the secret key or internal state information.
- Problem: Even if the underlying algorithm is mathematically sound, a poor implementation can make it vulnerable to attacks that circumvent the intended security. Hardware implementations of AES are mentioned as being resistant to some side-channel attacks, while ChaCha20’s simple operations also make it less susceptible. However, implementing cryptographic systems correctly is challenging.
Governments and security agencies pushing for “entry for government into the system” or proposing ways to “remove this encryption” are often viewed as suggesting mechanisms that would either revert to less secure models (like key escrow) or introduce deliberate weaknesses (backdoors). Cryptographers argue that this is often “impossible” in true E2EE systems without completely undermining their security. Any backdoor, if discovered by malicious actors (criminals, foreign states), would become a critical vulnerability for all users of the system. The sources suggest that when E2EE is robust, attackers are more likely to target the endpoints themselves (the user’s device), as messages must be decrypted to be displayed. Stealing or compromising a phone bypasses the encryption entirely.
Thile E2EE provides strong privacy and security by ensuring only communicating parties hold the decryption keys, proposals for backdoors or third-party access mechanisms directly conflict with this principle. Such measures create central points of vulnerability, introduce exploitable weaknesses, and, if compromised, can have devastating consequences for the security and privacy of all users.
An international law and human rights law perspective
In the landmark case of Podchasov v. Russia, the European Court of Human Rights (ECtHR) considered whether state-imposed decryption mandates were compatible with the right to privacy under Article 8 of the European Convention on Human Rights (ECHR). The case arose when the Russian Federal Security Service (FSB) demanded that the messaging service Telegram provide decryption keys to access users’ end-to-end encrypted communications. Telegram argued that complying with this demand would require the creation of a ‘backdoor’, which would compromise the security of all users’ communications.
The ECtHR recognised that end-to-end encryption (E2EE) is essential for safeguarding individuals’ private communications, particularly in an era where data breaches and unauthorised surveillance are widespread concerns. The Court emphasised that encryption protects not only personal data, but also underpins other fundamental rights, such as freedom of expression. The Court also noted that weakening encryption mechanisms could lead to indiscriminate and widespread surveillance, posing a significant risk to the security and privacy of all users.
Crucially, the Court found that the Russian authorities’ actions lacked adequate and effective safeguards against abuse, meaning the interference with the applicant’s rights was neither necessary in a democratic society nor proportionate to the legitimate aims pursued. The judgment emphasised that any measures compelling service providers to undermine encryption must be carefully scrutinised to ensure they do not infringe the essential rights protected by the ECHR.
This ECtHR decision sets a significant precedent by affirming the importance of strong encryption in safeguarding privacy rights, and by highlighting the necessity for any state interference to be justified and proportionate, and to be accompanied by robust safeguards.