<span style="font-size:200%">T</span>he mpSEQ project was inspired by [https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html Off-The-Record Messaging Protocol] messaging protocol and subsequent efforts to explore a multi-party multiparty use-case for OTR in [GUVGC09]. The protocol mpSEQ is currently developed for [https://github.com/cryptocat/cryptocat/wiki/mpOTR-Project-Plan Cryptocat] - a browser based XMPP chat platform and assumes its use-cases. Most importantly, mpSEQ allows for secure multi-party key exchange and end-to-end encrypted communications without extensive computational requirements from the client. You can follow and contribute to the implementation of [https://github.com/equalitie/libmpotr libmpotr] on our Github pages. Future protocol iterations will consider a variety of other real-world use cases and be platform independent.

In the following section we skim over summarise relevant publications and describe their resultsinfluence on this protocol. In Section [[mpSEQ#Design_rationaleIII._Design_rationale|Section III]], we describe our approach and choice of security features. In Section [[mpSEQ#Security_PropertiesIV._Security_Properties|Section IV]], we overview review the security properties that we are aiming for in within this protocol. In Section [[mpSEQ#Chat_Session_ModelV._Chat_Session_Model|Section V]] we give basic mathematical definition needed to model the chat session and security proofs for various security aspects of the protocol. Section [[mpSEQ#Adversarial_ModelsIV._Adversarial_Models|Section VI]] provides formal definitions and references to the adversarial models for each property which will be the base of the security proof for the protocol. In Section [[mpSEQ#Protocol_High_Level_DesignVII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In Section [[mpSEQ#mpSEQ_ProtocolVIII._mpSEQ_Protocol:_Step_by_Step|Section VIII]], we present each of the mpSEQ protocol steps at various stage stages in schematic and algorithmic format. We present our choice of primitives in Section [[mpSEQ#Cryptographic_PrimitivesiX._Cryptographic_Primitives|Section IX]]. Finally, we conclude by describing work remaining to be done on this protocol.

<span style="font-size:200%">T</span>wo-party Off The Record messaging (OTR) has been was introduced in [BGB04] as a better an alternative to PGP for casual secure Internet chat. OTR authors argue that using PGP for Internet chat is problematic due to the PGP scheme’s lack of by providing forward secrecy and deniable transcript features. These properties are expected [BGB04] proposes the use of symmetric encryption and message authentication in Internet chatOTR for confidentiality and integrity, since it mimics casual dayand the Diffie-to-day real-world conversations where future deniability is implicitHellman key exchange for authenticating the other party in the chat.

The OTR protocol received a lot of attention and has matured over the years. For example, in [BGB04RGK05] offers OTR as an alternative , researchers point out that OTR’s approach to PGP for simulating casual two-party chat authenticate renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the Internetsecrecy of the conversation. While OTR uses symmetric encryption and message authentication Hence, breaking the secrecy of the conversation (e.g. by leaking the session key) will lead to secure confidentiality and message integrityfalse authentication as well. They offer two authenticated deniable key exchange protocols, it uses Diffie-Hellman which also provide forward secrecy, as a replacement for OTR’s original key exchange . Furthermore, they argue that forgeability and malleability do not have any mathematical consequence in improving deniability if the parties have been authenticated by a deniable key exchange scheme. They argue that as an approach these properties pose potential security threats, it is desirable to authenticate the other party in omit them from the chatprotocol entirely.

There have been various security analyses and some criticisms of OTR since its introduction An alternative appears in 2004. For example,[BMBS07] shows that the unauthenticated exchange of the OTR version identifier can pose a threat to authenticity: the adversary can force clients to downgrade to an older, insecure version of the protocol. They also make note of using the DiffieSchnorr zero-Hellman key exchange failure in delivering knowledge proof and signature algorithm, to introduce a 4-round challenge-based authentication in the presence of an active adversary. Furthermore, they show scheme that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary grants deniability to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that two-round authenticated protocol described in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property[BVS05].

In [RGK05ACMP10] offers a more efficient protocol than [BS07], researchers criticize OTR’s approach in which the authenticity of the renewed sense that ephemeral session Diffie-Hellman elements are reusable to regenerate keys is provided by the property when some of confidentiality and is therefore dependent on the secrecy of the conversationparticipants change. HenceAs such, breaking the secrecy of the conversation (by the leak of the session key, for example) will lead it offers a one-round protocol to false authentication as well. They offer two authenticated deniable generate a key exchange protocols, which also provide forward secrecy, as a replacement for OTR’s original key exchange. Furthermore, they argue that forgeability and malleability do not have any mathematical consequence in improving deniability if the parties have been authenticated by a deniable key exchange scheme. They argue that as these properties pose potential security threats, it is desirable to omit them from subgroup of the protocol entirelyoriginal conversation.

In [GUVGC09], the Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. OTR authors offer proposed a generalization generalisation of two-party OTR to the multia multiparty use-party casein [GUVGC09]. However, they do did not specify the cryptographic primitives, neither do did they give a formal definition of the adversaries nor the proof of the algorithm’s security (reduction). Although a more robust key exchange is proposed, some primary performance analysis of the implementation of the key agreement protocol has been shown to be impractically slow, especially on mobile devices. Various attempts have been made to construct an efficient multiparty (known as group) authenticated key exchange protocol. Protocols proposed in [BCP01] and [BCPQ01] have been shown to be insecure against various adversarial models [GBNM11] and [Man06]. [BVS05] shows that the protocol introduced in [KLL04] is not secure against replaying the user’s message in another chat. The authors offer a slightly modified version of the protocol to remedy this. Authors of [RGK05] introduce 2 protocols with forward secrecy to replace the vulnerable deniable authentication of OTR. Both [RGK05] and [BS07] argue that SIGMA does not meet the definition of a truly deniable algorithm and the latter shows how it fails the deniability adversarial model introduced in [BS07]. Alternatively [BS07], using the Schnorr zero'''DV -knowledge proof and signature algorithm, introduces needs a 4-round challenge-based authentication scheme that grants deniability to the two-round authenticated protocol described in [BVS05]. [ACMP10] offers a more efficient protocol than [BS07], in the sense that ephemeral Diffie-Hellman elements are reusable to regenerate keys when some of the participants change. As such, it offers a one-round protocol to generate a key for a subgroup of the original conversation.reference'''

# Providing some degree of deniability when it does not negatively impact usability or our [[#IV._Security_Properties security goals]]