Difference between revisions of "Np1sec/concurrent join"

(First version)
(No difference)

Revision as of 18:42, 12 February 2015

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 U_{i} is in Session S. When new user Unew_{j} send a join request, user U_{i} start an admissible session S_{j} with the list of authenticated participant in the room (not users in the session).

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

Suppose S_{j} receives the mutual authentication of all new users in admissible session S_{j} that will become the potentially next session of U_{i}. U_{i} then sends the combined list of (authenticated) participants in S_{j}, (U_{1},y_{1},...,Unew_{m},ynew_{m},...) 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 S_{1},...,S_{m} as inadmissible sessions.

When U_{i} receives all shares of potentially next session S_{j} and the authenticated list from all users from current session, they tag the session as next and send the session key confirmation of S_{j}. 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 S_{j}' then it tag S_{j} inadmissible as well and start an admissible session with plist_{{S_{j}'}}\cup plist_{{S_{j}}} as new admissible session waiting for authentication from new users.

If it receives key confirmation from all U_{l} in (U_{1},...,Unew_{m},..) then it will make S_{j} 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.