Changes - learn.equalit.ie

Np1sec

36,394 bytes added, 7 years ago

/* Session Confirmation */

[[File:Np1sec-web.jpg|frameless|center|(n+1)sec]]

===Abstract===

''In this document we present the first public draft of ''(n+1)sec'' - a secure multi-party communication protocol developed by eQualit.ie with support from the [https://www.opentechfund.org/ Open Technology Fund] and [https://crypto.cat/ Cryptocat]. We include the design rationale, choice of security features, adversarial models, schematic and high level specification of sub-protocols. A subsequent document will present security proofs and implementation details.''

=I. INTRODUCTION=

The ''(n+1)sec'' project was inspired by [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Off-The-Record] messaging protocol and subsequent efforts to explore a multiparty use-case for OTR in [GUVGC09]. ''(n+1)sec'' is currently developed for [https://github.com/cryptocat/cryptocat/wiki/mpOTR-Project-Plan Cryptocat] - a browser based XMPP chat platform and assumes its use-cases. Most importantly, ''(n+1)sec'' allows for secure multi-party key exchange and end-to-end encrypted communications without extensive computational requirements from the client. You can follow and contribute to the implementation of [https://github.com/equalitie/~~libmpotr libmpotr~~np1sec np1sec] on our Github pages. Future protocol iterations will consider a variety of other real-world use cases and be platform independent. Please use the [[Talk:Np1sec|Discussion]] page to ask questions and leave comments.

In the following section we summarise relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we review the security properties within this protocol. In [[#V._Chat_Session_Model|Section V]] we give basic mathematical definition needed to model the chat session and security proofs for various security aspects of the protocol. [[#IV._Adversarial_Models|Section VI]] provides formal definitions and references to the adversarial models for each property. In [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._''(n+1)sec''_Protocol:_Step_by_Step|Section VIII]], we present each of the ''(n+1)sec'' protocol steps at various stages in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we ~~conclude by describing~~ define the work ~~remaining~~ that [[#Next_Steps|remains to be done ]] on this protocoland [[#XI._Acknowledgements|acknowledge]] the good people who have helped us get here.

= II. History and literature review =

[ACMP10] offers a more efficient protocol than [BS07] in the sense that ephemeral Diffie-Hellman elements are reusable to regenerate keys when some of the participants change. As such, it offers a one-round protocol to generate a key for a subgroup of the original conversation.

An unauthenticated exchange of the OTR version identifier can pose a threat to authenticity as shown in [BM]: the adversary can force clients to downgrade to an older, (potentially insecure ) version of the protocol. They also note the Diffie-Hellman key exchange failure in delivering authentication in the presence of an active adversary. Furthermore, they show that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property.

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 a goal of improving on some of its security properties. A notable change is the use of p2p private channels to send message digest so as to establish transcript consistency and implicit message origin authenticity between users. GOTR also strives to improve on repudiability by considering deniability against an 'online judge' as well as forgeability for the entire transcript by a single party (this is possible in [GUVGC09] as long as a deniable AKE is being used). The idea of online repudiabilty relies on the judge controlling up to '''N-2''' parties while the two remaining "honest" parties are allowed to collude. This is slightly unusual for both repudiability and honesty. [LVH13] also proposes an involved contributory BD based key agreement scheme, which disregard room consistency and turns GOTR into a broadcast scheme (c.f. [[#Appendix_B:_Other_design_possibilities|Appendix B]]).

=III. Design rationale =

We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication (even though it offers a slightly weaker form of deniability). We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.

* Omitting forgeability and malleability from the protocol and refraining from broadcasting the expired ephemeral authentication keys.

Following conclusions in [RGK05] we have dropped forgeability (mandatory publication of ephemeral signature/MAC keys) and malleability from our requirements since protocol deniability is based on a deniable key exchange. This significantly improves protocol efficiency, a primary focus for ''(n+1)sec''. The deniability of the authentication scheme prevents users not present in a chat session from forging a part of the transcript, however it allows them to forge a whole session with false participants and a complete transcript.

Another major departure from the suggested protocol in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or sends a message. Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the assumption that the ~~XMPP~~ chat server is mandated to provides a reliable and orderly message delivery, as it is in the case of XMPP protocol. We can ensure transcript consistency whenever the underlying transport layer guarantees the reliable delivery of the messages in the same order for all participants. If however, the underlying protocol does not guarantee reliability either in delivery or order, we report the discrepancy in user's transcript compared to their peers but we do not attempt to correct the transport protocol's action (we offer detection but not recovery).

We also equip ''(n+1)sec'' with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.

* '''Forward secrecy''' of the conversation, so its content remains inaccessible in the event that the long term private key of a participant (which represents their long term identity) is compromised after session key establishment. In addition in-session forward secrecy means that compromise of the ephemeral keys of a participant, or the session key during chat session which is live for long time, would reveal only a fraction of the transcript.

* '''Room consistency''', where all participants are confident that they have been participating in the same room; they are confident that everybody in the room believes that everybody else sees the same participant list as they do.

* '''Transcript consistency''', where all participants are confident that they have been participating in the same conversation; as the conversation continues, they are confident that they have ~~seen~~ been seeing the same sequence of messages.

For each of these requirements, it is necessary to formalize the above mentioned properties against an adversarial model which addresses the requirements stated in [[#Design_rationale|Section III]]. The next section will introduce formal definitions covering these elements.

In modelling the chat session, in terms of the adversarial models and protocol specifications, the notation of [ACMP10] is followed. This notation is common to other publication on group key exchange such as [GBNM11], and is adherred to for consistency.

'''Definition ~~III~~V.1 Multi-party chat session''''': 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>.''

'''Definition ~~III~~V.2 sub session''' 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>.

'''Definition ~~III~~V.3''' ''An'' '''authenticated group key exchange (AGKE)''' ''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'':

* '''Session id as seen by <math>U_i</math>''''': Session id <math>sid</math> will be derived during the execution of the protocol. The session id is computed by <math>\Pi^S_i</math> (the instance of the protocol run by <math>U_i</math> for session ''S'') and is indicated by <math>sid^S_i</math>, or <math>sid_i</math> when there is no concern of confusion''

* '''Participant list''''': <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.* '''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>.* '''Ephemeral key list''''': <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).

* '''Session key of <math>\Pi^S_j</math> as seen by <math>U_i</math>''''': <math>sk^S_i</math> (or <math>sk_i</math>) is the session key of session ''S'' as computed by <math>\Pi_i</math>. It represents the cryptographic secret computed by AGKE, it can be a set of secrets. The essential defining factor is that it should become common knowledge for the session participants at the end of AGKE execution. Similarly we define <math>subk_i</math> to represent the subsession key''

* '''Accepted state''''': A party enters the accepted state if it has computed <math>sk^S_i</math> and has detected no errors in the protocol.''

===Authenticated Key Exchange Adversary===

====Adversarial power====

The following set of functions model the AKE adversarial threats. The adversary for the authenticated key exchange can mount an attack through a sequence of call to the functions, outlined below. The limitation on the order and condition of calling these functions is defined per adversary. We will re-use these definitions to demonstrate similar routes for other adversaries considered by the threat models in later sections.

* '''Send(<math>\Pi^S_i,m</math>)/(<math>U_i,m</math>)''' sends a message ''m'' to the instance <math>\Pi^S_i</math>. We assume that ''m'' contains information to identify the sender <math>U_j</math>. <math>\mathcal{A}</math> will receive the execution transcript. Specifically, by sending <math>plist</math> messages it forces <math>U_i</math> to initiate <math>\Pi^S_i</math>.

* '''SKE(<math>\Pi^S_i, spid_i</math>)''': asks <math>\Pi^S_i</math> to compute the subgroup key for the <math>spid_i</math> subsession. In response, <math>\Pi^S_i</math> will either send a message or compute the subgroup key <math>k_{spid_i}</math> depending on the state of <math>\Pi^S_i</math>. This can be invoked only once per input.

* '''RevealGK(<math>\Pi^S_i</math>)}''': <math>\Pi^S_i</math> gives <math>sk_i</math> to <math>\mathcal{A}_a</math> if it has accepted (as defined in Definition III.3).

* '''RevealSK(<math>\Pi^S_i, T</math>)''': <math>\Pi^S_i</math> gives the <math>subk^T_i</math> to <math>\mathcal{A}_a</math> if it has been computed for subsession ''T''.

* '''Corrupt(<math>U_i</math>)''': <math>U_i</math> gives its long term secret key to <math>\mathcal{A}_a</math> (but not the session key).

'''Definition VI.3''' An ''AKE Adversary for the join key agreement'' <math>\mathcal{A}_{join}</math> is a probabilistic polynomial time algorithm (ppt) which can invoke all the functions given above with a

condition that the ~~TestSK~~ TestGK is invoked '''at least once''' against a fresh instance <math>\Pi^S_i</math> which stays fresh until the end of the game. The game ends when <math>\mathcal{A}_{join}</math> outputs its guess for ''b''. We say a key exchange protocol is secure if the following function is negligible:

<math>

===Forward Secrecy Adversary===

We do not define an independent forward secrecy adversary. Forward secrecy can be derived by resistance against the confidentiality adversary as well incorporating a forward secure key exchange as described in [GBN10]. The adversaries of Definition VI.3 and VI.4, are able to ''Corrupt'' users after the communication of DH secrets. Therefore they can trivially break an AKE ~~which~~ without forward secrecy. In this sense, the resistance against forward secrecy adversary is included in AKE adversarial model.

===Deniability Adversary===

==Consistency Adversary==

In ''(n+1)sec'' protocol, we attempt to ensure the consistency among participants all along the session incrementally, i.e. assuring consistency after receiving each message in a timely manner. However, we do not model the incremental aspect of consistency into the adversarial model, for the sake of simplicity.

'''Definition 1''' ''Transcript Consistency Adversary'' <math>\mathcal{A}_{cons}</math> is given the ability to invoke all functions in sections [[''(n+1)sec''#Adversarial_power|IV.1.1.1]] and [[''(n+1)sec''#Adversarial_power|IV.1.1.3]]. We say the protocol is secure against ''Consensus Adversary'' if at least two uncorrupted accepted instances <math>\Pi^S_i, \Pi^S_j</math> possess the transcripts chain <math>TransChain_{\Pi^S_i}(l) \neq TransChain_{\Pi^S_j}(l)</math> and they believe they have the <math>TransChain_{\Pi^S_i}(l) = TransChain_{Pi^S_j}(l) with non-negligible probability.

# '''Deniable authenticated signature key and session key exchange''', where participants deniably authenticate each other and agree on session key(s), while also exchanging ephemeral signing keys

# '''Communication''', where parties send authenticated confidential messages

# '''Transcript consistency verification''', where parties verify that all have received and seen an identical transcript in the same order, since the start of the chat sessionafter receiving each messages.

Our choice of sub-protocols for ''(n+1)sec'' followed suggestions made in [BGB04] and [GUVGC09], except where there has been a practical or security-related reason to deviate from those recommendations.

== '''VII.1 Design of Deniable Authenticated Signature Key Exchange'''==

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.

For the choice of the base authenticated key exchange protocol, we suggest a variant based on [ACMP10]. The rationale for the choice is laid out as follows:

* [ACMP10] only needs one round of key re-agreement in the case of a participant leaving the chat, while [BVS05] enforces re-computation of Diffie-Hellman ephemeral keys and hence needs a minimum of two rounds plus overhead of re-authenticating the new ephemeral keys. This can significantly improve the efficiency of casual chat sessions where participants frequently enter and exit the chat.

* 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 key exchange algorithms based on the standard model are considered theoretically more secure than those based on the random oracle model, there has been no proposal for a 2-round protocol in the standard model that promises forward secrecy. Therefore, due to the importance of usability and efficiency in our approach, we opted to for a ROM based protocol such as described by [BVS05] and [ACMP10].

Since each message sent by any one participant is signed by the ephemeral private key generated for that specific session, it is not possible for the internal or external adversary to forge a message on behalf of an uncorrupted participant.

However, if the adversary is controlling the network structure, denial or delay of service is always possible. The consistency of the transcript (i.e. all participants see the same transcript in the same order) relies on the means of transport guaranteeing reliable delivery, with a single order, to every participant. In other words, we are verifying the ''reception'' of the message by the intended ''recipients'' . By assuring transcript consistency, we also preventing <math>U_i</math> from sending different messages to <math>U_j</math>, <math>U_k</math> while they believe they are seeing the same conversation. In absence of transcript consistency, when a ~~message~~central server is managing the chatroom, this attack requires <math>U_i</math> to conspire with server, which is permeable in ''(n+1)sec'' threat model in accordance with the definition of transcript consistency in [GUVGC09].

The protocol offered in this document examines the transcript for such consistency. In the case that the underlying transport fails to provide this level of consistency, clearly the consistency test will fail. In this sense, failure of consistency does not distinguish between malicious activities or the absence of a reliable transport.

In this section we present the ''(n+1)sec'' protocol in algorithmic format. All user 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]. In both cases, we have added a key confirmation round (round 3) as recommended by [ChMa10] to provide mutual authentication as defined in [GBNM11].

==VIII.1 Schematic view of the key exchange==

~~Although computing~~ The protocol computes a unified session key for all ~~participant is possible~~participants. 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_i~~plist_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 ~~the high level design of the protocol we do not specify the primitives for ''GroupEnc'' and ''GroupDec'' used in steps '''XX''' and '''XX'''. However~~simplicity, ~~we discuss their property and we present some candidates~~group operation is written multiplicatively (even though it is actually an elliptic curve point operation traditionally represented by addition).

~~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}}, however the resulting computation is identical with the one in [ACMP10] protocol:

'''Algorithm 1'''

{| border="1" cellspacing="0" cellpadding="5" align="center"

!align="center"|Round

!align="center"|Step

!align="right"|Description

!align="center"|Type

|align="center"|1

|align="right"|Generate ephemeral DH private key

|align="center"|Computation

|align="center"|

|align="center"|2

|align="right"|Generate DH key for BD, Triple DH and Signature

|align="center"|Computation

|align="center"|

|align="center"|3

|align="right"|Broadcast User identity and the DH key

|align="center"|Broadcast

|align="center"|2

|align="center"|4

|align="right"|Compute Session Id

|align="center"|Receive

|-''(n+1)sec''

|align="center"|

|align="center"|5

|align="right"|Generate Triple Diffie-Hellman P2P keys

|align="center"|Computation

|align="center"|

|align="center"|6

|align="right" |Generate key confirmations

|align="center"|{{Font color|black|yellow|<math>kc_i \leftarrow (H(k_{i,1}, U_1),\dots,H(k_{i,n}, U_n))</math>}}

|align="center"|~~Broadcast~~Computation

|align="center"|

|align="center"|7

|align="right"|Generate secret shares

|align="center"|<math>z'_i := \leftarrow (H(k_{i,j}, sid_i) \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\})</math>

|align="center"|Computation

|align="center"|

|align="center"|8

|align="right" |Encrypt shares

|align="center"|{{Font color|black|pink|<math>z_i \leftarrow GroupEnc(k_{~~i_j~~i,j} \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z'_i)</math>}}

|align="center"|Computation

|align="center"|

|align="center"|9

|align="right"|Sign identity, shares

|align="center"|Computation

|align="center"|

|align="center"|10

|align="right"|Broadcast encrypted shares and confirmation

|align="center"|Broadcast

|align="center"|3

|align="center"|11

|align="right"|Check the validity of key confirmation|align="center"|{{Font color|black|yellow|<math>~~kc_k[~~H(k_{j] ,i},U_i) \stackrel{?}{=} kc_j[kU_i] \; \forall j \neq k</math>}}

|align="center"|Receive

|align="center"|

|align="center"|12

|align="right"|Check signatures

|align="center"|<math>Verify_{~~y_i~~y_j}(\sigma_j) \; \forall j \neq i</math>

|align="center"|Computation

|align="center"|

|align="center"|13

|align="right"|Check Session Ids

|align="center"|Computation

|align="center"|

|align="center"|14

|align="right"| Generate session key

|align="center"|{{Font color|black|pink|<math>sk_{i,j} \leftarrow H(GroupDec(k_{i,jl}\forall l, z_j \; ) \forall j, sid_i)=H(z'_1, \dots, z'_n,sid_i) </math>}}|align="center"|Computation|-|align="center"|3|align="center"|15|align="right"| Broadcast session confirmation|align="center"|{{Font color|black|yellow|<math>(sc_{i} \leftarrow H(sk_i,U_i), sigma_i \leftarrow Sign_{x_i}(sc_{i}))</math>}}|align="center"|Broadcast|-|align="center"|-|align="center"|16|align="right"|Check the validity of session confirmation|align="center"|{{Font color|black|yellow|<math>H(sk_{i}, U_j) \stackrel{?}{=} sc_j \; \forall j \neq i</math>}}|align="center"|Receive|-|align="center"||align="center"|17|align="right"|Check signatures|align="center"|{{Font color|black|yellow|<math>Verify_{y_j}(\sigma_j) \; \forall j \neq i</math>}}

|align="center"|Computation

===Triple Diffie-Hellman authentication===

''(n+1)sec'' uses a varient of Triple Diffie-Hellman (TDH) protocol also employed in Textsecure protocol [Mo13] to carry out mutual deniable authentication as well as peer-to-peer secret key exchange. It can be seen as a variation of [SoKi00] key exchange, however, unlike SoKi00], as it does not multiply all three DH secrets and therefore is not suspticble to attacks mentioned in [BoMa10].

By using TDH secret both in p2p key as well as in key confirmation step, (n+1)sec both implicitly and explicitly authenticate the peers.

In Algorithm 1, TDH and the original group key exchange from [ACMP10] has been combined to provide a deniable authenticated group key exchange. Here, we single out TDH Algorithm 1.1 for better presentation of the protocol for the reader. Note, that the users run step 5 differently based on their order in the group. This measure ensures that the P2P key is computed the same between two parties, i.e, <math>k_{i,j} = k_{j,i}</math>.

'''Algorithm 1.1''' Triple Diffie-Hellman between <math>U_i</math> and <math>U_j</math> assuming i < j

{| border="1" cellspacing="0" cellpadding="5" align="center"

!align="center"|Round

!align="center"|Step

!align="right"|Description

!align="center"|Pseudo-code

!align="center"|Type

|align="center"| 1

|align="center"|1

|align="right"|Generate ephemeral DH private key

|align="center"|<math> x_i \leftarrow [0, order(g)]</math>

|align="center"|Computation

|align="center"|

|align="center"|2

|align="right" | Generate ephemeral DH public key

|align="center"|<math>y_i \leftarrow g^{x_i}</math>

|align="center"|Computation

|align="center"|

|align="center"|3

|align="right" | Broadcast User identity and the DH key

|align="center"|<math>(U_i, y_i)</math>

|align="center"|Broadcast

|align="center"|2

|align="center"|4

|align="right" |Receive other party id and ephemeral DH public key

|align="center"|<math>(U_j|y_j)</math>

|align="center"|Receive

|-''(n+1)sec''

|align="center"|

|align="center"|5

|align="right"|Generate Triple Diffie-Hellman P2P keys

|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i})</math>

|align="center"|Computation

|align="center"|

|align="center"|6

|align="right" |Send key confirmation to other party

|align="center"|<math>kc_i \leftarrow H(k_{i,j}, U_j)</math>

|align="center"|Broadcast

|align="center"| -

|align="center"|7

|align="right"|Receive and Check the validity of key confirmation

|align="center"|<math>kc_j \stackrel{?}{=} H(k_{j,i}, U_i)</math>

|align="center"|Receive

===''GroupEnc'' and ''GroupDec'' functions===

For the high level design of the protocol we do not specify the primitives for ''GroupEnc'' and ''GroupDec'' used in steps '''8''' and '''14''' of Alogrithm 1 as a part of the protocol, as we do not specifies the Hash function and the block cipher. We explain their property here. We choose a candidate in section IX.4.

The ''GroupEnc'' and ''GroupDec'' functions are primitives which are called collectively by all instances involved in the session and are supposed to satisfies the following goal:

'''Definition''': Let <math>\mathcal{S} := \{U_1,...,U_n\}</math> and for each <math>i,j</math>, let <math>k_{i,j}</math> be a secret shared between and only between <math>U_i</math> and <math>U_j</math>. The goal of group <math>\mathcal{S}</math> is that:

# Each member of group <math>U_i</math> to generate and share a secret <math>z'_i</math> among the member of group ''G'' using public channel <math>\mathcal{C}</math>.

# <math>z'_i</math> remains unknown for any <math>\mathcal{A} \not \in G</math> eavesdropping the channel <math>\mathcal{C}</math>.

To this end each member <math>U_i</math> compute <math>z_i := GroupEnc(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,...,n\}, z'_i)</math> and broadcast <math>z_i</math> on <math>\mathcal{C}</math>. Later on when <math>U_i</math> receives all <math>z_j</math>. It recovers all secrets <math>z'_i</math> by computing <math>GroupDec(k_{i,j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,...,n\}, z_i)</math>.

===(n+1)sec key exchange vs original Flexible Group Key Exchange of [ACMP10]===

Although in higher level view of (n+1)sec we generalized the process of key exchange using ''GroupEnc''/''GroupDec'' abstraction, at lower level our choice of primitive for this functions make the group key computation processes of ''(n+1)sec'' and the original key exchange algorithm the same. Hence, the steps marked pink in Algorithm 1, only differ in from [ACMP10] but not in result.

(n+1)run a deniable mutual authentication protocol along side with the key exchange protocol, this results in communicating extra key confirmation data along side of other data exchanged during the course of running the protocol. As we will show in the proof, these data has effect on the usual run of the algorithm.

The only step that ''(n+1)sec'' runs differently compare to the original algorithm (beside generating extra data), is computation of mutual secret, between <math>U_i</math> and <math>U_j</math>. In original, algorithm it is simply <math>g^{x_i}{x_j}</math>. In ''(n+1)sec'', it is the triple DH secret <math>H({y_j}^{LSK_{U_i}},LPK_{U_j}^{x_i},y_j^{x_i})</math>. We will prove that this change does not compromise any of the protocol proprieties.

The main difference between the two key exchange algorithms is in the key used for signature. In original algorithm, parties use their long term private key to sign their contribution, while in ''(n+1)sec'' they use their ephemeral keys. However, because the ephemeral keys has been authenticated before used for verification, we prove that the authenticity of signatures in both algorithms are equivalent under CDH assumption.

==VIII.2 Chatroom Setup==

=== VIII.3 Join ===

Joining a chat involves two different procedures: the Join procedure, described in Algorithm [[''(n+1)sec''#Join|2]], which runs on the new participant’s instance, and an Accept New Participant Procedure, described in Algorithm [[''(n+1)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.

The new participant needs to authenticate everybody already in the room and hand them their ephemeral key. All the parties already in the room only need to authenticate the new participant and need to send to them their ephemeral DH key. These procedures are described in Algorithm 3 and 4. After initial authentication step, all parties follow the same procedure to initiate a new session following Algorithm 5.

==== Authentication Step for new Joining party====

'''Algorithm 3'''

|align="right"|Generate Triple Diffie-Hellman P2P keys

|align="center"|<math>k_{i,j} \leftarrow H({y_j}^{LSK_{U_i}},LPK{U_j}^{x_i},y_j^{x_i})</math>}}

|align="center"|Computation

|align="right"|Generate key confirmations

|align="center"|<math>kc_i \leftarrow ((U_1,H(k_{i,1}, U_1)),\dots,(U_n,H(k_{i,n}, U_n)))</math>}}

|align="center"|Computation

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.

|align="right"|Generate key confirmations

|align="center"|<math>kc_{i,j}\leftarrow (U_i,H(k_{i,j}, U_i)) </math>

|align="center"|Computation

After this step users will proceed to "initiate new session" using Algorithm 5.

==== Initiate new session ====

'''Algorithm 5'''

|align="right"|Compute Session Id

|align="center"|Computation

|align="right"| Cancel any pending request for establishing a session with the same Id

|align="center"|AxeNewSessionRequestTimer<math>(sid_i)</math>

|align="center"|Computation

|align="right"|Generate secret shares

|align="center"|<math>z'_i := \leftarrow (H(k_{i,j}, sid_i) \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\})</math>

|align="center"|Computation

|align="right" |Encrypt shares

|align="center"|<math>z_i \leftarrow GroupEnc(k_{~~i_j~~i,j} \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z')</math>

|align="center"|Computation

|align="center"|Broadcast

|align="right"| Receive other user(s)' key shares and confirmation of unauthenticated usersor Time out|align="center"|Wait to Receive (<math>~~\textrm{Receive} (~~U_j|z_j,\sigma_1,kc_{ji}) ~~\textrm{~~ </math> for } <math> U_j ~~\textrm{~~</math> unauthenticated}or Timeout by(2<math>\times</math>BROADCAST_LATENCY+INTERACTION_GRACE_INTERVAL, Drop inactive users, queue a new session request)

|align="center"|Receive

|align="right"|Check the validity of key confirmation of unauthenticated users|align="center"|<math>~~kc_i~~kc_j[jU_i] \stackrel{?}{=} H(k_{i,j,i}, ~~U_j~~U_i) ~~\textrm{~~ </math> for } unauthenticated <math> U_j ~~\textrm{unauthenticated}~~</math>

|align="center"|Computation

|align="right"|Check signatures

|align="center"|<math>Verify_{y_i}(\sigma_j) ~~\textrm{~~ </math> for } ''j \'' in \{1,~~\dots~~...,''n\''}~~</math>~~

|align="center"|Computation

|align="right"| Generate session key

|align="center"|<math>sk_{i,j} \leftarrow H(GroupDec(k_{i,jl}\forall l, z_j \; ) \forall j, sid_i)=H(z'_1, \dots, z'_n,sid_i)</math>|align="center"|Computation|-|align="right"| Broadcast session confirmation|align="center"|<math>(sc_{i} \leftarrow H(sk_i,U_i), sigma_i \leftarrow Sign_{x_i}(sc_{i}))</math>|align="center"|Broadcast|-|align="right"|Check the validity of session confirmation|align="center"|<math>H(sk_{i}, U_j) \stackrel{?}{=} sc_j \; \forall j \neq i</math>|align="center"|Receive|-|align="right"|Check signatures|align="center"|<math>Verify_{y_j}(\sigma_j) \; \forall j \neq i</math>

|align="center"|Computation

|align="right"| Initiate the TranscriptChain

|align="center"|<math>TrascriptChain^S_i[0] \leftarrow (sk^S_i, sid_i)</math>

|align="center"|Computation

|align="right"| Initiate the last_sender_seq_num array

|align="center"|<math>last\_sender\_seq\_num \leftarrow (0,...,0)</math>

|align="center"|Computation

|align="right"| Initiate the own_seq_num to 0

|align="center"|<math>own\_seq\_num \leftarrow 0 </math>

|align="center"|Computation

==== 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.

Consistency aspects of ''(n+1)sec'', 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's 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 ''(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.

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, ''(n+1)sec'' 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~~ 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

===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+1)sec''#Leave]].

====Farewell====

Run by exiting user.

|align="right"| Send farewell message

|align="center"|~~<math>~~Send("Leaving!")~~</math>~~

|align="center"|Broadcast

|align="right"| Wait to receive hashes of TranscriptChainor Timeout|align="center"|~~<math>~~Wait to Receive()or Timeout by((2 <math>\times</math>BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL)

|align="center"|Receive

====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.

Additionally, failure to receive a heartbeat from a user will result in executing Algorithm [[''(n+1)sec''#~~Leave~~Shrink]] excluding users who did not update their key.

'''Algorithm 7'''

|align="right"| Send Hash of TranscriptChain of last message seen by leaving user

|align="center"|Send(<math>~~Send(~~H(TranscriptChain^S_i[Parent(m_{farewell})]))</math>)

|align="center"|Broadcast

After the session key is established, participants will use Algorithms [[''(n+1)sec''#Send|5]] and [[''(n+1)sec''#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 has been received by the participant. This information is ~~need inorder~~ needed in order to enforce in-session forward secrecy. 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 seen 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. Those who have not updated their key shares eventually time out via their heartbeat interval.

====Send==== ~~Encrypted messages include a "hash of TranscriptChain" of their parent as "additional authenticated data".~~ ~~<math>(H(parent(m)), H(TransciptChain[parent(m)-1])))</math>~~ Note that we defined <math>H(parent(m))</math> rather than <math>H(m)</math>. This is because a hash may only be calculated once the subject is actually received back from the server (i.e. gets a sequence number). This differs from some other concepts of "message ID" that may be calculated locally.

'''Algorithm 8'''

!align="center"|Pseudo-code

!align="center"|Type

|align="right" | prepend session id and sender id

|align="center"|<math> m \leftarrow (sid, U_i, m) </math>

|align="center"|Computation

|align="right"| Generate new DH Key or new secret share if needed and append

|align="center"|Computation

|align="right"| Append the hash of the TranscriptChain, up to the parent of the message being sent

|align="center"|Computation

|align="right"| Sign the messageand append the signature|align="center"|<math>~~\sigma~~ m \leftarrow (m, Sign_{x_i}(m))</math>

|align="center"|Computation

|align="right"| Broadcast the message

|align="center"|<math>(sid_i, e~~, \sigma~~)</math>

|align="center"|Broadcast

|align="right"|Reset Heartbeat timeout timer

|align="center"|ResetHeartbeatTimer()

|align="center"|Computation

|align="right"|Set ACK timeout timer if the message has user content

|align="center"|<math>meta\_only \stackrel{?}=</math> False then ResetHeartbeatTimer()

|align="center"|Computation

!align="center"|Pseudo-code

!align="center"|Type

|align="right"| Decrypt message

|align="center"|<math> sid_{rec}, sender\_id, m, s, h, parent\_id, sender\_seq\_num, sigma \leftarrow Dec_k(m) </math>

|align="center"|Computation

|align="right"| Check signature

|align="center"|<math> ~~Verify~~Verify_{sender\_id}(m,\sigma) </math>

|align="center"|Computation

|align="right"| ~~Update TranscriptChain~~Compute message sequence number|align="center"|<math> ~~Insert~~seqnum(~~TranscriptChain^S,~~ m) \leftarrow </math>ComputeSeqNum(''m'')

|align="center"|Computation

|align="right"| ~~decrypt message~~Verify session id and transcript consistency and sender sequence number, issue a warning in case of failure|align="center"|<math> sid_i \stackrel{?}{=} sid_{rec}~~, s,~~ \; </math> and <math> \; h \stackrel{?}{=} H(H(parent(m)), h, H(TranscriptChain^S_i[parent~~\_id \leftarrow Dec_k~~(m) -1])) </math> and <math> sender\_seq\_num \stackrel{?}{>} last\_own\_seq\_nums[sender\_id] </math>

|align="center"|Computation

|align="right"| ~~Verify session id and transcript consistency, issue a warning in case of failure~~Update TranscriptChain if possible|align="center"|<math> ~~sid_i \stackrel{?}{=} sid_{rec} \; \textrm{and} \; h \stackrel{?}{~~TranscriptChain^S_i[seqnum(m)] =} (H~~(parent~~(m)), H(TranscriptChain^S_i[~~parent~~seqnum(m)-1])) </math>

|align="center"|Computation

|align="center"|<math>y_j \leftarrow s \; \textrm { or } \; z_{j} \leftarrow s</math>

|align="center"|Computation

|align="right"| If all users' share are received, generate session key

|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>|align="center"|Computation|-|align="right"| Update ack timeout timer|align="center"|AxeAckTimeoutTimer<math>(parent(m),sender_i)</math>|align="center"|Computation|-|align="right"| Update rekey timeout timer|align="center"| ResetRekeyTimeOut(<math>sender_i</math>)|align="center"|Computation|-|align="right"| If the message has content set up ACK timer|align="center"|<math>meta\_only \stackrel{?}= True</math> then <math>SetACKTimer(m)</math>

|align="center"|Computation

|align="right"| return m

|align="center"|If <math>meta\_only \stackrel{?}{=} False</math> then return ''m''|align="center"|Computation

==== Out of Session Send and Receive ====Due to nature of the key exchange algorithm, (n+1)sec support confidential P2P communication. This in particular enables the user to share the conversation with joining user(s) who confirmed their identity to the user but have not established a session yet. It is worth mentioning that every session keeps a ''list future sessions to transition to'' this is equivalent to the list of ''confirmed but yet to join users''. If the extension discussed in section VIII.3 is enabled it will make use of this list to implement the following changes:* When a user send a message ''Extended Send'' is invoked instead, it sends the message to the session using ''Send'' but also to the prospective participants, using ''P2P Send''.* When a message is received, ''Extended Receive'' is called which check if the user has the correct key to decrypt the message. If the message is encrypted by session key and user has the session key then it calls the normal receive. If the message is encrypted by a p2p key that the user share, it calls ''P2P Receive''. Otherwise, it simply ignores the message. '''Algorithm 9.1 Extended Send''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right" | If we are part of a session id in the room call ''Send''|align="center"| Send|align="center"| Broadcast|-|align="right"| For all confirmed users not in session call ''P2P Send''|align="center"| P2P Send|align="center"|Broadcast|} '''Algorithm 9.2 Extended Receive''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right" | If ''m'' has session id call ''Receive''|align="center"| if ''m'' has ''sid'' then Receive|align="center"| Computation|-|align="right"| If ''m'' has key id, call ''P2P Receive''|align="center"| P2P Send|align="center"|Computation|} '''Algorithm 9.3 P2P Send''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right" | Prepend key id and sender id|align="center"|<math> m \leftarrow (key\_id, U_i, m) </math>|align="center"|Computation|-|align="right" |Generate a random nonce and append to the message|align="center"|<math> m \leftarrow (m, rand(128bit)) </math>|align="center"|Computation|-|align="right"| Sign the message and append the signature|align="center"|<math> m \leftarrow (m, Sign_{x_i}(m))</math>|align="center"|Computation|-|align="right"|Encrypt|align="center"|<math>e \leftarrow Enc_{k_{key\_id}}(m)</math>|align="center"|Computation|-|align="right"| Broadcast the message|align="center"|<math>(key\_id, e)</math>|align="center"|Broadcast|} '''Algorithm 9.4 P2P Receive''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right"| Decrypt message|align="center"|<math> key_{id}, sender\_id, m, sigma \leftarrow Dec_{k_{key\_id}}(m) </math>|align="center"|Computation|-|align="right"| Check signature|align="center"|<math> Verify_{sender\_id}(m,\sigma) </math>|align="center"|Computation|-|align="right"| return m|align="center"|return ''m''|align="center"|Computation|} ==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.

|align="right"| Receive ''m'' with parent ''p'' from <math>\Pi^S_j</math>

|align="center"|<math> m \leftarrow seqnum(M), p \leftarrow parentnum(m)</math>

|align="center"|Computation

|align="right"| Compare hash of TranscriptChain_j[p] with own value of it, issue a warning if it fails.

|align="center"|<math>H(TranscriptChain^S_j[p]) \stackrel{?}{== } H(TranscriptChain^S_i[p])~~</math> for all <math>U_k \in plist^S_i~~</math>

|align="center"|Computation

|align="right"| Compute TranscriptChain^S_i[m]

|align="center"|<math>plist \leftarrow [U_i]</math>

|align="center"|Computation

** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''

===VIII.7 ~~Heartbeat~~ In-session Forward Secrecy==To ensure forward secrecy in long living chat sessions, ''(n+1)sec'' provides a session key update throughout the session. Each message sent to the session by each participant contains meta data described in [[#VIII.5.1 (n+1)sec Message Structure]]. Prior to sending any message, ''(n+1)sec'' determines the content of meta data, and piggy backs to that message according to the following algorithm: '''Algorithm 10.1 Compute meta data''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right"| Initiate meta data with current state of knowledge of new ephemeral keys and secret shares|align="center"|<math> meta\_data \leftarrow ustate_i[j]</math> for all ''j'' in {1,...''n}|align="center"|Computation|-|align="right"| Include the new ephemeral key if participant <math>U_j</math> has not receive it|align="center"|If <math>ustate_i[j] \stackrel{?}{=} 0</math> ''meta_data'' \leftarrow <math>y_{i_{new}}</math>|align="center"|Computation|-|align="right"| If (all) participants have sent their ephemeral keys compute the shared secret|align="center"|If <math>ustate_{j}[i] \stackrel{?}{=} 1</math> for all ''j''in {1,...''n}, then <math> meta\_data \leftarrow (meta\_data, GroupEnc(k_{i_j} \, \textrm{for} \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z'))</math>|align="center"|Computation|-|align="right"| Return meta data|align="center"|return ''meta_data''|align="center"|Computation|} ==VIII.8 Heartbeat and Timeout ==

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.

* REKEY_GRACE_INTERVAL, to ensure in session forward secrecy, the protocol requires that each <math>U_i</math> updates their DH ephemeral key as well as group key. After a session is established or it was rekeyed, each <math>\Pi^S_i</math> needs to send its new DH ephemeral key no later than REKEY_GRACE_INTERVAL. Therefore if <math>\Pi^S_i</math> has not sent any message by that

period of time, it issues an empty message. Similarly after receiving all ephemeral keys from all participants, <math>\Pi^S_i</math> needs to send its secret for computation of new key no later than REKEY_GRACE_INTERVAL.

* INTERACTION_GRACE_INTERVAL, to ensure establishment of a session in timely manner, when immediate contribution of participants is required (for example sending key confirmation, contribution to the session secret), this values indicate that how long an active participants should wait till it decide to drop the non-contributing inactive participants from the participant list.

* 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.

When a new session key is computed as well as when <math>\Pi^S_i</math> receives new ephemeral DH values from all users, a timer of (2*BROADCAST_LATENCY)+REKEY_GRACE_INTERVAL) period is set. It is cancelled when all user contributions are received (ephemeral keys or session key secrets). Otherwise, the <math>\Pi^S_i</math> excludes users who failed to contribute from the <math>plist</math> ~~and request a call for leave procedure to~~ exclude those users from the plist and call '''initiate new session'''. This measure is taken to ensure that users do not block in-session forward secrecy due to loss of connection or being under attack. === Timing out during an interactive session === ''(n+1)sec'' by design assumes the participants are trusted in being commited to the goal fo creating a secure chatroom. In this sense, ''(n+1)sec'' provide little defens against party which trying to sabotage a room by mounting various denial of service approaches. However, there are situation where a party is genuinely affected (by external adversary) or by connection problem. Under such assumption, situations we expect that all other parties, reach a consensus, that a participant has connectivity problem and agree on leave them out of the room. Timeout sub protocol is designed to deal with such a situation. When a new session is requested (for join, leave, etc) each participant wait for (2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, they omit non-participating participants from the plist, and wait for PLIST_UPDATE_GRACE_INTERVAL. so other participants also reach to the same conclusion and updates their plists, then they initiate a new session. === Drop inactive users, queue a new session request ==='''Algorithm 10.XX''' {| border="1" cellspacing="0" cellpadding="5" align="center"!align="right"|Description!align="center"|Pseudo-code!align="center"|Type|-|align="right"| Drop inactive users|align="center"|<math> plist_i \leftarrow plist_i \backslash inactive\_participant\_list</math>|align="center"|Computation|-|align="right"| Recompute Session Id|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_{n_{active}}|y_{n_{active}})</math>|align="center"|Computation|-|align="right"| Set up timer to request a new session|align="center"|SetTimer(PLIST_UPDATE_GRACE_INTERVAL, initiate new session)|align="center"|Computation|} When a participant receives a request for initiating new session, it checks their most current view of participant list (the one with eliminated timed out users) and if it matched then they go ahead with initiating the session, otherwise decline halt the request. ==VIII.9 (n+1)sec Message Dictionary== All (n+1)sec messages have the following format :o3np1sec:Base64EnocodedMessage The Base64EncodedMessage is decoded to sub data fields. There is no delimiter, the fields can be split based on the data size. We use commas (',') only for the purposes of readability in this document. The data types are described as follows. Bytes (DTByte): 1 byte unsigned valueShorts (DTSHort): 2 byte unsigned value, big-endianLength (DTLength): 4 byte unsigned value, big-endianHashBlock (DTHash): 32 byte dataOpaque variable-length data (DTOpaque): 4 byte unsigned len, big-endian len byte data All messages have mandatory version and message type fields: version (DTShort), message type (DTShort), type-specific part "version" is equal to 0001. "message type" is chosen from the following list: UNKNOWN =0x00, //Invalid JOIN_REQUEST =0x0a, //Session establishement PARTICIPANTS_INFO =0x0b, JOINER_AUTH =0x0c, GROUP_SHARE =0x0d, SESSION_CONFIRMATION =0x0e, //In session messages IN_SESSION_MESSAGE =0x10, P2P_MESSAGE =0x20, many messages use "participant id" which is defined as follows: participant nickname, participant fingerprint (DTHash) participant nickname is a string. Its size can be determined by the length of the participant id - 32. The participant finger print is a 32bit representation of an ed25519 public key. "participant info" is defined as participant id, ephemeral public key (DTHash), authenticated (DTByte) From the point of view of the sender of the message the participant is authenticated if "authenticated" is 1. Unauthenticated if it is 0. The following sections will describe the type-specific part for each type of messagee information about the joiner. ===Join Request=== participant_info where the following fields from participant_info submessage: participant id, ephemeral publick key (DTHash) are representing the joiner's information. the authenticated (DTByte) is kept only for compatibility with participant_info sub message structure and has no information value. It should be 1 as it represents the state of authentication of the joiner to itself. However, its value will be ignored by the current participants. ===Participant Info=== session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash) "session view" consists of participant0_info (DTOpeque), participant1_info (DTOpeque), ..., partcipantn_info(DTOpeque) where "participant0,...,participantn" are all participants in the session (represented by session id). "key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user. the sender's share is computed as described in the algorithm. ===Joiner Auth=== session id (DTHash), key_confirmation (DTOpeque), signature "key confirmation" consists of a hash of a triple dh token between the sender and the joining participant and the "participant id" of the joining user. ===Group Share=== session id (DTHash), sender share (DTHash), signature (DTHash) ===Session Confirmation=== session id (DTHash), session confirmation (DTHash), next session ephemeral key (DTHash) "session confirmation" is a hash(Session key|sender nickname), the next session ephemeral key is the 32 byte public key that the user is going to use in the next session. ===(n+1)sec in session Message Structure=== Every (n+1)sec message sent after establishment of a session has the following format: :o3np1sec:Base64EnocodedMessage The message has the following structure. sid (DTHash), Encrypted part of the message, Signature (DTHashx2) Encrypted message can be decrypted by the session key sender_index (DTLength), own_sender_id (DTLength), parent_id (DTLength), hash of TranscriptChain of the message (DTHash), nonce (DTHash), message load "session ID" and the "sender_index" are prepended in part to address concerns of [Da01]. "own_sender_id" is the sequential id assigned to each message by its sender, used for transcript consistency check. "parent_id" is the global sequential id of the last message seen by the sender before sending the message. The message also includes the "hash of TranscriptChain" of the parent of the message as "additional authenticated data". <math>H(TransciptChain[parent(m)])</math> Note that we send the entry in the chain indexed by <math>parent(m)</math> rather than <math>m</math>. This is because a hash may only be calculated once the subject is actually received back from the server (i.e. gets a sequence number). This differs from some other concepts of "message ID" that may be calculated locally. "nonce" is a random 128 bit value, appended to prevent any possibility of replay or brute force attack. "message load" is a multi-field message and has the following structure: sub_message_type(DTShort) sub_message(DTOpeque) [Optional] current sub message types are: USER_MESSAGE: 0001 follewed by the plain text typed by user and handled to (n+1)sec by the chat client(DTOpaque) LEAVE_MESSAGE 0002 followed by nothing. If there is no message load, then the message is just an ack, acknowledging receipt of other messages. ===(n+1)sec P2P Message Structure=== Every p2p (n+1)sec message sent after exchange of the ephemeral public keys has the following format. :o3np1sec:Base64EnocodedMessage The Base64EncodedMessage is decoded as: version (DTShort), sid (DTHash), Encrypted part of the message, Signature (DTHashx2) keyid, Encrypted part of the message, Signature Encrypted message can be decrypted by the p2p key and has the following structure Signed Message consists of following parts keyid, sender id, received id, nonce, User message, The "Key ID" and the "sender ID" are prepended in part to address concerns of [Da02]. The nonce is a random 128 bit value, appended to prevent any possibility of replay or brute force attack. User message is the plain text typed by user and handled to (n+1)sec by the chat client. ==VIII.10 (n+1)sec Session Management and Message Handling==(n+1)sec secure conversations are modeled as chat sessions with proven cryptographic properties. A chat session starts with participants run the key agreement protocol and then agree and confirm a shared key. However, the process on how a joining and leaving participants trigger a new chat sessions and how participants need to respond to multiple simultanous joins and leaves requests and the process of establishing multiple chat sessions is managed by (n+1)sec Session Management protocol. This protocol is work in progress to deal with unresponsive participants and those who denial their response to bar the establishment of a session. This section explains the rules - based on which - (n+1)sec currently governs the order when multiple participants try to join or leave a session simultaneously. Every participant in a chat room has either the status of a "joiner" or a "confirmed participant" of a (confirmed) session exclusively. Based on the user status and the message received, a specific subprotocol needs to be run by the user which is explained in the following sections. '''FSM message handling''': The basic rule is that if the message has a session id of a session that the user is part of, then message handling is governed by the finite state machine table described below. Otherwise, the messages should be handled as follows, for users of joiner or confirmed participant status: ===Joiner=== In current (n+1)sec implementation, this state is implemented as: user_in_room_state == JOINING * Messages without session id (including JOIN_REQUEST): The Joiner, user in "JOINIG" state will ignores all messages without session id. * If the message has a session id which the joiner has not constructed a session - the joiner will react as follows based on the typ of the message: ** '''Participant Info''': *** If the joiner is mentioned in the participant list, the joiner construct a session with that list. The session will be at the state of JOIN_REQUESTED.*** If the joiner is not mentioned in the plist, the joiner ignores the message (Suggestion: Should the joiner begins a session by appending itself to the list?). ** '''Session Confirmation''': The joiner will mark all its sessions as DEAD and wait for the new participant list (*** should joiner send a new join request?). If the message has session id corresponding to a session that the joiner already constructed (and is in process of joining, i.e. is not DEAD), then the session FSM will deal with the message, as stated above. ===Confirmed Participant=== This state is indicated as follows in the current implementation of (n+1)sec: user_in_room_state == CURRENT_USER The confirmed participant is a member of a unique session in state of IN_SESSION. This session is indicated as '''active_session'''. All messages participants sends to the room is going to such session. The participant also keeps an indicator named as '''next_in_activation_line'''. Both indicators are pointing to the active_session at the point when the active_session moves to IN_SESSION state. * If the received message has a session id and the participant has constructed a session corresponding to that message. Then the FSM treats the message. * If the received message has a session id, but the confirmed participant does not have a session is not part of the session then the participant will ignore the message, unless the message is of PARTICIPANT_INFO. * If the received message is of PARTICIPANT_INFO for which, the user doesn't have corresponding session then the FSM of next_in_activation_line session will treat the session. For the definition of next_in_activation_line. * If the received message does not have a session id, then it is a JOIN_REQUEST (otherwise marked as invalid). The FSM of next_in_activation_line will treat the session. ===Session transition=== Each confirmed participant (user_in_room_state == CURRENT_USER) keeps to indicators: * '''active_session''' The active_session is the only session which is in IN_SESSION state. A session state moves to IN_SESSION when the user receives session confirmation from all participants. In that case the previously active session state will be DEAD. When a new session get activated, all STALE sessions gets refreshed. That is, all sessions which were requested to be created (due to join or leave) during the creation of the newly active session, will be recreated according to the new participant list. Further more, the next_in_activation_line also points to the newly activated session. * '''next_in_activation_line''' next_in_activation_line is the session which receives requests for new session (join/leave). When new session is activated it also become next_in_activation_line. When a new priority session is constructed it takes the next_in_activation_line pointer. If there is no priority session, then the first session which gets it share key generated becomes the next in activtion. When a user leaves while another user trys to join, the leave protocol will take priority and a new participant info message is sent to the joining user after all leaving users have left. In this case, the session with leaving participant removed becomes the '''next_in_activation_line''' and all live sessions (not DEAD) (beside the active_session) will be marked as stale. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. That's the session will become the next_in_activation_line, and all live sessions (beside the active_session will bemarked as stale. When the next_in_activation_line session is confirmed and moves to IN_SESSION, the active_session moves to DEAD state. For each stale session, a new participant info list will be generated of the union of the participant in new active session and the participant in the stale session bar the users which left during in process of active_session establishment. The participants info message will be sent to the remaining joining users. Joining user (user_in_room_state == JOINING) does not keep any indicator. ===Finite State Table=== The sesseion finte state machine react based on the following table. A joiner will start a new session with JOIN_REQUESTED after it sends its join request. {| class="wikitable"|-! State/Message !! JOIN_REQUEST !! PARTICIPANTS_INFO !! JOINER_AUTH !! GROUP_SHARE !! SESSION_CONFIRMATION !! IN_SESSION_MESSAGE |-| JOIN_REQUESTED || || authenticate and send share || || || || |-| RE_SHARED || init a stale session with new user || authenticate and store share || authenticate and store share || authenticate and store share || || |-| GROUP_KEY_GENERATED || init a stale session with new user || || || || mark confirmed and may move session || |-| IN_SESSION || init a session with new user || || || || || receive |-| STALE || || || || || || |-| DEAD || || || || || || receive |} If a message is received when there is no handler it will be ignored. ====Explaniantion of the handlers==== * '''authenticate and send share''' called by the joiner, computes authentication token with each of the participants and the user share of the session key and send a JOINER_AUTH Message. Beside generating share it acts like '''authenticate and store share'''. * '''authenticate and store share''' validate the authentication token and store the sent share. If everybody is authenticated and all shares are received, compute the session key and the session confirmation and send of SESSION_CONFIRMATION message. In that case, the session state will be changed to GROUP_KEY GENERATED. Otherwise stays unchanged. If the received PARTICIPANTS_INFO message does not corresponds to the session, it create a new session for that list in stale state. In that case, the state of the receiving session stays unchanged. * '''confirm and may move session'''it validate the session confirmation. If all the participant is confirmed the state will change to IN_SESSION. joiner become confirmed participant. Otherwise it does not change the state of the session. * '''init a session with new user'''When a confirmed participant receive this message start a new session with the joiner added to it. The state of new session will be RE_SHARED. it does not change the state of the session. * '''init a stale session with new user'''It creates a new session with the joiner added to it. The state of new session will be STALE. it does not change the state of the session.

= '''IX Cryptographic Primitives''' =

==IX.2 Message Origin Authentication ==

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

==IX.3 Message Encryption ==

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 forgeability (although the whole transcript is forgeable), it is not prohibitive to use the same key for encryption and authentication.

~~==IX.4 GroupEnc and GroupDec Functions ==~~The ~~''GroupEnc''~~ added authentication, spares P@P send and ~~''GroupDec'' functions are primitives which are supposed to satisfies the following goal:~~receive routines from using digital signature.

~~'''Definition''': Let <math>\mathcal{S} := \{U_1~~With GCM mode,~~...,U_n\}</math>~~ the authenticated encryption is generically secure by the result (and ~~for each <math>i,j</math>, let <math>k_{i,j}</math> be a secret shared between and only between <math>U_i</math> and <math>U_j</math>~~assumptions) of [Kr00]. ~~The goal of group <math>\mathcal{S}</math> is that:~~

~~# Each member of group <math>U_i</math> to generate~~ ==IX.4 GroupEnc and ~~share a secret <math>z~~GroupDec Functions ==The '~~_i</math> among the member of group~~ 'GroupEnc'G'and ' ~~using public channel <math>\mathcal{C}</math>.# <math>z~~'~~_i</math> remains unknown for any <math>\mathcal{A} \not \~~GroupDec'' functions defined in ~~G</math> eavesdropping the channel <math>\mathcal{C}</math>~~Section VIII. ~~To this end each member <math>U_i</math> compute <math>z_i := GroupEnc(k_{i,j} for j \in \{~~1,~~...,n\}, z'_i~~facilitate the collective generation of a secret(s)~~</math> and broadcast <math>z_i</math> on <math>\mathcal{C}</math>. Later on when <math>U_i</math> receives all <math>z_j</math>. It recovers all secrets <math>z'_i</math>~~ shared by ~~computing <math>GroupDec(k_{i,j} for j \in \{1,~~the group.~~..,n\}, z'_i)</math>.~~ Here we mention two examples of such functions, and specify the functions for ''(n+1)sec' protocol:

* '''Naive peer-to-peer GroupEnc/Dec''':

This document is the first public draft of the ''(n+1)sec'' protocol. We are genuinely hoping to receive a lot of feedback and review on this work and have chosen the wiki format to support [[Talk:Nsec|Discussion]]. Ongoing tasks for the team include mathematical proofs of resistance to the adversarial model presented herein as well as technical implementation details. This is currently scheduled for the end of December, 2014. The [https://github.com/equalitie/np1sec np1sec] software library will be initially implemented in [https://github.com/cryptocat/cryptocat/ Cryptocat] and (with your help) further developed to suit a variety of use-cases in the near future.

= XI. Acknowledgements=The eQualit.ie team would like to give special thanks and note to the effort and dedication offered by Trevor Perrin and Ximin Luo to this project. They have been actively involved throughout the year and the result would not have been the same without their contribution. The team would also like to express thanks to Joseph Bonneau for ~~....~~his constructive comment and critisim to improve the protocol and its presentation. George Kadianakis for ~~his....~~ helping with the security proof and pointing out flaws and attack; Arlo Breault for his work on implementation of the protocol in the [https://github.com/equalitie/np1sec np1sec] software library; David Goulet for valuable advice as well as continued assistance and support offered to the project; Prof. ~~Finally~~Payman Mohassel for his help and advice on the security model and the proof; Prof. Jermey Clark, Prof. Matthew Green and Frederic Jacobs for their constructive participation in the design debates; Prof. Mark Manulis for suggesting the GKA. eQualit.ie expresses gratitude to Nadim Kobeissi, Cryptocat founder and developer who initiated the project and for sharing his experience and giving advice on secure browser based chat. Last but not least we would like to thank the Open Technology Fund for supporting itthe project.

= XII. References =

[*ACMP10] Michel Abdalla, Céline Chevalier, Mark Manulis, and David Pointcheval. “Flexible Group Key Exchange with on-Demand Computation of Subgroup Keys.” In ''Third African International Conference on Cryptology (AfricaCrypt ’10)'', edited by Dan Bernstein and Tanja Lange, 6055:351–368. LNCS. Stellenbosch, South Africa, 2010: Springer~~. doi:[http://dx.doi.org/10.1007/978-3-642-12678-9_21 10.1007/978-3-642-12678-9_21]~~.

[*~~BS07~~Be11]~~Bohli~~Bernstein, ~~Jens-Matthias, and Rainer Steinwandt. 2007. “Deniable Group Key Agreement~~Daniel J.~~” In ''VIETCRYPT''~~; Duif, ~~edited by Phong Q. Nguyen~~Niels; Lange, ~~4341:298–311~~Tanja; Schwabe, Peter; Yang, Bo-Yin. ~~Lecture Notes in Computer Science. Springer~~"High-Speed High-Security Signatures. ","CHES","978-3-642-23950-2","http://dblp.uni-trier.de/db/conf/~~vietcrypt~~ches/~~vietcrypt2006~~ches2011.html#~~BohliS06~~BernsteinDLSY11". 2011. pages: 124-142","6917","Lecture Notes in Computer Science","Springer".

[*~~BVS05~~BS07]Bohli, Jens-Matthias~~, Maria Isabel Gonzalez Vasco~~, and Rainer Steinwandt. ~~2005~~2007. ~~“Secure~~ “Deniable Group Key ~~Establishment Revisited~~Agreement.” In ''~~IACR Cryptology ePrint Archive~~VIETCRYPT'' ~~2005~~, edited by Phong Q. Nguyen, 4341: ~~395~~298–311. Lecture Notes in Computer Science. Springer. http://dblp.uni-trier.de/db/~~journals~~conf/~~iacr~~vietcrypt/~~iacr2005~~vietcrypt2006.html#~~BohliVS05a~~BohliS06.

[*BMBVS05]~~Bonneau~~Bohli, ~~Joseph~~Jens-Matthias, Maria Isabel Gonzalez Vasco, and ~~Andrew Morrison~~Rainer Steinwandt. ~~“Finite-State Security Analysis of OTR Version 2~~2005. “Secure Group Key Establishment Revisited.” ''IACR Cryptology ePrint Archive'' 2005: 395. http://~~www~~dblp.~~jbonneau~~uni-trier.~~com~~de/~~doc~~db/~~BM06-OTR_v2_analysis~~journals/iacr/iacr2005.html#BohliVS05a.~~pdf~~

[*~~BGB04~~BM] ~~Borisov~~Bonneau, ~~Nikita, Ian Goldberg~~Joseph, and ~~Eric Brewer~~Andrew Morrison. ~~2004. “Off~~“Finite-~~the-Record Communication, or, Why Not to Use PGP~~State Security Analysis of OTR Version 2.” ~~In ''Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society'', 77–84. WPES ’04. New York, NY, USA: ACM. doi:[~~http://dxwww.~~doi~~jbonneau.~~org~~com/~~10.1145~~doc/~~1029179.1029200 10.1145/1029179.1029200]. http://doi.acm.org/10.1145/1029179.1029200~~BM06-OTR_v2_analysis.pdf

[*~~BCGNP08~~BGB04] ~~Colin Boyd~~Borisov, ~~Yvonne Cliff~~Nikita, ~~Juan Gonzalez Nieto~~Ian Goldberg, and ~~KennethG~~Eric Brewer.~~ Paterson~~2004. ~~2008. “Efficient One~~“Off-~~Round Key Exchange in~~ the ~~Standard Model~~-Record Communication, or, Why Not to Use PGP.” In ''~~Information Security and~~ Proceedings of the 2004 ACM Workshop on Privacyin the Electronic Society'', ~~edited by Yi Mu~~77–84. WPES ’04. New York, ~~Willy Susilo~~NY, ~~and Jennifer Seberry, 5107:69–83. Lecture Notes in Computer Science. Springer Berlin Heidelberg. http://dx.doi.org/10.1007/978-3-540-70500-0_6.~~USA

[*~~BCP01~~BCGNP08] ~~Emmanuel Bresson~~Colin Boyd, Yvonne Cliff, ~~Olivier Chevassut~~Juan Gonzalez Nieto, and ~~David Pointcheval~~KennethG. ~~2001~~ Paterson. ~~“Provably Authenticated Group Diffie~~2008. “Efficient One-~~Hellman~~ Round Key Exchange - in the ~~Dynamic Case~~Standard Model.” In ''~~Advances in Cryptology - Proceedings of ASIACRYPT ’01~~Information Security and Privacy'', edited by ~~Colin Boyd~~Yi Mu, ~~2248~~Willy Susilo, and Jennifer Seberry, 5107:~~290–309~~69–83. ~~LNCS~~Lecture Notes in Computer Science. ~~Gold Coast, Australia:~~ Springer~~. doi:[http://dx.doi.org/10.1007/3-540-45682-1_18 10.1007/3-540-45682-1_18]~~Berlin Heidelberg.

[*BoMa10] Boyd, Colin; Mathuria, Anish. "Protocols for Authentication and Key Establishment","3642077161, 9783642077166",2010, Springer Publishing Company, Incorporated, 1st edition [*BCP01] Emmanuel Bresson, Olivier Chevassut, and David Pointcheval. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange - the Dynamic Case.” In ''Advances in Cryptology - Proceedings of ASIACRYPT ’01'', edited by Colin Boyd, 2248:290–309. LNCS. Gold Coast, Australia: Springer. [*BCPQ01] Emmanuel Bresson, Olivier Chevassut, David Pointcheval, and Jean-Jacques Quisquater. 2001. “Provably Authenticated Group Diffie-Hellman Key Exchange.” In ''Proceedings of the 8th ACM Conference on Computer and Communications Security (CCS ’01)'', edited by Mike Reiter, 255–264. Philadelphia, Pennsylvania~~: ACM Press. doi:[http://dx.doi.org/10.1145/501983.502018 10.1145/501983.502018]~~.

[*CaKr01] Ran Canetti, Hugo Krawczyk. 2001. “Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels” “EUROCRYPT Conference. Lecture Notes in Computer Science”. Edited by Birgit Pfitzmann.

[*ChMa10] Qingfeng Cheng, Chuangui Ma, "Security Weakness of Flexible Group Key Exchange with On-Demand Computation of Subgroup Keys", CoRR, 2010, http://arxiv.org/abs/1008.1221

[*Da14] George Danezis, Should Group Key Agreement be Symmetric and Contributory, http://conspicuouschatter.wordpress.com/2014/06/28/should-group-key-agreement-be-symmetric-and-contributory/

[*Da02] Davis, Don,"Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML.","USENIX Annual Technical Conference, General Track","1-880446-09-X","http://dblp.uni-trier.de/db/conf/usenix/usenix2001g.html#Davis01","2002-09-022001", page 65-78 [*GUVGC09] Ian Goldberg, Berkant Ustao\uglu, Matthew D. Van Gundy, and Hao Chen. 2009. “Multi-Party Off-the-Record Messaging.” In ''Proceedings of the 16th ACM Conference on Computer and Communications Security'', 358–368. CCS ’09. New York, NY, USA: ACM~~. doi:[http://dx.doi.org/10.1145/1653662.1653705 10.1145/1653662.1653705]. http://doi.acm.org/10.1145/1653662.1653705~~.

[*GBN10] M. Choudary Gorantla, Colin Boyd, and Juan Manuel González Nieto. 2010. ''One Round Group Key Exchange with Forward Security in the Standard Model''. http://eprint.iacr.org/2010/083.pdf

[*GBNM11] M. Choudary Gorantla, Colin Boyd, Juan Manuel González Nieto, and Mark Manulis. 2011. “Modeling Key Compromise Impersonation Attacks on Group Key Exchange Protocols.” ''ACM Trans. Inf. Syst. Secur.~~'' 14 (4): 28.http://dl.acm.org/citation.cfm?id=2043628.2043629~~

[*Gun13a] Matthew Van Gundy. April 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.”

[*Gun13b] Matthew Van Gundy March 2013. “[OTR-dev] Improved Deniable Signature Key Exchange for mpOTR.”

http://lists.cypherpunks.ca/pipermail/otr-dev/2013-March/001676.html.

[*Kr00], "Krawczyk, Hugo","The order of encryption and authentication for protecting communications (Or: how secure is SSL?), 2001, Published: Cryptology ePrint Archive, Report 2001/045 http://eprint.iacr.org/

[*KPW13] Hugo Krawczyk and Kenneth G. Paterson, Hoeteck Wee. 2013. “On the Security of the TLS Protocol: A Systematic Analysis” in

''IACR Cryptology ePrint Archive''.

[*LVH13] Liu, Hong; Vasserman, Eugene Y.; Hopper, Nicholas. "Improved Group Off-the-record Messaging" from the ''Proceedings of the 12th ACM Workshop on Workshop on Privacy in the Electronic Society'', 978-1-4503-2485-4, 'ACM', New York, NY, USA. 2013

[*Mo13] Marlinspike, Moxie,"Simplifying OTR deniability" blogpost, Open Whispersystems, https://whispersystems.org/blog/simplifying-otr-deniability/

[*Sys14] Marlinspike, Moxie et al. Whisper Systems. 2014. “TextSecure ProtocolV2.” Accessed March 2. https://github.com/WhisperSystems/TextSecure/wiki/ProtocolV2.

[*RGK05] Mario Di Raimondo, Rosario Gennaro, and Hugo Krawczyk. 2005. “Secure Off-the-Record Messaging.” In ''WPES'', 81–89. Alexandria, VA, USA. http://dl.acm.org/citation.cfm?doid=1102199.1102216

[*~~Sys14~~KiSo00] ~~Whisper Systems~~Song, Boyeon; Kim, Kwangjo, "Two-Pass Authenticated Key Agreement Protocol with Key Confirmation","Progress in Cryptology —INDOCRYPT 2000","978-3-540-41452-0","http://dx. ~~2014~~doi. ~~“TextSecure ProtocolV2~~org/10.~~” Accessed March 2~~1007/3-540-44495-5_21","2000"; "237-249",1977 "Lecture Notes in Computer Science",Springer Berlin Heidelber. [*Git11] https://github.com/~~WhisperSystems~~hellais/~~TextSecure/wiki/ProtocolV2.~~cryptocat

</HarvardReferences>

We say a group key scheme (as defined in [[#V._Chat_Session_Model|Section V]]) is correct if all accepted instances of <math>\Pi^S_i</math> end up with the same participant lists <math>plist_i</math> and compute the same session id.

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.

Therefore, in the context of a chat room, broadcasting scheme participants do not have the same view of the room and consequently we cannot compute a unified session id <math>sid</math> based on the list of the participants (as opposed to the group key scheme). In a group key scheme, it is the name of the chat room plus a set of ephemeral keys and the set of ephemeral public keys which uniquely identifies the session. There are advantages and disadvantages to each of these schemes, which we enumerate here:

Based on the above differences, we selected a group key scheme for the proposed protocol. This is primarily because room consistency is one of the main security properties desired. However, when it is critical, the sub-protocol described by [[#Sending_and_receiving_messages_ while_joining_is_in_progress|Section VIII.2 Sending and receiving messages while joining is in progress]] allows for communication with users while they are waiting for the join procedure to complete.

===Participatory vs individually independent computation of group ~~keys~~key(s)===

Most AKGE offer some degree of contributiveness in computing the group secret. This roughly means that (at least in the absence of an insider) the group secret is derived using contribution from all members of the group. There has been criticism of the importance of this property such as in [Da14]. In this section we consider briefly the arguments for each side and describe the rational for our choice.

[[Category: np1sec]]

Vmon

Administrator

148

edits