Hi Eleanor Thanks for the question. We'd encourage ongoing discussion on the protocol to take place on the project wiki https://learn.equalit.ie/wiki/Talk:Np1sec We decided on this platform for publication (as opposed to the traditional LaTeX/PDF) so as to publicly collate review and progress as we mature the protocol.
The protocol requirements were adapted from the original mpOTR paper by Goldberg and Borisov, dropping only forgeability. Room moderation was discussed alongside many other topics over a six month period on algorithm design. The consensus was that properties like moderation and kick are part of the client/transport layer and are not explicitly part of a secure communications protocol. (n+1)sec design model is based on everybody in the room having an equal say on key agreement. However (n+1)sec supports room consistency, that is the chat session only starts after all participants have the same view of the room (who is in the room). If the chat protocol (let's say XMPP or IRC) support kick, that will trigger our "leave" sub-protocol [1] to tell remaining room members that the kicked participant is omitted, and compute a new session key (similar to heartbeat failure [2]). The new session cannot start without confirmation of the new participants list from those remaining in the room. This is our cryptographic solution to make sure that the kicked user no longer has access to the conversation. Sincerely Dmitri Vitaliev [1] https://learn.equalit.ie/wiki/Np1sec#VIII.4_Leave [2] https://learn.equalit.ie/wiki/Np1sec#Failure_to_heartbeat_and_inactivity_timers On 14-12-10 01:31 PM, Eleanor Saitta wrote: > On 2014.12.10 11.31, Dmitri Vitaliev wrote: > > Dear Libtech > > > In recognition and celebration of Human Rights Day, eQualit.ie is > > proud to release the first public draft of a provably secure > > protocol for group messaging on the Internet > > https://learn.equalit.ie/wiki/Np1sec > > > The protocol provides for end-to-end security of synchronous > > communications between any number of people. It is efficient and > > builds on recent advancements in cryptographic research. Security > > properties of (n+1)sec include: > > > * Confidentiality: the conversation is not readable to an outsider > > * Forward secrecy: conversation history remains unreadable to an > > outsider even if participants’ encryption keys are compromised * > > Deniable authentication: Nobody can prove your participation in a > > chat * Authorship: A message recipient can be assured of the > > sender’s authenticity even if other participants in the room try to > > impersonate the sender * Room consistency: Group chat participants > > are confident that they are in the same room * Transcript > > consistency: Group chat participants are confident that they are > > seeing the same sequence of messages > > Hi! This is great news and I'm delighted to see a new effort in this > space, especially one that's taken review seriously from the > beginning. I'm curious, however, how the requirements for the > protocol where arrived at. In particular, I notice that you're > supporting group chat with no specific provision made for a moderator > role to eject a participant from a chat room. When I've talked to > users about their actual use of group chats, this is a consistent > requirement and far more important than deniability, the utility of > which is still unclear at best. Would you talk a bit about how you > arrived at that list of properties and how moderator ejection will be > implemented, assuming uncooperative clients? > > E. > -- Director | https://equalit.ie | https://deflect.ca GPG key ID: 0x6FF1895D -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
