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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Messaging mailing list Messaging@moderncrypto.org https://moderncrypto.org/mailman/listinfo/messaging
