[messaging] RFC: (n+1)sec secure group chat - security properties and UX design

[Ruud Koolen]

Hi folks,

The (n+1)sec project [1] is our [2] 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 
identified.

To this end, we have written a specification [3] 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 
supporting infrastructure;
  - 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 
hopefully implement.

We expect to be able to develop a library that conforms to the design 
described in this conceptual API specification [3]; 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.

Kind regards,
Ruud Koolen
eQualit.ie

[1] https://equalit.ie/portfolio/np1sec/
[2] https://equalit.ie/
[3] 
https://github.com/equalitie/np1sec/raw/c26932edf28421ce896bd815f135d70676722b80/doc/high-level-api.pdf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160912/fbc9572f/attachment.sig>