= VIII. ''(n)sec'' Protocol: Step by Step =
<span style="font-size:200%">I</span>n this section we present the ''(n)sec'' protocol in algorithmic format. All user Ids IDs should be considered the modulo number of participants in the room.
Deniable authentication is derived from the Triple Diffie-Hellman algorithm presented in [Sys14]. Joining the room is a variation of the two-round mBD+P protocol presented in [ACMP10] where the authentication step has been made deniable. Leaving the room is the one-round mBD+S from [ACMP10].
== '''VIII.1 Schematic view of the key exchange '''==
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 [[''(n)sec''#VII.2b_Participatory_vs_individually_independent_computation_of__group_keysParticipatory_vs_individually_independent_computation_of_group_keys|Section VII2.2bAppendix 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 and -.3. However, we disucss discuss their property and we present some canadidatescandidates.
For simplicity, group operation is written multiplicatively, although it is actually an elliptic curve points operation traditionally represented by addition. Where ever Whenever our design deviates from [ACMP10], it is marked by in {{Font color|black|yellow|yellow}}. Pink means we We have abstracted out the step steps mentioned in [ACMP10] as an independent primitivein {{Font color|black|pink|pink}}:
'''Algorithm 1'''
|align="center"|<math>sid_i \leftarrow (U_1|y_1|\dots|U_n|y_n)</math>
|align="center"|Receive
|-''(n)sec''
|align="center"|2.1
|align="right"|Generate Triple Diffie-Hellman P2P keys
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 adjust the implementation to have a threshold time to wait and thus start a chat with more participants. However, this makes the implementation significantly more complicated without any 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 [[''(n)sec''#VIII.3_Joining|VIII.3]], as they enter the chat. Algorithm [[''(n)sec''#Chatroom_setup|1]] describes the chat room setup protocol.
'''Algorithm 2'''