MpSEQ/protocol - Revision history

Dmitri: /* II. History and literature review */

2014-11-05T21:28:07Z

‎II. History and literature review

Dmitri: /* I. INTRODUCTION */

2014-11-05T19:31:04Z

‎I. INTRODUCTION

Dmitri: /* I. INTRODUCTION */

2014-11-05T17:53:56Z

‎I. INTRODUCTION

Dmitri: /* III. Design rationale */

2014-11-05T17:41:40Z

‎III. Design rationale

Dmitri at 17:32, 5 November 2014

2014-11-05T17:32:50Z

Dmitri: Created page with "===Abstract=== ''In this document we present the first public draft of mpSEQ - a secure multi-party communication protocol developed by eQualit.ie with support from the [http..."

2014-11-03T20:53:27Z

Created page with "===Abstract=== ''In this document we present the first public draft of mpSEQ - a secure multi-party communication protocol developed by eQualit.ie with support from the [http..."

Show changes

@@ Line 11: / Line 11: @@
 = II. History and literature review =
-<span style="font-size:200%">T</span>wo-party Off The Record messaging (OTR) has been introduced in [BGB04] as a better alternative to PGP for casual Internet chat. OTR authors argue that using PGP for Internet chat is problematic due to the PGP scheme’s lack of forward secrecy and deniable transcript features. These properties are expected in Internet chat, since it mimics casual day-to-day real-world conversations where future deniability is implicit.
+<span style="font-size:200%">T</span>wo-party Off The Record messaging (OTR) was introduced in [BGB04] as an alternative to PGP for secure Internet chat by providing forward secrecy and deniable transcript features. [BGB04] proposes the use of symmetric encryption and message authentication in OTR for confidentiality and integrity, and the Diffie-Hellman key exchange for authenticating the other party in the chat.
-[BGB04] offers OTR as an alternative approach to PGP for simulating casual two-party chat on the Internet. While OTR uses symmetric encryption and message authentication to secure confidentiality and message integrity, it uses Diffie-Hellman key exchange as an approach to authenticate the other party in the chat.
+The OTR protocol received a lot of attention and has matured over the years. For example, in [RGK05], researchers point out that OTR’s approach to authenticate renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the secrecy of the conversation. Hence, breaking the secrecy of the conversation (e.g. by leaking the session key) will lead to false authentication as well. They offer two authenticated deniable 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 the protocol entirely.
-There have been various security analyses and some criticisms of OTR since its introduction in 2004. For example,[BM] 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 the Diffie-Hellman key exchange failure in delivering authentication in the presence of an active adversary. Furthermore, they show that the early publication of MAC keys for the purpose of forgeability can easily enable the active adversary to forge messages during the conversation (instead of the intended forgeability after the conversation has ended). Finally, they argue that in an environment where the adversary is controlling the whole network, she can effectively disarm the protocol of its forgeability property.
+An alternative appears in [BS07], using the Schnorr zero-knowledge proof and signature algorithm, to introduce a 4-round challenge-based authentication scheme that grants deniability to the two-round authenticated protocol described in [BVS05].
-In [RGK05], researchers criticize OTR’s approach in which the authenticity of the renewed ephemeral session keys is provided by the property of confidentiality and is therefore dependent on the secrecy of the conversation. Hence, breaking the secrecy of the conversation (by the leak of the session key, for example) will lead to false authentication as well. They offer two authenticated deniable 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 the protocol entirely.
+[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 [GUVGC09], the authors offer a generalization of two-party OTR to the multi-party case. However, they do not specify the cryptographic primitives, neither do they give a formal definition of the adversaries nor the proof of 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. OTR authors proposed a generalisation of two-party OTR to a multiparty use-case in [GUVGC09]. However, they did not specify the cryptographic primitives, neither 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. '''DV - needs a reference'''
-−
-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-knowledge proof and signature algorithm, introduces 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.
 =III. Design rationale =

@@ Line 7: / Line 7: @@
 <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 and subsequent efforts to explore a multiparty use-case for OTR in [GUVGC09]. 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 relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we overview the properties that we are aiming for in this protocol. In [[#V._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. [[#IV._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 [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._mpSEQ_Protocol:_Step_by_Step|Section VIII]], we present each of the mpSEQ protocol steps at various stage in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we conclude by describing work remaining to be done on this protocol.
+In the following section we summarise relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we review the security properties within this protocol. In [[#V._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. [[#IV._Adversarial_Models|Section VI]] provides formal definitions and references to the adversarial models for each property. In [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._mpSEQ_Protocol:_Step_by_Step|Section VIII]], we present each of the mpSEQ protocol steps at various stages in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we conclude by describing work remaining to be done on this protocol.
 = II. History and literature review =

@@ Line 5: / Line 5: @@
 =I. INTRODUCTION=
-<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] and subsequent efforts to explore a multi-party use-case for OTR in [GUVGC09]. The protocol 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.
+<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 and subsequent efforts to explore a multiparty use-case for OTR in [GUVGC09]. 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 relevant publications and their results. In Section [[mpSEQ#Design_rationale|III]], we describe our approach and choice of security features. In Section [[mpSEQ#Security_Properties|IV]], we overview the properties that we are aiming for in this protocol. In Section [[mpSEQ#Chat_Session_Model|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_Models|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_Design|VII]] we describe various parts of the protocol and present choices for each sub protocol. In Section [[mpSEQ#mpSEQ_Protocol:_Step_by_Step|VIII]], we present each of the mpSEQ protocol steps at various stage in schematic and algorithmic format. We present our choice of primitives in Section [[mpSEQ#Cryptographic_Primitives|IX]]. Finally, we conclude by describing work remaining to be done on this protocol.
+In the following section we skim over relevant publications and describe their influence on this protocol. In [[#III._Design_rationale|Section III]], we describe our approach and choice of security features. In [[#IV._Security_Properties|Section IV]], we overview the properties that we are aiming for in this protocol. In [[#V._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. [[#IV._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 [[#VII._Protocol_High_Level_Design|Section VII]] we describe various parts of the protocol and present choices for each sub protocol. In [[#VIII._mpSEQ_Protocol:_Step_by_Step|Section VIII]], we present each of the mpSEQ protocol steps at various stage in schematic and algorithmic format. We present our choice of primitives in [[#iX._Cryptographic_Primitives|Section IX]]. Finally, we conclude by describing work remaining to be done on this protocol.
 = II. History and literature review =

@@ Line 33: / Line 33: @@
 # 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 negatively impact usability or our [#IV._Security_Properties security goals]
+# 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.

@@ Line 26: / Line 26: @@
 [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.
 =III. Design rationale =
-<span style="font-size:200%">T</span>he main motivation behind the development of mpSEQ is the lack of provably secure, implementable, end-to-end encrypted multiparty chat protocols that apply to a variety of use-cases. Our approach for the mpSEQ design was based on the following rationales, listed in order of importance:
+<span style="font-size:200%">T</span>he main motivation driving mpSEQ 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 approach for 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.
+# 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.
+# Usability according to real world use-cases.
-* Providing some degree of deniability when it does not hurt usability or our fundamental security goals.
+# 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.
+# 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].
 Additionally, based on the conclusions of [BM] and [RGK05], we are taking the following points into consideration:
@@ Line 53: / Line 51: @@
 * 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.
 = IV. Security Properties =