mpOTR Project Plan

You can contribute to this plan using the version posted on the Cryptocat development wiki.

Cryptocat has relied on group chat as one of its staple features since its inception in 2011. Cryptocat’s group chat protocol has been openly implemented and specified, and has offered cryptographic confidentiality, integrity, authentication, and forward secrecy. However, due to lack of resources, the protocol has never undergone a security proof and rigorous academic review, and has never been made into a true standard protocol for multiparty chat, something which is needed in today’s cryptographic applications.

The mpOTR project, undertaken by Cryptocat and eQualitie, seeks to bring together the open source cryptography community to produce a protocol that builds upon the experience and research of the community over past years. Much of these research discussions have been instigated thanks to the success and popularity of Cryptocat’s work. We aim to end up with a universal standard that is specified, widely implementable, transport agnostic and that grants secure, encrypted group chat with properties of confidentiality, authentication, integrity, replay attack protection and forward secrecy. As much as we are technically allowed without overly compromising the efficiency or practicality of the protocol, we will also aim for message ordering preservation, and plausible deniability.

During our preparatory phase for this effort, we have met with members of our team and volunteers and contributors at large at numerous events and conferences (Observe Hack Make 2013, 30th Chaos Communication Congress, Real World Cryptography 2014 among others.) We’ve identified existing problems, possible solutions and a plan of action for the protocol.


Essential Protocol Properties

As part of our mpOTR effort, we will define an adversarial model for essential properties. In each case, we will present a proof towards reducing adversarial success in case of a successful attack against the mpOTR protocol or its cryptographic primitives.

  • Confidentiality: Assuming the honesty of the room participants, no outsider should be able to access the plaintext of messages sent and received within an mpOTR conversation.
  • Entity Authentication: Each participant should be able to verify the identity of the room participants using their long term identity.
  • Message Origin Authentication: Participant should not be able to forge messages to appear as if they originate from, or are authored by, other participants.
  • Transcript Consistency and Integrity: Outsiders should not be able to modify a conversation transcript. Honest participants should be able to verify that they all see the same transcript.
  • Forward Secrecy: The encrypted transcript should not be decipherable using long term keys.

Secondary Protocol Properties

Effort will be taken to satisfy these properties. However, due to the prioritization of protocol use cases and implementability, we may not present a mathematical proof or necessarily finally claim that our protocol satisfies these properties.

  • Message Ordering Preservation: All participant see messages in the same order.
  • Plausible Deniability: It should not be possible to prove after the conversation if a participant participated in the conversation. It should also not be possible to associate part of the transcript to a specific participant.

Non-cryptographic Protocol Properties

  • Transport Agnosticism: The protocol should not be dependent on properties exclusive to a small number of transport protocols (XMPP, IRC, email…) but should instead be minimally reliant on transport properties so that it is widely implementable across different transports.
  • Replay Attack Prevention: The protocol should guarantee that sent messages cannot be later resent by an adversary with control over network flow.

Previous Work

There exists a body of work that we have relied on in our primary investigations of mpOTR:

  1. M. D. Raimondo, R. Gennaro, and H. Krawczyk, Deniable Authentication and Key Exchange. 2006.
  2. M. Bellare and P. Rogaway, “Entity authentication and key distribution,” in Advances in Cryptology—CRYPTO’93, 1994, pp. 232–249.
  3. J. Bonneau and A. Morrison, “Finite-State Security Analysis of OTR Version 2.”
  4. H. Liu, E. Y. Vasserman, and N. Hopper, “Improved Group Off-the-record Messaging,” in Proceedings of the 12th ACM Workshop on Workshop on Privacy in the Electronic Society, New York, NY, USA, 2013, pp. 249–254.
  5. I. Goldberg, B. Ustaouglu, M. D. Van Gundy, and H. Chen, “Multi-party Off-the-record Messaging,” in Proceedings of the 16th ACM Conference on Computer and Communications Security, New York, NY, USA, 2009, pp. 358–368.
  6. N. Borisov, I. Goldberg, and E. Brewer, “Off-the-record Communication, or, Why Not to Use PGP,” in Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society, New York, NY, USA, 2004, pp. 77–84.
  7. M. D. Raimondo, R. Gennaro, and H. Krawczyk, “Secure off-the-record messaging,” in WPES, Alexandria, VA, USA, 2005, pp. 81–89.

