[messaging] RFC: (n+1)sec secure group chat - protocol specification draft

[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.

A couple of months ago, we published a draft [3] 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 [4] and proof-of-concept client [5] that we feel works well in 
practice. This implementation is based on the design in [3], 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 [6] 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 
detail:
- 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 
streams.
The specification could also use a conceptual bird's-eye overview of the 
protocol.

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 [7] 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.

Kind regards,
Ruud Koolen
eQualit.ie

[1] https://equalit.ie/portfolio/np1sec/
[2] https://equalit.ie/
[3] https://github.com/equalitie/np1sec/raw/master/doc/high-level-api.pdf
[4] https://github.com/equalitie/np1sec/
[5] https://github.com/equalitie/np1sec-test-client/
[6] https://github.com/equalitie/np1sec/raw/master/doc/protocol.pdf
[7] https://www.nccgroup.trust/us/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20170210/5bbc1f27/attachment.sig>