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'''

|}

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:

|}

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.

All (n+1)sec messages have the following format

The following sections will describe the type-specific part for each type of messagee information about the joiner.

participant_info

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.

session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash)

the sender's share is computed as described in the algorithm.

session id (DTHash), key_confirmation (DTOpeque), signature

session id (DTHash), sender share (DTHash), signature (DTHash)

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 32bit public key that the user is going to use in the next session.

Every (n+1)sec message sent after establishment of a session has the following format:

If there is no message load, then the message is just an ack, acknowledging receipt of other messages.

Every p2p (n+1)sec message sent after exchange of the ephemeral public keys has the following format.

User message is the plain text typed by user and handled to (n+1)sec by the chat client.

This section explains the rule - based on which - (n+1)sec 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 "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.

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:

In current (n+1)sec implementation, this state is implemented as:

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.

This state is indicated as follows in the current implementation of (n+1)sec:

* If the received message does not have a session id, then it is a JOIN_REQUEST then the FSM of next_in_activation_line will treat the session. For the definition of next_in_activation_line see Session Transmission section.

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.

If a message is received when there is no handler it will be ignored.

* '''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'''.

* '''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.

= '''IX Cryptographic Primitives''' =