Np1sec/concurrent join

Revision as of 15:53, 13 March 2015 by Vmon (Talk | contribs)

Proposal for concurrent join

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

each occupant can mark each session with one of the 5 status: {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. 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. dead: The session is abonden and not going to become 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 n+1sec protocol.

Session picking protocol for new user joining the room

New user start a join process by sending (U_{{joiner}},y_{{joiner}}). In respose, it receives messages of the format

sid,(U_{1},y_{1},...,U_{{joiner}},y_{{joiner}},...),kc_{{i}},z_{{i}}

From each user i. The joiner makes a session for each sid 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.

Session picking protocol for current occupant of the current session

Suppose user U_{i} is in Session S. When new user U_{j} send a join request, user U_{i} start a session in limbo S_{j} with the list of users in the current session plus the joining user. As a part of initiation of each session S_{j} the current user send a message of type:

sid,(U_{1},y_{1},...,U_{{joiner}},y_{{joiner}},...),kc_{{i}},z_{{i}}


If m users are joining that session concurrently, there are S_{1},...,S_{m} sessions in-limbo which are receiving shares and authentication messages.

If the U_{l} currently in room signal to leave the room a session S_{l} is created. Each session S_{j} results in creation of session S_{{j'}} with user U_{l} omitted. S_{j} is marked as dead.

User U_{i} 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 S_{j} results in new session S_{{j''}} to which U_{{joiner}} is added. previous "current" session becomes in-limbo.

in-limbo -> {in-limbo, dead, current} current -> in-limbo

Last modified on 13 March 2015, at 15:53