=== Chat setup ===
In almost any practical case, participants join the chat sequentially. It is assumed that multiple participants cannot join simultaneously. For the sake of efficiency one can tweak the implementation to have a threshold to wait and start a chat with more participants. However, this makes the implementation significantly more complicated without an evident efficiency benefit.
Therefore, our assumption is that a secure chat is always set up when a participant starts the chat room. Additional participants would be added sequentially using Algorithm [[mpCAT#VIII.3_Joining|VIII.3]], as they enter the chat. Algorithm [[mpCAT#Chatroom_setup|1]] describes the chat room setup protocol.
====Chatroom setup====
=== Joining ===
Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[mpCAT#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[mpCAT#Protocol_for_other_participants_already_in_the_chat_to_accept_the_newcomer|3]], which runs on the clients of participants that are already in the chat.
When a new participant <math>U_{n+1}</math> joins the chat, current participants can still use their established authenticated ephemeral public key (to derive the <math>sessionKey_{new}</math> and as their signature verification key). Confidentiality of <math>sessionKey_{old}</math> is guarded against the new participant by Diffie-Hellman key shares hashed alongside the session id (which is dependent on the list of participants). The new participant cannot combine the old and new shares to recover <math>sessionKey_{old}</math>. The fact that old participants do not need to compute new ephemeral keys (and re-verify their ephemeral identities) decreases the computational complexity of the protocol.
====Join====
{{algorithm-end}}
=== Sending and receiving messages while joining is in progress ===
In situations where a prolonged joining process (due to connection problems or malicious activities) has an adverse effect on the user experience, it might be desirable to enable the joining users to communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.
Consistency aspects of mpCat, both for the room view (plist) and for the transcript, are reached through group agreement. However, there are times when group agreement may be hard or impossible to reach either due to latency in a single participant connection or due to a single participant broadcasting incorrect confirmation data (such as wrong plist, sid, key share, etc).
We offer an extension to the mpCat protocol to tackle this problem during the joining process. When a new participant joins the room, they send their DH key shares to the other participants. The other participants send their ephemeral key in return. They then send their key confirmation and key share. If this extension is to be considered, as soon as each user receives a key confirmation from another user, who is not currently part of the session, mpCat displays a message highlighting the fact that although the user is not part of the session, the conversation is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input into the consistency check, until a new session including the new user is set up. Each client can decide whether to disable this option.
The user remains in the list of those not part of the current session, but receives the session messages until a new session is set up. Similarly, when a user receives a message from a user who is not part of the session, mpCat will decrypt the message and display it with a disclaimer that the user is not yet part of the session and that some participants may not receive the same message.
In this model, a room is a forwardly secure authenticated communication channel while a session is a subset of the room, which additionally offers a consistent view
of the room and consistent messages among participants.
=== Leave ===
Leaving a chatroom involves only one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Algorithm [[mpCAT#Farewell|4]]. The remaining participants only need a notice from the server that the user is leaving to re-run the one round key update algorithm. Also, failure to receive a heartbeat from a user will result in executing Algorithm [[mpCAT#Farewell|4]] excluding users which did not update their key.
====Farewell====
<span style="font-family: serif; font-size: larger; font-variant:small-caps;">'''Broadcast</span>'''(":3mpCAT:3KeyShare:3", <math>myId</math>, <math>keyShare_{myId}</math>, <math>originAuthSignature</math>) # we can send this encrypted but leaving person can read it, hence theoretically it is the same as sending it unencrypted.
{{algorithm-end}}
=== Secure Send and Receive ===
After the session key is established, participants will use Algorithms [[mpCAT#Send|5]] and [[mpCAT#Receive|6]] to communicate securely.
On Send, the protocol checks the status of the new ephemeral Diffie-Hellman and key share using messages it receives from participants. It (re)sends any missing pieces. It also informs other participants which part of the key share is received by that user. The metadata flag indicates if the message being sent only contains meta data (e.g. heartbeat) or actual user communication.
On Receive, the protocol updates who has which pieces of the key shares. The protocol also generates a new group key if the new key shares have been received from all participants or those who have not updated their key shares time out on their heartbeat interval.
====Send====
Input: <math>lastMessage</math>
'''for each''' <math>message</math> in Messages Received from <math>lastDigestedMessage</math>+1 till <math>lastMessage</math>, '''do'''
<math>sesionDigest := HassHash(sessionDigest, message)</math>
<span style="font-family: serif; font-size: larger; font-variant:small-caps;">'''LRU Cache Store Digest</span>'''(<math>sessionDigest</math>, <math>message</math>)
'''return''' <math>sessionDigest</math>,<math>lastMessageId</math>
{{algorithm-begin|name=Hash}}
Input: <math>message</math>
'''return''' <span style="font-family: serif; font-size: larger; font-variant:small-caps;">'''SHA-512256</span>'''(<math>message</math>)
{{algorithm-end}}
[[Category: mpOTR]]
