[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.
In designing mpSEQ’s deniable authentication and key agreement protocol, we have followed the main idea of [ACMP10] in choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] instead of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.
We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication even though it offers a slightly weaker form of deniability. We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.
Another major difference between mpSEQ and the suggested original protocol for mpOTR in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or send a message. The transcript authentication, which we refer to as transcript consistency check throughout this document, is an optimistic approach based on the assumption that the XMPP server provides a reliable and orderly message delivery.
We also equip mpSEQ with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.
=III. Design rationale =
<span style="font-size:200%">T</span>he main motivation behind the driving mpSEQ development of mpSEQ is the lack of a provably secure, and implementable, multiparty chat protocol offering end-to-end encrypted multiparty chat protocols that apply encryption and applicable to a variety of use-cases. Our approach for the mpSEQ design was based on the following rationales, listed in order of importance:
* # A protocol that is provably secure in a sufficiently strong adversarial model which addresses the most urgent requirement of users in need of security. These are : confidentiality, authenticity and forward secrecy.* # Usability according to real world use -cases.* # Providing some degree of deniability when it does not hurt negatively impact usability or our fundamental [#IV._Security_Properties security goals.]* # Addressing security flaws in the OTR protocol.
To achieve these goals, we focused our studies on the OTR protocol and various subsequent protocols evolved from OTR such as the TextSecure protocol [Sys14], as well as papers offering security analysis of the original OTR protocol. We designate the protocol suggested in [GUVGC09] as our starting point and apply various modifications to reach a desirable protocol which satisfies our goals.
A significant portion of this research suggests a better performing, more secure alternative to the key exchange protocol suggested in [GUVGC09] which is considered by various researchers to be one of the most troubling and inefficient aspects of the proposal. In-session transcript consistency and periodic heartbeats are other major departing points of mpSEQ from mpOTR [GUVGC09].
In designing mpSEQ’s deniable authentication and key agreement protocol, we have followed the main idea of [ACMP10] in choosing a provably secure authenticated key exchange method and replacing the signature-based authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] instead of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibility.
We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of Schnorr signature scheme suggested in [BS07] because it saves us two critical rounds for authentication even though it offers a slightly weaker form of deniability. We have also modified the protocol to represent the chat condition where participants sequentially join and leave the chat.
Another major difference between mpSEQ and the suggested original protocol for mpOTR in [GUVGC09] is in-session transcript authentication, which happens every time a participant receives or send a message. The transcript authentication, which we refer to as transcript consistency check throughout this document, is an optimistic approach based on the assumption that the XMPP server provides a reliable and orderly message delivery.
Additionally, based on the conclusions of [BM] and [RGK05], we are taking the following points into consideration:
* Omitting forgeability and malleability from the protocol as recommended by [RGK05] and refraining from broadcasting the expired ephemeral authentication keys. We propose the possibility of using block-based, rather than stream-based, encryption for the symmetric encryption primitives.
* Offering provably secure models for every aspect of the algorithm which formalizes the critical security properties of mpSEQ.
We also equip mpSEQ with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.
= IV. Security Properties =