DEV Community

Max Bantsevich for dev.family

Posted on

How did we create a private messenger with E2E encryption?

Alt Text
It is a SaaS product for exchanging private messages between different platform users.

We were responsible for prototyping and design of a custom app that was developed in React Native to reach users of both iOS and Android, but not stretch the creation process over the long term.

Who did it?

The Web Secret team represented by Nikita Tolkachev and Masha Sidorevich, who are specialists in the field of cryptography and mobile development.

How long?

3 months. Yes, that's exactly how much time it takes to create a full-fledged and secure messenger that works on the SaaS principle and can be used by up to 10,000 people a day. At the same time, the speed of content generation and delivery by the server will not exceed 1 second at peak load.

Why is it cool for users?

You do not need to enter any personal data to access the app, because you already have a personal account on the platform. By the way, no one will find you by your nickname either. To log in, you will need a QR code or a direct link posted in the profile of the person you want to chat with, and the funds in your account.

Alt Text

So for a certain fee, you are given the opportunity to conduct absolutely secret correspondence online with any other user of the platform. And you can do this from several devices at the same time. Therefore, if you need a correspondence history or access to media files, you can get them from a mobile, or from a tablet, or from a laptop.

The project can be connected to completely different services and not even require a fee. For example, if this solution is selected by any representative of the financial sector for internal use.

E2E encryption

If you now started shouting: "Aah! Private messages will be stored on someone else's servers", it's time to tell you about the end-to-end encryption that was used to create the messenger.

In fact, this means that the decryption key is stored only in your device. And if someone attacks the server, intercepts the traffic, they will still not be able to read messages. They remain on the server until they are delivered to the addressees. But even there they stay encrypted. This means that even the owners of the service are not able to find out what you are writing to each other there.

Why is it cool technically?

As you already understood, we made secret chats, like in Telegram, but better, because in our case they are possible for several user devices, a kind of multi-device secret chat. AES-256 is used to encrypt the messages and a proprietary protocol applying elliptic curve cryptography is used to exchange the shared key.

The Sesame Algorithm

The synchronization of messages between all user devices, which the client insisted on, is implemented in a similar way to the scheme described in the Sesame algorithm (a protocol developed for Signal messenger). All used devices constantly exchange keys to support E2E encryption.

Data storage

Another requirement of the customer, storing messages on the server until the customer received it, was implemented as follows. Messages themselves are stored in PostgreSQL, and Redis is used for the Pub-Sub system. It is unreasonable to store messages in Redis, as it takes too much memory. The messenger supports exchange of media files (photos and videos), which are duplicated on all user's devices (the same notorious synchronization), and this would eat up a lot of memory.

What was used in the work?

Back-end: Go is a powerful and simple compiled programming language.

Mobile: React Native significantly reduced the development time for a cross-platform app without losing quality.

Databases: Redis, PostgreSQL. Redis is used in places where maximum performance is needed, PostgreSQL is a time-tested database used to store data about devices, users and messages.

Server: Docker, Kubernetes allow to reduce the cost of maintaining the server infrastructure, building CI/CD processes.

Who will be interested?

Companies that want to provide a secure channel of communication between employees with the ability to synchronize correspondence between several user devices, transfer media files with no need to store anything on their servers.

Top comments (3)

Collapse
 
james_palermo_bc208e463e4 profile image
James Palermo

What are your plans for having your crypto audited?

Collapse
 
mrbantsevich profile image
Max Bantsevich

The offer is interesting, but unfortunately this is a commercial project, so we can't give you an access.

Collapse
 
james_palermo_bc208e463e4 profile image
James Palermo • Edited

I wasn’t requesting access, I was asking what trusted third party authority will audit your cryptographic protocol to certify it as secure? Do you adhere to NIST standards? Do you offer a bounty for cracking your crypto like Telegram? Do you have a white paper explaining your cryptographic architecture and the reasoning behind it?

Why do you use a proprietary key exchange algorithm and not a standard robust Diffie-Helman?