1

I'm designing a chat-like application. Every message sent must be encrypted. Multiple users must be able to decrypt it.

In the early stage, a chat will contains only two chatters. This way I can implement it with a simple asymetric encryption. But later more user could join a chat.

For example, if Bob, Alice, and John want to chat together, when Bob send a message, he has to encrypt it using a public key known by all, then Alice and John must be able to decrypt it, each with their OWN private key (can't be the same has privte keys can't leave device for security reason unless you've got a way to secure the private key exchange).

I guess there is no implementation of such an assymetrical encryption but it must be some workaround to get it worked.

EDIT : After some more research I found out broadcast encryption would be the thing to use. But don't understand how it can work. Let's say my three chatters have a public/private key. When Bob send a message, he still have to send it to encrypt it one time for each users with their corresponding key ? Otherwise how can a different private keys decrypt a message encrypted with only one public key ?

EDIT 2 : For what i understand now, I have to choice:

  • Store a same symetric key for the chat and send it to all chatters after I encrypted it with their personnal public key. Not that good I think... I should not store such an important key, right ?
  • Store a public key per chatter, and send an encrypted version of each messages to each of them (encryptted with their own personnal public key)
Improve this question
2

1 Answer 1

Reset to default
1

One simple way would be for the chat originator to generate a unique, throw-away symmetric encryption key. Then the "invitation" packet to any other participant contains the encryption key, itself public-key encrypted with the recipient's public key. Or the "announcement" packet might contain all the necessary encrypted versions of the key.

This way, only the intended participants can come to know the decryption key, and since it is also an encryption key, they may use it to send messages as well as receive them.

This is not the same problem as broadcast encryption, since each participant uses the same key and knows it.

To revoke a participant, whoever has the right to do so sends a revoke packet containing a new secret symmetric key, encrypted with the public keys of the non-revoked participants.

Improve this answer
5
  • With your solution, when I start the chat the follow would happen: I invite you => Here is my public key => thx, here is the symetric encrypted with your public key. All regular messages would be encrypted with the one encrypted key ? If I want to add a user later, I would have to either store that first symetric key, or generate a new one that I forward to anyone, right ?
    – Bancarel Valentin
    Jun 6, 2017 at 18:36
  • Yes, you would generate and store a unique symmetric key for every chat.
    – LSerni
    Jun 6, 2017 at 19:10
  • And yes, you could change everyone's key at each invitation to prevent the new arrival to access past messages.
    – LSerni
    Jun 6, 2017 at 19:11
  • Isn't storing a symmetric key a bad practise ?
    – Bancarel Valentin
    Jun 7, 2017 at 7:33
  • It depends. In this case nothing prevents the client from storing the invitation packets, where the symmetric key is encrypted asymmetrically; actually you would need to do that, in order to access the chat history.
    – LSerni
    Jun 7, 2017 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.