End-To-End-Encryption for messengers

3 June 2016

End-To-End-Encryption is nothing new. With messengers like Whatsapp or Telegram it’s again an issue. If E2E-Encryption means that nobody but the endpoints are able to encrypt the messages, then how is this feature implemented so seamlessly?

What’s E2E-Encryption

End-to-end encryption ( E2EE ) is a system of communication where only the people communicating can read the messages. No eavesdropper can access the cryptographic keys needed to decrypt the conversation, including telecom providers, Internet providers and the company that runs the messaging service.[1] Surveillance and tampering are impossible because no third-parties can decipher the data being communicated or stored. For example, companies that use end-to-end encryption can’t hand over texts of their customers’ messages to the authorities - Wikipedia

Whats problem with encryption in general?

The big problem with encryption, using an unsecure channel, is the way how endpoints exchange the cryptographic keys. And this is even much more difficult if the persons never met. If we are using an unsecure channel we have to trust something and this “something” is the breaking point. Of course we have cryptographic algorithms like Diffie-Hellman key exchange but they just help us to exchange a key encrypted. If you don’t know how the Diffie-Hellman key exchange works, here is the most simplest explanation in an lillustration(I borrowed the image from Wikipedia, just click on the image to get to the source):

Algorithms like Diffie-Hellman do not ensure the integrity of our endpoints! Therefore an attacker can perform a Man-In-The-Middle attack to infiltrate the key exchange:

DH Key Exchange

Is there a solution?

We need a fixpoint we can trust somehow. The easiest way would be that if we know a person, we can meet and exchange the keys physically. In that way we use a different “secure” channel and we know each other(integrity). But that’s not always possible.

With public-key-algorithms it is possible to have central authorities we can trust(I don’t really trust them, but that’s another story..). Those authorities have 2 functions:

  1. register a person’s identity
  2. sign a certificate for this person

So if we trust the authority(our fixpoint here and we have the public-keys of the authority already installed on our machine) and our endpoint uses a certificate which is signed by this authority, we can trust the identity of our endpoint.

Another approach would be to have a Web-Of-Trust.GPG uses this approach. We can sign other peoples public key if we trust them. In that way we have a network of people who trust each other(fixpoint here) transitively. Pretty cool, but this needs users with some knowledge about public-key-technologies.

Again: “We need a fixpoint we can trust somehow”. And trust is an expendable word…



End-to-End-encryption exists a long time for emailing. Users have tomanually take care about the keys(PGP/GPG). They can make use of the Web-Of-Trust and it’s up to the user how paranoid his key/trust-management is. The thunderbird-extensions Enigmail makes it very easy to use E2E-encryption.


Jabber (also known as XMPP) is an extendable chat-protocol. Many jabber-clients have a built-in button for GPG-encryption. The users still have to take care of their keys for themself. Since there are many open-source clients, we also exactly know the implementation of it.


Some Jabber-Clients also support Off-The-Record(OTR). Off-The-Record is supposed to make the key-exchange more easy. So this is great for users who don’t want to take care about technical details. It work’s like this in action: Alice clicks on a button “otr”. Then a key is generated and sent to Bob. Bob’s client will also generate a key and sends it to Alice. Both User just see the fingerprint of both keys and can compare them. If they want more security, they can use another channel(like the phone) to verify the keys. The problem with OTR: if the jabber-server is compromised, a Man-In-The-Middle-attack might be possible. And of course: if both endpoints don’t verify their keys, the integrity of the keys can also not be ensured. But that’s the price for “easy-to-use”-encryption.


When I started to write this article, I was thinking about Whatsapp. Because Whatsapp advertises with “we support E2E-encryption”. Whatsapp is closed-source, so I was looking for an Open-Source-alternative for Whatsapp. And I came to Telegram.

Telegram is a Whatsapp-like messenger. And it’s open-source, isn’t it? Not really. The client-application is open-source but not the server-part. I checked out it’s source-code. And I was supprised because it just uses RPC-calls rather than make use of any chat-protocol(which is not bad! I just wrote that because I expected something else). Another supprise appeared when I saw the crypto-implementation. They break the first rule of crypto-development: “DON’T IMPLEMENT YOUR OWN ALGORITHM!”. Some flaws already have been discovered and discussed:


Here some quotes:

They use the broken SHA1 hash function

They include a hash of the plaintext message in the ciphertext. Essentially, they are trying to do “Mac and Encrypt” which is not secure. They should be doing “Encrypt then Mac” with HMAC-SHA512.

They rely on an obscure cipher mode called “Infinite Garble Extension.”

They do not authenticate public keys

Even if these flaws would not exist anymore there is still one question in my mind: How is the integrity of the keys ensured? E2E really means end-to-end. This means that the only nodes in this communication who know the keys are our endpoints. But I have never seen a fingerprint on Telegram where I could verify the key of my chat-partner. Telegram makes it easy: “just trust our server, then everything is easy and everything is okay”. What if the server is hacked? What if the server logs keys or messages? For me, this is not End-To-End-Encryption.


I don’t know how Whatsapp has implemented E2E-encryption. I know that it has to be enabled and that there are QR-Codes. Yet I don’t know how it works and can’t say anything about it, but I am very curious about it.

UPDATE : I found a Whitepaper about Whatsapps E2E-encryption

Another problem to deal with

So even if we use a messenger which really uses E2E-encryption, there is still one issue: What about the History-File? Thunderbird and Enigmail encrypts a message just for few minutes. After then you have to insert your GPG-mantra again. But I know some messengers, where you can encrypt your messages with GPG but the messages are still in plaintext in the history-file! And if you just disable history-logs on your client, you still can’t be sure that your opposite did it too.

[ Security  Crypto  ]
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution 3.0 Unported License.

Copyright 2015-present Hoti