Changes
/* Session Confirmation */
<span style="font-size:200%">I</span>n 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==
|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"|8
|align="right" |Encrypt shares
|align="center"|{{Font color|black|pink|<math>z_i \leftarrow GroupEnc(k_{i,j} \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z'_i)</math>}}
|align="center"|Computation
|-
|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"|12
|align="right"|Check signatures
|align="center"|<math>Verify_{y_iy_j}(\sigma_j) \; \forall j \neq i</math>
|align="center"|Computation
|-
|align="right"| Generate session key
|align="center"|{{Font color|black|pink|<math>sk_{i} \leftarrow H(GroupDec(k_{i,l} \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 on 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"|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}) \; \forall j \neq i</math>}}
|align="center"|Computation
|-
|align="center"| -
|align="center"|7
|align="right"|Receive and Check the validity of key confirmation|align="center"|<math>kc_j \stackrel{?}{=} H(k_{i,j,i}, U_i)</math>
|align="center"|Receive
|}
# <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]===
|}
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.
'''Algorithm 3'''
After this step joining user will proceed to "initiate new session" by Algorithm 5.
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.
After this step users will proceed to "initiate new session" using Algorithm 5.
'''Algorithm 5'''
|-
|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} \, \textrm{for } \, j \neq i \, \textrm{and} \, j \in \{1,\dots,n\}, z')</math>
|align="center"|Computation
|-
|align="center"|Receive
|-
|align="right"|Check the validity of key confirmation of unauthenticated users|align="center"|<math>kc_ikc_j[jU_i] \stackrel{?}{=} H(k_{i,j,i}, U_jU_i)</math> for unauthenticated <math> U_j</math>
|align="center"|Computation
|-
|align="right"| Generate session key
|align="center"|<math>sk_{i} \leftarrow H(GroupDec(k_{i,l} \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
|-
|}
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.
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
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]].
Run by exiting user.
|}
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.
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.
'''Algorithm 8'''
|align="center"|Computation
|-
|align="right" |Generate a random nuance nonce and append to the message
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math>
|align="center"|Computation
|align="center"|Computation
|-
|align="right" |Generate a random nuance nonce and append to the message
|align="center"|<math> m \leftarrow (m, rand(128bit)) </math>
|align="center"|Computation
|}
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.
** <math>\Pi^S_i</math> won't have a chance to reach consistency for the messages receives after ''p''
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:
|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
|-
|}
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.
* 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> 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.
''(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.
'''Algorithm 10.XX'''
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 value
Shorts (DTSHort):
2 byte unsigned value, big-endian
Length (DTLength):
4 byte unsigned value, big-endian
HashBlock (DTHash):
32 byte data
Opaque 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''' =
[*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/
