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

If users are joining that session concurrently, there are admissible which are receiving shares and authentication messages.

Suppose receives the mutual authentication of all new users in admissible session that will become the potentially next session of . then sends the combined list of (authenticated) participants in , 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 as inadmissible sessions.

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

If it receives key confirmation from all in then it will make 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.