End-to-End encryption for a chat application

Question

I am trying to build an android chat application just for educational purpose. I would like to try implementing end-to-end encryption so that my messages are secure. I thought of using RSA as the encryption scheme (I'm new to the field of cryptography)

This is how I thought I should do it,

Step 1: Generate public and private key in the Client and Server sides.

Step 2: Exchange the public keys. (This means that server will have the public key of each and every client).

Step 3: Encrypt the message using the public key of the Server and send to Server or vice-versa.

Step 4: The Server can then use its private key to decrypt the message.

So my questions are,

1. How am I to store the private keys?
2. What are the drawbacks of this approach?
3. How should this actually be implemented?

Please help me clear this concept

Answer 1

What you describe is not end to end encryption.

End to end implies that the communication between the two endpoints (clients) is encrypted. The whole idea is that the server can never read or modify the conversation data.

I will mainly answer your last question, because this is probably the most relevant one:

How should this actually be implemented?

The goal that you want to achieve is for conversation partners to share the same secret key. The generally accepted method for this is to use (elliptic curve) Diffie-Hellman key exchange. After we have established a shared secret, we can start communicating between the clients using a suitable AEAD scheme.

Note that this is still prone to man-in-the-middle attacks, so we will need an out-of-band method to verify that the two clients actually share the same key. This is often done by manually comparing hashed values of the keys (example: Signal).

So basically the server only acts as a relay for the clients. In any case, it would still be a good idea to use TLS for connection with the server.

Note that we have not considered the following subjects:

• Forward secrecy (by rekeying)
• Replay attacks
• Anonymity of the clients
• Impersonation of other clients
• et cetera

In the end, you really want to implement a thoroughly scrutinised protocol like OMEMO or Axolotl, but I guess that's pretty far fetched for an educational project.