Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am working on a chat application which supports both single user chat as well as group chat.

We planned to encrypt messages in single user chat by public key of receiver and decrypt it using private key of receiver.

If we go by this approach then we are clueless about implementing it in case of group chat.

Any thoughts?

share|improve this question
    
how are you implementing this? Client-server? –  Jay Apr 28 at 11:32
    
yes... it is client server based. –  Miraaj Apr 29 at 6:20

3 Answers 3

This depends on model you use for group chat:

  • Peer-to-peer: You need to encrypt each message with the recipient's puiblic key and send it to each user separately, and create the "illusion" of a group chat. This will prevent new group joiners to see previous messages.
  • Client-Server: You upload the messages "signed" to the server, and encrypt them to each user.

Alternatively, you create a key pair for this "group" and send a copy of the private to all members of the group, but I'm sure you see the problem with that already.

share|improve this answer

Your best bet is probably to have the idea of a chat session and use a session key for the duration of it. Symmetric encryption is far faster and more secure than asymmetric, so if you have the session host decide on a session key and then encrypt that with each member of the conversation's public key and send them out, then each party would have the same session key and be able to participate in the conversation.

Alternately, you could simply encrypt the message for every recipient or setup unique sessions with each recipient, but this is a far slower and more processor intensive process, though it still uses roughly the same amount of data since the messages have to sent individually to each recipient anyway (unless you are using a server based relay).

share|improve this answer

I'm not aware of any standard way of implementing what you're requesting. However, you can take as model the kind of system used in EFS (and other similar software solution):

  • Have someone create the group chat. The creator will generate a unique key valid only for this specific chat.
  • Each chat message is encrypted using a symmetric encryption algorythm using the unique session (chat room) key.
  • Each time a new client joins, he will have to ask an existing chat member for the key (how you authenticate that new client is out of scope). That chat key is being encrypted by the sender using the new client's public key.

The main problem with this is how to vet for the new client: obviously, you need to perform that validation in a "strong" way because once someone obtains the session key, all messages - past and future using that key can be decrypted.

If your sessions are supposed to last for a long time, it might be useful to have some mechanism for key re-negotiation at some point.

Also, since in this system the initial client decides on the encryption key, you will have to be very careful about how that key is chosen as not to weaken the whole security by using a simple key and you should implement some way for the other parties in the conversation to reject a "weak" key (not forcing a renegotiation, just rejecting the connection)

share|improve this answer
1  
Would there be any particular problem with picking a new session key every time someone enters or leaves [perhaps numbering them], and sending out messages saying "Public-message session key #20, encrypted with session key #19, is XXX", and providing a means by which a client that missed one (or more) session-key updates could say "I'm XXX; please tell me session key #20 encrypted with either session key #16 or my public key?" If everyone who is entitled to key#16 is entitled to #20, the arbitrator could use the simpler encryption; otherwise, if XXX is authorized to #20, use the public key. –  supercat Apr 28 at 18:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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