Open Problems

  • Key agreement: One of the components of mpOTR that is not yet fully developed at this point is key exchange. There exists a naive, expensive approach with an efficiency of O(N²), but efficient group key exchange remains a central issue to be resolved with the protocol.
  • Message order verifiability: Verifying message orders becomes more difficult as different parties experience the reception of messages with different delays and orders due to differing network connection type, speed and quality. Ultimately, we may need to allow some leeway in which order messages are allowed to be received in a conversation in order for large group conversations to be possible while accommodating for varying levels of network latency between participants.
  • Room moderation: There exist arguments for not including moderation as part of the protocol to allow protocol implementation to remain simple and transport-agnostic. The current Cryptocat model does not allow for any kind of room moderation, but however offers users the ability to mute messages from other users.


Specification Authors

Specifications authors are responsible for the authorship of mpOTR specification drafts, up until the final draft of the specification. Most importantly, they must present their drafts on time to be taken up by the specification reviewers team, who must offer timely feedback on each specification draft. The specification authors must then consider this feedback and incorporate the necessary changes into their next draft. This team is comprised entirely of a cryptography PhD research unit from various Canadian universities who have been working closely with Cryptocat and eQualitie for some time.

Specification Reviewers

Specification reviewers receive timely drafts from the specification authors. Specification reviewers must, true to their name, review each specification draft and present any vulnerabilities, fixes, weaknesses, inefficiencies and improvements they may find. Specification authors must then accept the report from the specification reviewers, and incorporate as much of it as they deem suitable into their upcoming draft. Once specification reviewers and authors reach an agreement on a particular draft, it is considered to be the final draft and may be published for public review.

Implementation Authors

Once the final draft of the mpOTR specification has been agreed upon by both specification authors and specification reviewers, the implementation authors must produce portable mpOTR libraries written in one high level language (JavaScript, Python) and one low level language (C). These libraries are to be used as reference implementations and must be securely written, adhere completely to the specification and pass any test vectors. They must also be written in a fashion that allows them to act as pluggable libraries into other projects.

Implementation Reviewers

Once an implementation is completed by the implementation authors, the reviewers must provide a code audit and suggest fixes for any security vulnerabilities or inefficiencies found in the code. This process is different from the specification review process in that there are no “drafts.” There is only one implementation written, and it is only audited once before publication.


January 2014

Finish planning stages of mpOTR project.

March 2014

First draft of specification is presented to specification review team.

April 2014

Specification Review Summit takes place in Montréal, Canada, bringing together the specification authors and reviewers to help discuss the second specification draft. During this time, the specification is also reviewed for standards of implementability and accessibility to real-world use-cases and scenarios.

June 2014

Present second draft of mpOTR specification to specification review team. Review of the second draft and presentation of comments.

July 2014

Final agreement between specification author and review teams on all cryptographic properties, security model details, and all other details necessary for beginning the authorship of the final draft of the specification.

August 2014

Final draft of the mpOTR specification is officially approved by both specification author and review teams, no more modifications are allowed. The specification phase ends here, and the work for both specification teams is permanently completed.

September 2014

mpOTR implementation prototype in JavaScript and C.

October 2014

mpOTR implementations in JavaScript and C are presented for review by the implementation review team.

November 2014

Implementation review team communicates audit results, identifying any vulnerabilities or inefficiencies. mpOTR implementations are fixed of any inefficiencies, version 1.0 of the implementations is frozen.


mpOTR is released on its own website, complete with all papers, specifications, reference implementations and documentation.


Our main focus during this collaboration between Cryptocat, eQualitie and a number of contributors is practical results. The discussions surrounding mpOTR have been overly theoretical for years, and no actionable protocols that are implementable to handle real world use cases have therefore been devised. This is the problem we aim to fix with our workflow. We thank the Open Technology Fund for supporting our work.