</div>
=AppendixAppendices=
==Appendix A: Asynchronous communication and Forward Secrecy==
As the assumption of having a continuous heartbeat might not be realistic in various asynchronous cases, implementations can assume specific deadlines for dropping users who did not communicate their new keys or shares.
==Appendix B: Other design possibilities==
During the process of designing ''(n)sec'' we have considered, and debated, other design possibilities which we will describe in this section along side our argument in favour of the choice we have made.
===Group Key Scheme vs Broadcast Scheme===
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. <!--In such protocol we define <math>plist_{union} := \cup{i \in {interested participants}} plist_i</math>.-->
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:
# Chat room simulation: A group scheme simulates a normal chat room in the absence of an 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 keep different participant lists. This is in conflict with the security assumptions of the authentication properties from the original proposal for ''(n)sec''.
# Consistency: In a group key exchange, the consistency of the 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 the transcript's 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 that a minimum consistency of a conversation can 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 key of C.
# Delayed join and leave: In a group scheme, until all participants confirm their identical view of a new participant list (due to a member joining or leaving the room), they need to assume the status quo. 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 methods are possible against such attacks (all summarized under the umbrella term "Denial of Service" ) they are not included in threat model considered in ''(n)sec'' protocol.
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|VI.II.2b]] allows for communication with users while they are waiting for the join procedure to complete.
===Participatory vs individually independent computation of group keys===
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: nsec]]