Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. OTR authors proposed a generalisation of two-party OTR to a multiparty use-case in [GUVGC09]. However, they did not specify the cryptographic primitives, neither did they give a formal definition of the adversaries nor the proof of the algorithm’s security (reduction). Although a more robust key exchange is proposed, some primary performance analysis of the implementation of the key agreement protocol has been shown to be impractically slow, especially on mobile devices [Gun13a][Git11]. [LVH13] proposes GOTR as an alternative to [GUVGC09] with goal of improving some of the security and practical properties of [GUVGC09]. Most notable change in GOTR compared to the original mpOTR proposal in [GUVGC09] is the use of p2p private channels to send message digest to establish transcript consistency and implicitly message origin authenticity between users. GOTR strives to imporve on repundibility and forgibility of the [GUVGC09]. It has been claimed that GOTR is to provide online repundibility (deniability against online judge), per message forgibility and and forging the entire transcript by a single party (the third seems possible by [GUVGC09] as long as a deniable AKE is being used). The notation of online repundibilty relies on the judge controling up to '''N-2''' parties while the two remaining "honest" parties are allowed to collude. This is an rather unusual notion for both repundibility and honesty. [LVH13] also proposes an involved contributory BD based key agreement scheme, which disregard room consistancy and turn GOTR into a broadcast scheme (c.f. Appendix B).

<span>'''Definition IIIV.1 Multi-party chat session'''</span>'': Let <math>\mathcal{U} = \{U_1,...,U_m\}</math> be the set of possible participants. A multi-party chat session is an ordered pair <math>S := (\mathcal{S}, sid)</math> in which <math>\mathcal{S} \subset \mathcal{U}</math> and <math>sid</math> is the unique session id. Without loss of generality we assume <math>\mathcal{S} = \{U_1,...,U_n\}</math> and we interchangeably refer to party <math>U_i</math> by index ''i''. Furthermore, it is assumed that party <math>U_i</math> is presented and identified verifiably by a long-term persistence key pair <math>(LPK_{U_i}, LSK_{U_i})</math>.''

<span>'''Definition IIIV.2 sub session'''</span> After session ''S'' is established, A subset of participants <math>\mathcal{T}\subset \mathcal{S}</math> might want to start a session in which parties in <math>\mathcal{T}\backslash\mathcal{S}</math> are excluded (for example when those parties leave the chatroom). In such a setting we say <math>T := (\mathcal{T}, sid^T)</math> is a subsession of ''S''. When there is no need to specify the subsession of choice, we use <math>spid</math> to refer to <math>sid^T</math>.

<span>'''Definition IIIV.3''' ''An'' '''authenticated group key exchange (AGKE)'''</span> ''is Algorithm <math>\Pi</math> which each honest party will execute in order to communicate (by means of sending, receiving or computing) a cryptographic secret - namely a key - among the other parties of a session. By <math>\Pi^S_i</math> (or <math>\Pi_i</math> when the underlying session is understood) we are referring to an instance of <math>\Pi</math> which the party <math>U_i</math> executes to achieve the collective goal. Further more we define'':

* <span>'''Participant list'''</span>'': <math>plist^S_i</math> is the list of participants which <math>U_i</math> believes are participating in the chat session ''S''.''When there is no ambiguity in the underlying session, we simply use <math>plist_i</math> notation.* <span>'''key id'' is the serial number given to the P2P keys generated during the process of key exchange, is computed as <math>Hash(U_i|y_i|U_j|y_j)</math>.* <span>'''Ephemeral key list'''</span>'': <math>klist^S_i</math> is the list of ephemeral public key <math>y_j = g^{x_j}</math>'s of all participants which <math>U_i</math> believes they are using in the chat session ''S''.'' When there is no ambiguity in the underlying session, we simply use <math>klist_i</math> notation instead. We use the notaion of <math>plist_i|klist_i<\math> to represent ordered concatenation of <math>U_i|y_i</math> pairs as in <math>U_1|y_1|\dots|U_n|y_n</math>. The order is assumed to be computable by all participants (lexicographically ordered using long term public key of participants, for example).

We have chosen our deniable signature key exchange protocol following the conclusions in [Gun13b] - by identifying a secure key exchange protocol that satisfies our needs. We then apply the triple Diffie-Hellman authenticated exchange to grant it properties of deniability[Ma13]. Subsequently, one can apply the same approach presented in [Gun13b] to communicate ephemeral signature keys during the key establishment process. However, for efficiency, we use the same ephemeral Diffie-Hellman private and public values used to deniably authenticate users and generate secret shares to produce ephemeral signatures.

* Although the Schnorr based algorithm suggested in [BVS05] satisfies a more comprehensible deniable model, Triple triple Diffie-Hellman authenticated key exchange only needs two rounds of communication and can be done alongside the key agreement steps, while the Schnorr based algorithm of [BVS05] needs four rounds.

Although computing The protocol computes a unified session key for all participant is possibleparticipants. This imposes, in particular, the protocol will compute ''n'' different keys each being used to decrypt the text received from the corresponding participant. In other words, Participant necessity that all <math>U_iplist_i</math> uses key <math>sk_{i' is identical for all participants. However,i}</math> to encrypt data. Formally we consider a tuple as consistent view is part of <math>sk^S_i := ''(sk^S_{i,n+1})sec'' security model,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 it does not impose extra limitation on 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 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}}:

|align="center"|BroadcastComputation

|align="center"|{{Font color|black|pink|<math>sk_{i,j} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math>}}

|align="center"|<math>sk_{i,j} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math>

We offer an extension to the ''(n+1)sec'' 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, ''(n+1)sec'' displays a message highlighting the fact that although the user is not part of the session part of the conversation (from users' who confirmed the new user's identity) is being shared with them (through P2P encryption using the key derived from DH Key). The protocol, however, does not honour their input in the consistency check until a new session including the new user is set up. Each client can decide whether to disable this option.

In this This is less secure model, in which 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.The detail of the process is depicted in Secthoin VIII.5

meta_onlyflag, ustate_1, ..., ustate_n, current_load

|align="center"|<math>sk_{i,j} \leftarrow H(GroupDec(k_{i,j}, z_j \; \forall j),sid_i, U_j) \; \forall j \neq i</math>

'''Algorithm 10.XX'''

ED25519 has been chosen as the signature primitive due to its efficiency and more secure implementability over other elliptic-curve digital signature algorithms.[Be11]

We are using AES-256 in counter mode Galois/Counter Mode (GCM) with a shared group key for message encryption, as suggested we are following the suggestion by the original OTR protocolof using counter mode. However, unlike OTR, <math>(n+1)sec</math> does not support per message forgibility (although the whole transcript is forgible), it is not prohibitive to use the same key for encryption and authentication. The added authentication, spares p2p send and receive routines from using digital signature. With GCM mode, the authenticated encryption is generically secure by the result (and assumptions) of [Kr00].

By contrast, a broadcast scheme refers to a scheme in which each participant is broadcasting a message to a set of participants of their choice from a set of potential participants. Each participant will have its own different <math>plist_i</math> which is able to broadcast as well. See GOTR by [LVH13] For an example of such scheme where each participant chooses there own circle of audiances. <!--In such protocol we define <math>plist_{union} := \cup{i \in {interested participants}} plist_i</math>.-->

===Participatory vs individually independent computation of group keyskey(s)===