Changes
GroupEnc moved, interaction timeout added
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 ''recipientsreception'' of a the messageby the intended ''recipients''.
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.
Although computing a unified session key for all participant is possible, the protocol will compute ''n'' different keys each being used to decrypt the text received from the corresponding participant. In other words, Participant <math>U_i</math> uses key <math>sk_{i,i}</math> to encrypt data. Formally we consider a tuple of <math>sk^S_i := (sk^S_{i,1},sk^S_{i,2},...,sk^S_{i,n})</math> as a session key. This measure has been taken to facilitate the transition to a broadcast use-case where the protocol does not promise same <math>plist</math> for all participants and therefore, it is conceptually impossible to compute a unique key. For more information please see [[#Participatory_vs_individually_independent_computation_of_group_keys|Appendix B: Participatory vs individually independent computation of group keys]].
For 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"|Computation
|}
===''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 '''XX''' and '''XX''' as 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} for 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} for j \in \{1,...,n\}, z'_i)</math>.
===(n+1)nsec key exchange vs original Flexible Group Key Exchange of [ACMP10]===
|align="right"|Compute Session Id
|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_n|y_n)</math>
|align="center"|Computation
|-
|align="right"| Cancel any pending request for establishing a session with the same Id
|align="center"|<math>AxeAcNewSessionRequestTimer(sid_i)</math>
|align="center"|Computation
|-
|align="center"|Broadcast
|-
|align="right"| Receive other user(s)' key shares and confirmation of unauthenticated usersor Time out|align="center"|<math>Wait to \textrm{Receive} (U_j|z_j,\sigma_1,kc_{ji}) \textrm{ for } U_j \textrm{unauthenticated}or Timeout_by((2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL, Drop inactive users, queue a new session request)</math>
|align="center"|Receive
|-
|align="center"|Broadcast
|-
|align="right"| Wait to receive hashes of TranscriptChainor Timeout|align="center"|<math>Wait to Receive() or Timeout_by((2*BROADCAST_LATENCY)+INTERACTION_GRACE_INTERVAL)</math>
|align="center"|Receive
|}
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''#LeaveShrink]] excluding users who did not update their key.
'''Algorithm 7'''
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''
===VIII.7 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.
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''' {| 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"|Compute Session Id|align="center"|<math>sid_i \leftarrow H(U_1|y_1|\dots|U_n|y_n)</math>|align="center"|Computation|-|align="right"| Set up timer to request a new session|align="center"|<math> SetTimer(PLIST_UPDATE_GRACE_INTERVAL, \textrm{initiate new session})</math>b|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.
= '''IX Cryptographic Primitives''' =
We are using AES-256 in counter mode with a shared group key for message encryption, as suggested by the original OTR protocol.
==IX.4 GroupEnc and GroupDec Functions ==The ''GroupEnc'' and ''GroupDec'' functions are primitives which are supposed to satisfies the following goal: '''Definition''': Let <math>\mathcal{S} := \{U_1,..defined in Section VIII.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 facilitate the collective generation 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} for j \in \{1,...,n\}, z'_is)</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''':
