[messaging] RFC: (n+1)sec secure group chat - protocol specification draft
ruud at equalit.ie
Thu Feb 9 20:55:34 PST 2017
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.
A couple of months ago, we published a draft  of a design outline for the
(n+1)sec system, describing what model of communication (n+1)sec can support,
what communication infrastructure it needs to make that happen, and what
security properties it can deliver in that setting. Since then, we have been
busy implementing a version of the (n+1)sec library that realizes that
design. After having gone through several iterations of design,
implementation, and practical testing, we have now arrived at a version of
the library  and proof-of-concept client  that we feel works well in
practice. This implementation is based on the design in , though amended
in certain places where practical testing found parts of the design that did
not work as well as we had hoped.
In order to facilitate independent study and analysis of the (n+1)sec system,
we have written a draft  specification of the protocol used by (n+1)sec.
This specification describes the abstract cryptographic protocol used by
(n+1)sec, and the assumptions it relies on; a codification of the model
driving (n+1)sec; and the specification and semantics of all communication
exchanged by users of the protocol.
This document is a draft, not a finished specification. There is a number of
elements that a well-polished, real-world-ready protocol specification should
include, that have not yet been completed in this draft version of the
specification. The protocol specification does not yet describe in any
- what the (n+1)sec protocol accomplishes;
- how (n+1)sec chat behaves from a user point of view;
- what security properties (n+1)sec can guarantee, and against what threats;
- the exact encoding used for encoding abstract (n+1)sec messages as byte
The specification could also use a conceptual bird's-eye overview of the
Despite these omissions in this draft version of the protocol specification,
we'd be very interested in hearing what the members of the cryptographic
messaging community have to say about this protocol design. We are planning
to have the fine folks at NCC Group  take a look at the (n+1)sec design,
and perform a formal audit of the protocol and implementation alike; we are
preparing a version of the protocol specification for them to review. In the
meantime, we would love to hear the opinions of the wider community as well,
regarding what we have so far. Does the protocol design sound sensible? Are
there any obvious security problems, cryptographic or otherwise? Does the
design appear to be able to handle the rigours or use in real-world
conditions? Anything we should improve? Besides "go finish these missing
sections", that is :-)
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: 833 bytes
Desc: This is a digitally signed message part.
More information about the Messaging