Np1sec/concurrent join - Revision history

Vmon at 16:33, 13 March 2015

2015-03-13T16:33:12Z

Maja: /* Session picking protocol for new user joining the room */

2015-03-13T16:26:31Z

‎Session picking protocol for new user joining the room

Maja: /* Session picking protocol for current occupant of the current session */

2015-03-13T16:25:19Z

‎Session picking protocol for current occupant of the current session

Maja: /* Proposal for concurrent join */

2015-03-13T16:24:17Z

‎Proposal for concurrent join

Maja: /* Proposal for concurrent join */

2015-03-13T16:23:12Z

‎Proposal for concurrent join

Vmon: No key confirmation

2015-03-13T15:56:04Z

No key confirmation

Vmon: Simplifies the protocol without involving confirmation

2015-03-13T15:53:42Z

Simplifies the protocol without involving confirmation

Vmon: First version

2015-02-12T18:42:00Z

First version

New page

=Proposal for concurrent join=

With having session key confirmation one can have following protocol to handle concurrent join.

Each session can have 5 status: {current, potentially next, next, admissible, inadmissible}.

==Session picking protocol for current occupant of the current session==
Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>Unew_j</math> send a join request, user <math>U_i</math> start an admissible session <math>S_j</math> with the list of authenticated participant in the room (not users in the session).

If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> admissible which are receiving shares and authentication messages.

Suppose <math>S_j</math> receives the mutual authentication of all new users in admissible session <math>S_j</math> that will become the potentially next session of <math>U_i</math>. <math>U_i</math> then sends the combined list of (authenticated) participants in <math>S_j</math>, <math>(U_1,y_1,...,Unew_m,ynew_m,...)</math> to the room intending for new users not in the list to see and to authenticate to, and to old user to signal its potentially next session. It tags <math>S_1,...,S_m</math> as inadmissible sessions.

When <math>U_i</math> receives all shares of potentially next session <math>S_j</math> and the authenticated list from all users from current session, they tag the session as next and send the session key confirmation of <math>S_j</math>. The session will not be tagged as inadmissible in case of new authenticated list, it just make new admissible session.

If user U_i receives another authenticated list from another <math>S_j'</math> then it tag <math>S_j</math> inadmissible as well and start an admissible session with <math>plist_{S_j'} \cup plist_{S_j}</math> as new admissible session waiting for authentication from new users.

If it receives key confirmation from all <math>U_l</math> in <math>(U_1,...,Unew_m,..)</math> then it will make <math>S_j</math> as current session and send messages to this session.

==Session picking protocol for new user joining the room==
When a joining user Unew_l receives a list of potential users which is not including them, it authenticate to U_i's which new user has not yet authenticated to, and compute new share for the new share list. When they have all shares and authentication for plist_j then they send the key confirmation and wait for all of key confirmation.

When they receive confirmation from every user in plist_j. They make it current session and start chatting.

admissible -> {inadmissible, potentially next}
potentially next ->{inadmissible, next}
next->{current}

current and inadmissible will be eventually discarded.

@@ Line 15: / Line 15: @@
 <math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. '''When a session receives all shares, it computes the session key becomes the current session.''' All other sessions can remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
+From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. When a session receives all shares, it computes the session key and becomes the current session. All other sessions can remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
 ==Session picking protocol for current occupant of the current session==
@@ Line 25: / Line 25: @@
 If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> sessions in-limbo which are receiving shares and authentication messages.
