Blog

Introducing (n+1)sec – a protocol for distributed multiparty chat encryption

By: dmitri On: August 10, 2017 Comments Disabled
Today we present (n+1)sec, a free (libre), end-to-end secure, synchronous protocol for group chat developed by eQualit.ie with support from the Open Technology Fund. After 2 years of design, development and testing, we are releasing the (n+1)sec protocol and library for securing group conversations on various messaging systems, like Jabber/XMPP or IRC. Following a  protocol and cryptographic review by the NCC Group, we are looking forward to its implementation in as many chat clients as possible.

 

 

Distributed encryption for federated group chat

Considering the times we live in, people tend to rely more and more on encrypted chat for communicating securely with their friends and colleagues. Some of the most secure communication tools have been conceived for this kind of interaction online, including the widespread OTR (off-the-record) and Signal protocols. Our aim was to complement and build on these technologies, offering communication and privacy properties to which these protocols currently did not cater. For example, OTR has been around for over a decade and is built into many desktop and mobile messaging platforms. Its encryption capabilities however are limited to conversations between two people, and cannot be used for a group of three or more. The Signal protocol has been implemented in Signal, WhatsApp, Facebook messenger and many other tools, reaching over a billion users. It is an incredibly powerful solution but it is reliant on asynchronous communication and is therefore also dependent on the messaging platform — a central server that can become a single point of failure (or metadata collection).
These were the starting points for eQualit.ie when considering the (n+1)sec design – we wanted a tool as flexible as OTR that could offer groups and organizations a secure way of communicating and coordinating, respecting federation for messaging protocols and adhering to end-to-end encryption properties for privacy. Our final protocol has the following security properties for group messaging:
  • Confidentiality: the conversation is not readable to an outsider
  • Forward secrecy: conversation history remains unreadable to an outsider even if participants’ encryption keys are compromised
  • Deniable authentication: Nobody can prove your participation in a chat
  • Authorship: A message recipient can be assured of the sender’s authenticity even if other participants in the room try to impersonate the sender
  • Room consistency: Group chat participants are confident that they are in the same room
  • Transcript consistency:  Group chat participants are confident that they are seeing the same sequence of messages

Can i test it?

To be sure that (n+1)sec did what we wanted it to do, we have developed an internal dogfooding client in the form of a Pidgin plugin. It is experimental and you shouldn’t rely on it for security – or even stable communications – but it is a good demonstration of how (n+1)sec works. There is a public server set-up for testing it with your friends and colleagues. You can also run the software with any Jabber/XMPP server you already have.
We also wrote a command line client, called Jabberite. It’s in the main (n+1)sec repository and can be used, for instance, with EchoChamber, a testing platform for the (n+1)sec protocol that simulates network conditions and peer behaviour to produce programmer-friendly benchmark data.

How can I help?

Now that a first protocol for secure distributed multiparty chat exists, we would love to see it implemented and used! If you are interested in making this happen, you can give us a precious hand: testing, bugtracking, and of course further development are welcome. The code is out there — just check it out! And of course if you have any feedback you don’t think fits in a public Github repository, you can always write to us through our contact form https://equalit.ie/#contact.

Related Posts

np1sec challenge

The challenge involve partially implementing some of our XMPP test client event handlers...

Deflect Stats July 2016

From what we can conclude from our statistics, during the month of July bot controllers...