Although computing a unified session key for all participant is possible, the protocol will compute ''n'' different keys each being used to decrypt the text received from the corresponding participant. In other words, Participant <math>U_i</math> uses key <math>sk_{i,i}</math> to encrypt data. Formally we consider a tuple of <math>sk^S_i := (sk^S_{i,1},sk^S_{i,2},...,sk^S_{i,n})</math> as a session key. This measure has been taken to facilitate the transition to a broadcast use-case where the protocol does not promise same <math>plist</math> for all participants and therefore, it is conceptually impossible to compute a unique key. For more information please see [[#Participatory_vs_individually_independent_computation_of_group_keys|Appendix B: Participatory vs individually independent computation of group keys]].
For the high level design of the protocol we do not specify the primitives for ''GroupEnc'' and ''GroupDec'' used in steps 2.4 '''XX''' and -.3'''XX'''. However, we discuss their property and we present some candidates.
For simplicity, group operation is written multiplicatively (even though it is actually an elliptic curve points operation and traditionally represented by addition). Whenever our design deviates from [ACMP10], it is marked in {{Font color|black|yellow|yellow}}. We have abstracted out the steps mentioned in [ACMP10] as an independent primitive in {{Font color|black|pink|pink}}:
|}
=== VIII.3 Join ===
Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[''(n)sec''#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[''(n)sec''#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.
After this step joining user will proceed to "initiate new session" by Algorithm 5.
==== Authentication Step for parties in the room====
For other participants to a accept a new participant only, the authentication step is different. After current participants authenticate the new user, they proceed to update session.
After this step users will proceed to "initiate new session" using Algorithm 5.
==== Initiate new session ====
'''Algorithm 5'''
|}
==== 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 that joining users can communicate with the parties in the room, while maintaining minimum assurances of authenticity, confidentiality, forward secrecy, as well as consistency only among participants.
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.
===VIII.4 Leave===
Leaving a chatroom involves a message from a leaving party indicating its intention to leave which, as with all other messages, contains the hash of TranscriptChain and one procedure for those who are staying in the chatroom (Procedure Farewell) which is described in Table [[''(n)sec''#Leave]].
====Farewell====
Run by exiting user.
|}
====Shrink====
When the remaining participants receive the farewell message they need to reply with the Hash of TranscriptChain of the last message seen by the leaving user. They also need to re-run the one round key update algorithm. However, they only need a notice from the server that the user is leaving to initiate a subsession excluding the leaving user.
Users will proceed to "initiate new session" steps.
=== VIII.5 Secure Send and Receive ===
After the session key is established, participants will use Algorithms [[''(n)sec''#Send|5]] and [[''(n)sec''#Receive|6]] to communicate securely.
|}
=== VIII.6 Reaching Consistency ===
The protocol provisions two procedures to reach consistency in different cases: (a) reaching consistency for arbitrary messages during the course of a conversation, and (b) reaching consistency when an instance <math>\Pi^S_i</math> leaves. Case (b) may be viewed as a special instance of case (a) plus the additional premise that <math>\Pi^S_i</math> must reach consistency as soon as possible (because they want to leave), and that they don't care about reaching consistency for any subsequent messages that they might receive after their final "farewell" message.
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''
=== VIII.7 Heartbeat ===
Heartbeat is an empty message which contains only meta data. The meta data consists of information used to compute a new key and the most updated hash of transcript chain.
* BROADCAST_LATENCY: Modelling the amount of time which a message takes to reach the server and broadcast to the other clients. It should be based on the transport considered.
==== Failure to heartbeat and inactivity timers ====
Whenever, a message ''m'' is received a timer of (2*BROADCAST_LATENCY)+ACK_GRACE_INTERVAL) period is set. If the <math>H(Transcript_j[m'])</math> for a <math>m' \ge m</math> is received from all participants, the timer is cancelled. Otherwise at the time out, the protocol issues a local UI warning and cancel the warning if/when such a hash is received and is consistence among participants.