Changes
ACMP10 vs (n+1)sec described
|align="center"|Computation
|}
===(n+1)nsec key exchange vs original Flexible Group Key Exchange of [ACMP10]===
Although in higher level view of (n+1)nsec 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==
|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
|}
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.
====(n+1)sec Message structureStructure====
Every (n+1)sec message sent after establishment of a session has the following format:
np1sec:3Base64EnocodedMessage:3
The Base64EncodedMessage is decoded as:
sid, Encrypted part of the message
Encrypted message can be decrypted by the session key and has the following structure
Signed message, Signature corresponding to the signed message
Signed Message consists of following parts
sid, sender ID, User message, meta message, hash of TranscriptChain of the message, naunce
The "session ID" and the "sender ID" are prepended in part to address concerns of [Da01]. The nuance is a random 128 bit value, appended to prevent any possibility of replay or brute force attack.
meta message contains a message has the following format
meta_only, ustate_1, ..., ustate_n, current_load
current_load = (load_flag, load) load_flag = 0 no load load_flag = 1 load contains new ephemeral public key from sender load_flag = 2 load contains new secret share from the sender
The message also include "hash of TranscriptChain" of parent of the message as "additional authenticated data".
<math>H(H(parent(m)), H(TransciptChain[parent(m)-1])))</math>
Note that we defined send the entry in the chain indexed by <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.
====Send====
|align="center"|<math>(sid_i, e)</math>
|align="center"|Broadcast
|-
|align="right"|Encrypt
|align="center"|<math>e \leftarrow Enc_{k_{sid}}(m)</math>
|align="center"|Computation
|-
|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="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"|<math>AxeAckTimeoutTimer(parent(m),sender_i)</math>
|align="center"|Computation
|-
|align="right"| Update rekey timeout timer
|align="center"|<math>ResetRekeyTimeOut(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{?}{=} return ''m''
|align="center"|
|}
|align="center"|Computation
|-
|align="right"| Compute TranscriptChain^S_i[m]??? THIS DOESN'T MAKE SENSE ???
|align="center"|<math>plist \leftarrow [U_i]</math>
|align="center"|Computation
