8

I was thinking about building a simple end-to-end encrypted chat with group chat capabilities. Please bare in mind that 1) it's just an experiment to help me know more about cryptography and 2) I'm an humble programmer not a security expert that knows all the cyphers out there and complex encryption schemes.

My first thought was to:

  • Single conversations (two persons): each client generates a public/private key pair and sends the public key to the server. Every-time someone whats to talk to another person they just have to grab the recipient's public key from the server and encrypt the messages using that key. Later on the recipient can just decrypt them with their private key;
  • Group Chats: when someone starts a group chat:
    1. A public/private key pair is generated by the user who created the chat (lets call it starter);
    2. The "starter" fetches all public keys of the participants from the server and encrypts the chat's private key with them;
    3. The "starter" sends the encrypted chat private key to each participant;
    4. Each participant can now send encrypted messages (by encrypting them with the chat's public key) and decrypt messages coming from others by using the chat's public key.
    5. If someone is added or removed from the chat, a new chat public/private key pair is generated and distributed using the same procedure above.

Focusing on the group chats: What are the drawbacks of this implementation? Is this a reasonable and secure approach to the problem?

the
  • 1,841
  • 2
  • 16
  • 33
TCB13
  • 217
  • 3
  • 7
  • 1
    Interesting project. Be aware that the server can provide fake public keys to intercept communication. I'm not sure how commercial E2E systems like WhatsApp prevent that (perhaps they don't). For group chats you probably just need a symmetric key for the group, that is sent to people added, and when someone is removed, the key is regenerated. – paj28 Feb 26 '19 at 10:26
  • @paj28 `For group chats you probably just need a symmetric key for the group, that is sent to people added, and when someone is removed, the key is regenerated` isn't that what I described? – TCB13 Feb 26 '19 at 10:43
  • If I understood correctly, you suggested a public/private key pair. That's probably overkill and a symmetric key would do. – paj28 Feb 26 '19 at 11:09
  • @paj28 but with a public/private key pair I can distribute the group chat private key by encrypting it with a previously known public key of the participants.... Meaning the server doesn't really know any key. – TCB13 Feb 26 '19 at 11:13
  • 1
    I think you could do the same with a symmetric key. Anyway, there's no security weakness with using asymmetric crypto here, I was just suggesting it as an optimization. – paj28 Feb 26 '19 at 12:00
  • 1
    Take a look at OMEMO, OTRv4, Matrix.org OLM, Signal, MLS (messaging layer security) – Natanael Feb 26 '19 at 13:59

2 Answers2

3

Overall

I would recommend that you use hybrid encryption.

It's more performant than using "only asymmetric encryption" (public-private-key). Some problems could even occur when you encrypt very long messages with asymmetric encryption.

The server should never know the symmetric keys. It's main task is to guarantee the transmission of the messages.

2-party-E2EE

The first "message" between two parties is the exchange of a symmetric key via asymmetric encryption. This is to increase the performance of all succeeding messages (symmetric encryption and decryption is faster than asymmetric encryption).

Mulit-party E2EE

This basically works the same way as the 2-party-end-to-end-encryption. The simplest method would be this:

  1. The admin of the group chat creates a (random) symmetric key.
  2. The admin sends this symmetric key to each recipient of the group via asymmetric encryption.
  3. All further messages are then encrypted & decrypted with this symmetric key.
  4. If a new party joins the group then this symmetric key can be sent to this party as well, if you don't care that these members then also can decrypt previous messages. If you don't want them to decrypt older messages, then the 1. step is repeated.
  5. If a party leaves the group then the 1. step is repeated.

Edit: I should probably also add that there are definitely more details to it, but this shows the basic functionalily.

Community
  • 1
AleksanderCH
  • 711
  • 3
  • 10
  • 23
  • Thank you for the answer, your hybrid approach makes sense to minimize CPU usage. – TCB13 Feb 26 '19 at 11:25
  • 3
    Be aware that previous group messages could be decrypted by new joiners. Consider renegotiating the shared key every time someone new joins. – John Deters Feb 26 '19 at 13:38
  • Since there are multiple similar real world implementations for end-to-end encryption for chat applications, starting from scratch with your own protocol implementation is not a great idea. This answer contains some good advice, but there's plenty more to an actual end-to-end encryption designed than what's been shared. – Filipe dos Santos Feb 26 '19 at 23:34
  • 1
    @FilipedosSantos you missed `its just an experiment`. – TCB13 Feb 27 '19 at 14:07
2

There is no need to reinvent the wheel or design your own cryptographic protocol that will likely be flawed due to lack of experience.

Message Layer Security (MLS) is a trend in the cryptology academy due to the complexity of implementing end-to-end encryption for large scale chat applications (like WhatsApp/Snapchat/Telegram).

There are multiple proposals that were accepted by the academy and some were already implemented in real world applications like WhatsApp and Signal. WhatsApp uses a Noise Protocol and Signal uses is own protocol also called Signal.

Per the recent development progress made by Nadim Kobeissi (and team) the Noise Protocol Framework currently is the best option for any real world application that wants to implement a secure end-to-end protocol that is based on DH key exchange and is not TLS.

I strongly recommend you to watch the following Real World Crypto talks on the Noise Protocol Framework and Noise Explorer, I'm sure this will immensely enlighten you:

The Noise protocol framework| | Trevor Perrin | RWC 2018

Noise Explorer: Fully Automated Modeling and Verification for Arbitrary Noise Protocols

Filipe dos Santos
  • 1,090
  • 4
  • 15