[messaging] RFC: (n+1)sec secure group chat - security properties and UX design
ruud at equalit.ie
Mon Sep 12 09:34:33 PDT 2016
The (n+1)sec project  is our  approach to developing a secure multiparty
chat system, implemented as a library that sends encrypted messages over
arbitrary carrier chat-systems. It aims to achieve chat security properties
similar to those of OTR -- confidentiality, authentication, deniability,
forward secrecy -- while adding chat-session authorization controls and
chat-consistency assurances. As with OTR, a major concern is to provide
security without sacrificing too much usability, and thus to avoid designing
a beautiful system that nobody will use because of its complexity.
Reliability is another priority, and we are trying to make sure the system
behaves sensibly in real-world contexts that include frequent casual attacks,
network connections breaking down, and other complications.
So far, work has consisted mostly of developing and perfecting the
cryptographic machinery necessary to make this happen, as well as
experimenting with the protocol design-space and studying the user interface
consequences of various design choices. More recently, we have been working
to condense the results of our experiments into a consistent, well-rounded
design, which meets all the requirements and solves all the problems we have
To this end, we have written a specification  that describes in detail:
- what (n+1)sec is supposed to accomplish;
- what security properties it can guarantee;
- what requirements (n+1)sec expects to hold regarding the chat server and
- what forms of interaction apply between the user and the (n+1)sec system,
and thus the conceptual shape of any user interfaces; and
- motivations and rationales for all of the above.
Together, these descriptions specify what problems the (n+1)sec system can
solve, what role it can play in a secure chat application, and what it
demands in terms of supporting infrastructure. In other words, it specifies
on a conceptual level the abstract API that the (n+1)sec library will
We expect to be able to develop a library that conforms to the design
described in this conceptual API specification ; we are currently working
on polishing a draft for a protocol that we claim can make all of this
happen. Before moving too far in that direction, we would very much like to
hear your thoughts about our plans. We invite you to review our work and send
us your comments, either on the mailing list via which you received this, or
off-list if you prefer. Does the design sound sensible? Are the tradeoffs
reasonable? Can you find any embarrassing omissions or security problems?
Anything we should simplify? Does it seem like the design will behave well in
real-world chat situations?
We'd be very grateful for your comments, criticisms, suggestions and thoughts
on our work. Please email us and let us know what you think.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part.
More information about the Messaging