Changes

Np1sec

48 bytes removed, 3 years ago
/* VIII.4 Leave */
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]].
====Farewell====
Run by exiting user.
|}
====Shrink====
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.
====Send====
'''Algorithm 8'''
|}
===VIII.6 Reaching Consistency ===
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''
===VIII.7 In-session Forward Secrecy===
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:
|}
===VIII.8 Heartbeat and Timeout ===
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.
==== Failure to heartbeat and inactivity timers ====
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.
==== Timing out during an interactive session ====
''(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.
==== Drop inactive users, queue a new session request ====
'''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
The following sections will describe the type-specific part for each type of messagee information about the joiner.
=====Join Request=====
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.
=====Participant Info=====
session id (DTHash), session view (DTOpaque), key_confirmation(DTOpaque), sender's share(DTHash)
the sender's share is computed as described in the algorithm.
=====Joiner Auth=====
session id (DTHash), key_confirmation (DTOpeque), signature
=====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 32bit 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:
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.
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====
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:
=====Joiner=====
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.
=====Confirmed Participant=====
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.
===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. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list 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.
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'''.
* '''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.
 
 
=====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. When multiple users are joining, when the confirmed participant receives the first joiner auth, it will halt the protocol for other joining users. When the session is confirmed, the new participant info list will be sent to the remaining joining users.
 
Joining user (user_in_room_state == JOINING) does not keep any indicator.
= '''IX Cryptographic Primitives''' =