=III. Design rationale =
<span style="font-size:200%">TO</span>he main motivation driving ''(n)sec'' development is the lack of a provably secure and implementable multiparty chat protocol offering end-to-end encryption and applicable to a variety of use-cases. Our ur approach for ''(n)sec'' design was based on the following rationalesrequirements, listed in order of importance:
# A protocol that is provably secure in a sufficiently strong adversarial model which that addresses the most urgent requirement of users in need of security. These are: confidentiality, authenticity and forward secrecy.# Usability according to real world the Cryptocat XMPP use-cases.case
# Providing some degree of deniability when it does not negatively impact usability or our [[#IV._Security_Properties security goals]]
# Addressing security flaws in the OTR protocol.[BGB04] and [GUVGC09]
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 satisfying the above stated goals.
A significant portion of this our research suggests suggested 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 Based on conclusions in [BM] and periodic heartbeats are other major departing points of ''(n)sec'' from mpOTR [GUVGC09RGK05]., we are making the following design changes:
In designing ''(n)sec''’s * Using a more secure deniable authentication and key agreement protocolexchange algorithm, we have followed the main idea instead of [ACMP10] in choosing naive Diffie-Hellman* Using a provably secure authenticated more practical algorithm, rather than the peer-to-peer signature key exchange method * Omitting forgeability and replacing malleability from the signature-based protocol and refraining from broadcasting the expired ephemeral authentication with a deniable onekeys. We have chosen the protocol introduced in [ACMP10] instead * Offering provably secure models for every aspect of [BS07], due to its superior efficiency. We abstract out the method where parties communicate their secret for additional flexibilityalgorithm which formalizes the critical security properties of ''(n)sec''.
We In designing ''(n)sec''’s deniable authentication and key agreement protocol, we have chosen followed [ACMP10] by choosing a provably secure authenticated key exchange method and replacing the two round SKEMEsignature-based Triple Diffie-Hellman deniable key authentication with a deniable one. We have chosen the protocol introduced in [ACMP10] 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, due to its superior efficiency. We have also modified abstract out the protocol to represent the chat condition method where participants sequentially join and leave the chatparties communicate their secret for additional flexibility.
Another major difference between ''(n)sec'' and We have chosen the two round SKEME-based Triple Diffie-Hellman deniable key authentication instead of the Schnorr signature scheme suggested original protocol for mpOTR in [GUVGC09BS07] is in-session transcript because it saves us two critical rounds for authentication, which happens every time (even though it offers a participant receives or send a messageslightly weaker form of deniability). The transcript authentication, which we refer We have also modified the protocol to as transcript consistency check throughout this document, is an optimistic approach based on represent the assumption that chat condition where participants sequentially join and leave the XMPP server provides a reliable and orderly message deliverychat.
Additionally, based on the conclusions of [BM] Another major difference between ''(n)sec'' and [RGK05], we are taking the following points into consideration: * Using a more secure deniable key exchange algorithm, instead of naive Diffie-Hellman, and a more practical algorithm, rather than the peer-to-peer signature key exchange suggested protocol for mpOTR in [GUVGC09]is in-session transcript authentication, which happens every time a participant receives or sends a message.* Omitting forgeability and malleability Transcript authentication (referred to as transcript consistency check from here on) is an optimistic approach based on the protocol as recommended by [RGK05] assumption that the XMPP server provides a reliable and refraining from broadcasting the expired ephemeral authentication keysorderly message delivery. 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 also equip ''(n)sec''with heartbeat to ensure in-session forward secrecy, periodical consistency check and freshness.
We also equip ''(n)sec'' with heartbeat to ensure inFinally, we propose the possibility of using block-based, rather than stream-session forward secrecybased, periodical consistency check and freshnessencryption for the symmetric encryption primitives.
= IV. Security Properties =
<span style="font-size:200%">F</span>ollowing from the original proposal for the mpOTR protoocol proposed in [GUVGC09] and based on our design rationales proposed in Section[[''(n)sec''#Design_rationale|III]], we give an informal description of the properties which ''(n)sec'' aims to secure in a multi-party chat session:<br /><br />
* <span>'''Participant deniable authenticity'''</span> based on their long term persistent identity: While a participant in a chat can be sure of another participant’s authenticity, they cannot prove their confidence to anybody else who has not actively participated in the chat session or who has not interacted with the authenticator prior to the session.