The security approaches for messengers nowadays

The recent tweet thread about #Telegram made me write this article about designing for security.

Actually Telegram does have end2end encryption, but only in secret chats, and this limitation does not come for free: a secret chat is accessible only on the device pair it was originally created because it requires the encryption keys to be stored on the device. In order to provide rich clients for all the platforms possible telegram does not use the e2e for regular chats, so you get your history on all the devices you have. Whatsapp for example limits your usage to a single device, leveraging the end to end protection to all your communications (at least they say so).

It may appear that we have a contradiction (see TRIZ) between security and user experience. The more secure you make the system the more actions you require from the user or the more limitations you introduce. Providing a very simple example, we may say that it’s convenient not to lock up your car for fast access; but it’s also obviously not safe in terms of stealing so we introduce a lock and a key.

In a software architecture this is a contradiction in requirements leading to the process of balancing between usability and security quality attributes of a system to design.

However the security by defaultprinciple tells us to make the system as secure as it could be ever possible; ideally not affecting the user experience. In my understanding this is the reason we have touch ids on our phones and soon everywhere else.

Lets get back to our messenger example. Could Telegram really keep their chats both secure and still accessible from several devices simultaneously? For sure it can! It takes a little: the only necessity is to transfer the encryption keys for e2e communication. The process will look like this:

We will need to introduce a procedure of adding a new device. Imagine you registered a first device, and, since you want all your chats be end2end encrypted the client generated a key pair and shared the public key to the server(because how the people’s clients are going to know about your key?). The private key though stays on your device.

Ok, now you want to add a second device — for example a tablet. You need to receive the private key from your first device and do it in the most secure way, as this is a secret you want to be kept secret. But we want to make this transfer user-friendly, right? There is a way.

The second device just generates new temporary keypair and exposes the public key of the pair in the form of QR code and let the first device scan this data. Once it’s scanned the first device encrypts it’s private key with this temporary public one and transfer it over the network. This is safe, because it’s encrypted and only the second device can decrypt the data. Once it’s transfered the second device now becomes a full-functional client.

This is a very simple explanation which omits several aspects of such transfer including the device verification, but the whole idea is that Telegram still can do e2e encryption the default behaviour not missing the opportunity to work on several devices in parallel. I hope the telegram team implements this.

I want to emphasize that nowadays the governments of Russia, China, USA and definitely others are abusing the people privacy pushing on the internet and service providers. In such situation software developers and solutaion architects should aim to design the systems as secure as possible to protect the people agains their own politicians.