I want to use end-to-end encryption for communicating with other clients using my app. I had the following idea.

  1. Every client creates a public and private key.
  2. Everyone sends the public key to my server and anyone who wants to send messages to another client, gets their public key for that client from my server.
  3. Then he encrypts his message with this key and sends it to my server.
  4. I will save it in my DB until the receiver downloads it.

Is this end-to-end? Is this a secure method? First I wanted to use libusodium for end-to-end encryption but I think this should also work right?

  • 1
    Why should I trust you? See the signal application for user verification
    – kelalaka
    Commented Nov 29, 2019 at 22:04

1 Answer 1


Your general description is fairly standard end-to-end encryption. However, as in most cryptography systems, the main issue is key management, and that's where this can go wrong. For example, your scheme has no independent mechanism to verify the other party's public key. So consider the following scenario:

  • Alice generates keypair and sends public key (A) to server
  • Server secretly generates its own keypair (S)
  • Bob requests A, but server provides S.
  • Bob encrypts to S and sends to the server
  • Server decrypts with S, then re-encrypts with A and sends to Alice.

Unless there is an independent way for Alice to confirm her public key to Bob, Bob has to trust that you're not doing that.

This is but one possible problem with the system; there are many other ways it can go wrong. Without a detailed description of the design, implementation, deployment, and maintenance, it's impossible to judge whether it's secure.

libsodium doesn't change anything here one way or another. It's a perfectly good cryptography library, but designing a secure messaging protocol is a lot more than just good cryptography. A great many systems fail in their key management. It is very easy to mess this up. I would not recommend designing a crypto system of any kind without engaging someone experienced in the field.

  • So what can I do against this scenario? Just display the public key f.e. as an qr-code and let the user scann to proof the using the right keys? I think threema and whataapp doing so
    – Jones
    Commented Dec 1, 2019 at 11:07
  • That could be a part of addressing that specific problem. It depends exactly how it's designed and implemented whether it mitigates the issue correctly, and meets your other usage requirements. There's no good way to get you to a secure system one feature at a time this way. The entire system has to be considered together to evaluate it, and that's not conducive to a Q&A site. If you're trying to build something where security is central to the product, you will need security expertise, either by study or by hiring it.
    – Rob Napier
    Commented Dec 1, 2019 at 16:04
  • Security is not like most other parts of software. For most software skills, "users find few bugs" is sufficient to know you've done it to an acceptable level. Horrible, broken security, on the other hand, can look almost identical to good security, and users won't know there's a problem until it's too late. Security has to be designed in, and that requires expertise that is difficult to acquire without some formal study. I wish there were an easy "just read this and follow these rules and it'll be secure," but security doesn't work like that.
    – Rob Napier
    Commented Dec 1, 2019 at 16:09

You must log in to answer this question.