Latest revision as of 18:47, 2 December 2014

Group key scheme vs a broadcast scheme

We say a group key scheme (as defined in section ???), is correct if all accepted instances $\Pi_i$ ends up with the same participant lists $plist_i$ and compute the same session id..

In contrast, by a broadcast scheme we refer to a scheme where each participant is broadcasting a message to set of participants of their choice from a set of potential participants. Each participant will have its own different $plist_i$ which is able to broadcast too.

Therefore, in the context of a chat room, in a broadcasting scheme participants do not have the same view of the room and consequently we can not compute a unified session id $sid$ based on the list of the participants as opposed to the group key scheme. In a group key scheme, the name of the chat room, a set of ephemeral keys along side with the set of ephemeral public keys uniquely identifies the session. There benefits and disadvantages to each of such schemes which we enumerate here:

1. Chat room simulation: A group scheme simulate a normal chat room in absence of authentication adversary, where the participants all have the same view of who is in the chat room when they start talking. This is not the case in a broadcasting scheme as participants keeps different participant list. This is in conflict with the security assumption of authentication property of original proposal for mpOTR.

2. Consistency: in a group key exchange the consistency of participant list (and session id) is provided by the group key exchange protocol. In such a protocol, extra measures need to be taken only to assure transcript consistency, i.e. verification of the consistency of delivery and order of messages exchanged between participants. In a broadcast scheme, a new notion needs to be defined and enforced so a minimum consistency of a conversation could be simulated. For example, as broadcasting to a subset of potential participants is allowed, the notion needs to deal with a situation in which A receives the DH public key of B but wants to send a message to the "room" before it receives the DH keys of C.

3. Delayed join and leave: In a group scheme, till all participants confirm their identical view on a new participant list (due to a member joining or leaving the room), They need to assume the statuesque. This might delay a new participant from joining a chat or if no further measure is taken, enable a participant to deny join/leave for the whole group. While various mitigation is possible for such attacks (all summarized under denial of service umbrella term) they are not included in threat model considered in mpOTR protocol.

Based on above differences we decided to choose a group key scheme/broadcast scheme for the proposed protocol.