-'''If <math>U_l</math> currently in room signals to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in the creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead.'''
+If <math>U_l</math>, currently in the session, signals to leave the room, a new session <math>S_l</math> is created. Furthermore, each session <math>S_j</math> in-limbo which has <math>U_l</math> as participants, results in the creation of new session <math>S_{j'}</math> with user <math>U_l</math> omitted and <math>S_j</math> is marked as dead.
-The user <math>U_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. '''All other <math>S_j</math> results in new session <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.'''
+The user <math>U_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. All other <math>S_j</math> result in new sessions <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. Previous active (current) session of the room becomes in-limbo.
 in-limbo -> {in-limbo, dead, current}
 current -> in-limbo

@@ Line 15: / Line 15: @@
 <math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-'''From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. When a session receives all shares, it computes the session key becomes the current session.''' All other sessions can remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
+From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. '''When a session receives all shares, it computes the session key becomes the current session.''' All other sessions can remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
 ==Session picking protocol for current occupant of the current session==

@@ Line 25: / Line 25: @@
 If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> sessions in-limbo which are receiving shares and authentication messages.
-'''If the <math>U_l</math> currently in room signal to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in the creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead.'''
+'''If <math>U_l</math> currently in room signals to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in the creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead.'''
 The user <math>U_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. '''All other <math>S_j</math> results in new session <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.'''

@@ Line 5: / Line 5: @@
 Each occupant can mark each session with one of the '''5 statuses: {current, in-limbo, dead}'''
 '''current''': User messages are being encrypted and decrypted in the current session. The join request will be processed by this session.
-'''in-limbo''': A session which is receiving shares and confirmation, this session can potentially become the next session if it receives session confirmation from all users.
+'''in-limbo''': A session which is receiving shares and confirmations, this session can potentially become the next session if it receives session confirmation from all users.
 '''dead''': The session is abandoned and not going to become the current session.

@@ Line 1: / Line 1: @@
 =Proposal for concurrent join=
-One can have following protocol to handle concurrent join.
+One can have the following protocol to handle concurrent join.
-each occupant can mark each session with one of the 5 status: {current, in-limbo, dead}
+Each occupant can mark each session with one of the '''5 statuses: {current, in-limbo, dead}'''
-'''current''': User messages are being encrypted and decrypted in the current session. The join request will be process by this session.
+'''current''': User messages are being encrypted and decrypted in the current session. The join request will be processed by this session.
-'''in-limbo''': A session which is receiving shares and confirmation, this session can potentially become the next session if it receive session confirmation from all users.
+'''in-limbo''': A session which is receiving shares and confirmation, this session can potentially become the next session if it receives session confirmation from all users.
-'''dead''': The session is abonden and not going to become current session.
+'''dead''': The session is abandoned and not going to become the current session.
-The protocol join one user at the time but is greedy and non-blocking in respect to several concurrent joiner and eventually results in join of all new users as long as current users in the session cooperate with join process. The global order of messages is essential in for the protocol to succeed which is a transport assumption for <math>n+1sec</math> protocol.
+The protocol joins one user at a time but is greedy and non-blocking in respect to several concurrent joiners and eventually results in joins of all new users (as long as current users in the session cooperate with the join process). The global order of messages is essential for the protocol to succeed, which is a transport assumption for <math>n+1sec</math> protocol.
 ==Session picking protocol for new user joining the room==
-New user start a join process by sending <math>(U_{joiner}, y_{joiner})</math>. In respose, it receives messages of the format
+New user starts a join process by sending <math>(U_{joiner}, y_{joiner})</math>. In respose, it receives messages of the format
 <math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contain them as a participant, the user initiate a session and gather shares. When a session receives all shares it compute the session key becomes the current session. All other session can remains in limbo or get discarded based on the memory capacity of the implementation and security requirement.
+'''From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contains them as a participant, the user initiates a session and gathers shares. When a session receives all shares, it computes the session key becomes the current session.''' All other sessions can remain in limbo or get discarded based on the memory capacity of the implementation and security requirement.
 ==Session picking protocol for current occupant of the current session==
-Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>U_j</math> send a join request, user <math>U_i</math> start a session in limbo <math>S_j</math>  with the list of users in the current session plus the joining user. As a part of initiation of each session <math>S_j</math> the current user send a message of type:
+Suppose user <math>U_i</math> is in Session <math>S</math>. When a new user <math>U_j</math> sends a join request, the user <math>U_i</math> starts a session in limbo <math>S_j</math> with the list of users in the current session plus the joining user. As part of initiation of each session <math>S_j</math> the current user sends a message of type:
 <math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math>  sessions in-limbo which are receiving shares and authentication messages.
+If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> sessions in-limbo which are receiving shares and authentication messages.
-If the <math>U_l</math> currently in room signal to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead.
+'''If the <math>U_l</math> currently in room signal to leave the room a session <math>S_l</math> is created. Each session <math>S_j</math> results in the creation of session <math>S_{j'}</math> with user <math>U_l</math> omitted. <math>S_j</math> is marked as dead.'''
-User <math>U_i</math> send the shares and authentication token necessary for each session. The first session which receives all confirmation will become the main session, the joiner user of that session becomes the current session. All other <math>S_j</math> results in new session <math>S_{j''}</math> to which  <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.
+The user <math>U_i</math> sends the shares and authentication token necessary for each session. The first session which receives all confirmations will become the main session, and the joiner user of that session becomes the current session. '''All other <math>S_j</math> results in new session <math>S_{j''}</math> to which <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.'''
 in-limbo -> {in-limbo, dead, current}
 current -> in-limbo

@@ Line 3: / Line 3: @@
 With having session key confirmation one can have following protocol to handle concurrent join.
-Each session can have 5 status: {current, potentially next, next, admissible, inadmissible}.
+each occupant can mark each session with one of the 5 status: {current, in-limbo, dead}
-==Session picking protocol for current occupant of the current session==
+The protocol join one user at the time but is greedy and non-blocking in respect to several concurrent joiner and eventually results in join of all new users as long as current users in the session cooperate with join process. The global order of messages is essential in for the protocol to succeed which is a transport assumption for <math>n+1sec</math> protocol.
-Suppose user <math>U_i</math> is in Session <math>S</math>. When new user <math>Unew_j</math> send a join request, user <math>U_i</math> start an admissible session <math>S_j</math>  with the list of authenticated participant in the room (not users in the session).
-If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math> admissible which are receiving shares and authentication messages.
+==Session picking protocol for new user joining the room==
-Suppose <math>S_j</math> receives the mutual authentication of all new users in admissible session <math>S_j</math> that will become the potentially next session of <math>U_i</math>. <math>U_i</math> then sends the combined list of (authenticated) participants in <math>S_j</math>, <math>(U_1,y_1,...,Unew_m,ynew_m,...)</math> to the room intending for new users not in the list to see and to authenticate to, and to old user to signal its potentially next session. It tags <math>S_1,...,S_m</math> as inadmissible sessions.
+<math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-When <math>U_i</math> receives all shares of potentially next session <math>S_j</math> and the authenticated list from all users from current session, they tag the session as next and send the session key confirmation of <math>S_j</math>. The session will not be tagged as inadmissible in case of new authenticated list, it just make new admissible session.
+From each user <math>i</math>. The joiner makes a session for each <math>sid</math> which contain them as a participant, the user initiate a session and gather shares. When a session receives all shares it compute the session key becomes the current session. All other session can remains in limbo or get discarded based on the memory capacity of the implementation and security requirement.
-If user U_i receives another authenticated list from another <math>S_j'</math> then it tag <math>S_j</math> inadmissible as well and start an admissible session with <math>plist_{S_j'} \cup plist_{S_j}</math> as new admissible session waiting for authentication from new users.
+==Session picking protocol for current occupant of the current session==
-If it receives key confirmation from all <math>U_l</math> in <math>(U_1,...,Unew_m,..)</math> then it will make <math>S_j</math> as current session and send messages to this session.
+<math> sid, (U_1,y_1,...,U_{joiner},y_{joiner},...), kc_{i}, z_{i}</math>
-When they receive confirmation from every user in plist_j. They make it current session and start chatting.
+If <math>m</math> users are joining that session concurrently, there are <math>S_1,...,S_m</math>  sessions in-limbo which are receiving shares and authentication messages.
-admissible -> {inadmissible, potentially next}
+User <math>U_i</math> send the shares and authentication token necessary for each session. The first session which receives all confirmation will become the main session, the joiner user of that session becomes the current session. All other <math>S_j</math> results in new session <math>S_{j''}</math> to which  <math>U_{joiner}</math> is added. previous "current" session becomes in-limbo.
-potentially next ->{inadmissible, next}
-next->{current}
-current and inadmissible will be eventually discarded.
+in-limbo -> {in-limbo, dead, current}