STOCKHOLM SWEDEN 2020,
On Asynchronous Group Key Agreements
Tripartite Asynchronous Ratchet Trees
PHILLIP GAJLAND
Phillip Gajland
A thesis submitted for the degree of Master of Science
Theoretical Computer Science:
Algorithms, Complexity and Cryptography
Supervisor (CH): Prof. Dr. Serge Vaudenay
Security and Cryptography Laboratory (LASEC) EPFL – Swiss Federal Institute of Technology Lausanne Supervisor (SE): Prof. Dr. Mats N¨aslund
Division of Theoretical Computer Science (TCS) KTH - Royal Institute of Technology
Examiner: Prof. Dr. Johan H˚astad Department of Mathematics
KTH - Royal Institute of Technology
School of Electrical Engineering and Computer Science KTH Royal Institute of Technology
Stockholm / Lausanne - Spring 2020
The subject of secure messaging has gained notable attention lately in the cryptographic community. For communications between two parties, paradigms such as the double ratchet, used in the Signal protocol, provide provably strong security guarantees such as forward secrecy and post-compromise security. Variations of the Signal protocol have enjoyed widespread adoption and are embedded in several well known messaging services, including Signal, WhatsApp and Facebook Secret Conversations. However, providing equally strong guarantees that scale well in group settings remains somewhat less well studied and is often neglected in practice. This motivated the need for the IETF Messaging Layer Security (MLS) working group. The first continuous group key agreement (CGKA) protocol to be proposed was Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] and formed the basis of TreeKEM [Barnes et al., 2019], the CGKA protocol currently suggested for MLS.
In this thesis we propose a new asynchronous group key agreement protocol based on a one-round Tripartite Diffie-Hellman [Joux, 2000]. Furthermore, we show that our protocol can be generalised for an n-ary asynchronous ratchet tree, assuming the existence of a one-round (n + 1)-way Diffie-Hellman key exchange, based on a n-multilinear map [Boneh and Silverberg, 2003]. We analyse ART, TreeKEM, and our proposals from a complexity theoretic perspective and show that our proposals improve the cost of update operations.
Finally we present some discussion and improvements to the IETF MLS standard.
Keywords: MLS, secure messaging, cryptography.
Phillip Gajland (Stockholm / Lausanne - Spring 2020) On Asynchronous Group Key Agreements
Amnet¨ om s¨akra meddelanden har p˚a senare tid skapat uppm¨arksamhet inom kryptografiska samfundet. F¨or kommunikationer mellan tv˚a parter ger paradigmer s˚asom Double Ratchet, som anv¨ands i Signal-protokollet, starka bevisbara s¨akerhetsgarantier som forward secrecy och post-compromise security. Variationer av Signal-protokollet anv¨ands mycket i praktiken och ¨ar inb¨addade i flera v¨alk¨anda meddelandetj¨anster s˚asom Signal, WhatsApp och Facebook Secret Conversations. D¨aremot ¨ar protokoll som erbjuder lika starka garantier och som skalar v¨al i gruppsituationer n˚agot mindre studerade och ofta eftersatta i praktiken. Detta motiverade behovet av arbetsgruppen IETF Messaging Layer Security (MLS).
Det f¨orsta kontinuerliga gruppnyckelprotokollet (CGKA) som f¨oreslogs var Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] och lade grunden f¨or TreeKEM [Barnes et al., 2019], det CGKA-protokoll som f¨or n¨arvarande f¨oreslagits f¨or MLS. I detta examensarbete f¨oresl˚ar vi ett nytt asynkront gruppnyckelprotokoll baserat p˚a en en-rundad Tripartite Diffie–Hellman [Joux, 2000]. Vidare visar vi att v˚art protokoll kan generaliseras f¨or n-ary tr¨ad med hj¨alp av ett en-rundat (n + 1)-v¨ag Diffie-Hellman nyckelutbyte, baserat p˚a en multilinj¨ar mappning [Boneh and Silverberg, 2003]. Vi analyserar ART, TreeKEM och v˚ara f¨orslag ur ett teoretiskt perspektiv samt visar att v˚ara f¨orslag f¨orb¨attrar kostnaden f¨or uppdateringsoperationer. Slutligen presenterar vi n˚agra diskussioner och f¨orb¨attringar av IETF MLS-standarden.
Nyckelord: MLS, s¨aker meddelandehantering, kryptografi.
Phillip Gajland (Stockholm / Lausanne - Spring 2020) On Asynchronous Group Key Agreements
Die Sterne reißt’s vom Himmel Das eine Wort: Ich will!”
- Große
Foremost I would like to express my deepest appreciation to my supervisor, Serge Vaudenay, for hosting me at LASEC and making this thesis possible. His remarkable attention to detail and emphasis on quality research leaves me in awe.
I am extremely grateful for the continued guidance that I have received from my supervisor in Sweden, Mats N¨aslund. His deep insights into such a wide range of topics in cryptography have been most valuable. I would also like to thank Johan H˚astad for agreeing to be the examiner of this thesis and for putting me in touch with Mats.
My time at the lab has been most memorable and I would like to thank all my colleagues there for the fruitful conversations. A particular mention goes to Fatih Balli, whom I had the privilege of sharing an office with, as well as Martine Corval for helping me with the various administrative hurdles.
Finally, I thank my parents and family for their continued support.
1 Background 8
1.1 Motivation . . . 8
1.2 Outline . . . 11
1.3 Objectives of Secure Messaging . . . 11
1.4 Security Notions . . . 12
1.5 Relevant Previous Work . . . 13
1.6 Introductory Cryptography . . . 13
1.7 KEM . . . 15
2 Secure Messaging 17 2.1 The Signal Protocol . . . 17
2.2 X3DH . . . 17
2.3 Hash Ratchets & the Double Ratchet Algorithm . . . 19
3 Secure Group Messaging 24 3.1 Messaging Layer Security (MLS) . . . 25
3.2 Asynchronous Ratcheting Trees . . . 28
3.3 Tree KEM . . . 30
3.4 Tripartite Asynchronous Ratcheting Trees . . . 31
4 Discussion 38 4.1 Results and Conclusion . . . 38
4.2 Open Questions for the IETF MLS Standard . . . 39
1.1 PGP hasn’t been adopted by the general public as non-technical users might find it hard to use. Inspecting public keys with gpg, the OpenPGP part of the GNU Privacy Guard (GnuPG). . . 9 1.2 A X.509 self-signed root certificate representing a certificate authority. . . 11 2.1 The three Diffie-Hellman operations making up X3DH are
DH1 = DH(IKA, SPKB), DH2 = DH(EKA, IKB) and DH3 = DH(EKA, SPKB). The shared key k is computed as k = KDF(DH1||DH2||DH3). If the prekey bundle contains a one-time prekey OPKiB, then k is computed as k = KDF(DH1||DH2||DH3||DH4), where DH4= DH(EKA, OPKiB). . . 19 2.2 In a KDF chain, part of the output from a KDF is used as the input to a
following KDF. The other part is used as an output key. Since each output appears random, a KDF chain provides forward secrecy. . . 21 2.3 Diffie-Hellman ratchet. Alice is initialised with Bob’s ratchet pkB0. Alice
performs a DH computation with pkB0 and skA1, the output is used to derive a new sending chain key. The next message sent by Alice includes her pkA
1. Bob then performs a DH computation using pkA1 and skB0. The output is used to derive his new receiving chain key, which is the same as Alice’s sending chain key. Bob then computes a new pair (pkB1; skB1) and derives a new key for his sending chain using pkA
1 and skB
1. . . 22 3.1 Using the Signal protocol for a group of 8 users would require 28 channels. . . 24 3.2 Users A, B and C publish their KeyPackages to a directory . . . 26 3.3 User A creates a group with users B and C. . . 27 3.4 User B sends an update. . . 28 3.5 ART - At each node a public key pk and a secret key sk is stored (separated
by a semicolon). For intermediate nodes, the children’s secret keys are used as the exponents to compute sk. f (·) maps a group element to an integer, f (·) : G → Z/|G|Z, where G is an arbitrary Diffie-Hellman group. The path from C to the root is marked in red and the nodes lying on the copath of C are marked in bold. . . 29 3.6 TreeKEM - At each node a public key pk, a secret key sk and a symmetric
secret is stored (separated by a semicolon). . . 30
3.7 Tripartite ART - At each node a public key pk and a secret key sk is stored (separated by a semicolon). For intermediate nodes, one secret key along with two public keys belonging to the children are used to compute sk. The path from C to the root is marked in red and the nodes lying on the copath of C are marked in bold. . . 33
List of Tables
3.1 Comparison of ART, Tripartite ART and TreeKEM - listing the number of elementary cryptographic operations. Send update denotes the number of operations done by a group member initialising an update. Similarly, process update denotes the number of operations done by each group member to process an update. Transmission indicates the amount of key material that needs to be broadcasted to make an update. Storage indicates the number of public keys need to be stored along the path in order to compute the values stored at intermediate nodes. When updates are processed, on average only a constant number of keys need to be computed, the remaining keys along the path need to be cached though. As usual, (pk; sk) denotes a key pair of an arbitrary public-key cryptosystem and s denotes a symmetric secret . . . . 37
Background
1.1 Motivation
Recently, the desire for secure messaging has gained an increase in popularity, in part due to the Snowden revelations [Macaskill and Dance, 2013]. Messaging applications have progressively been adopting end-to-end security mechanisms to ensure that messages are not accessible to servers involved in the communications, but only to the communicating end parties. Signal, WhatsApp, Telegram and Facebook Secret Conversations are just some of the messaging applications that have implemented such mechanisms, enjoying regular usage by over a billion people worldwide. For communications between two parties, paradigms such as the double ratchet, used in the Signal protocol, provide provably strong security. However, achieving equally strong security that scales well in group settings remains somewhat less well studied and is often neglected in practice. Establishing keys to obtain such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. This motivated the need for the Internet Engineering Task Force (IETF) Messaging Layer Security (MLS) working group. The first continuous group key agreement (CGKA) protocol to be proposed was Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] and formed the basis of TreeKEM [Barnes et al., 2019], the CGKA protocol currently suggested for MLS.
1.1.1 Communication
In this section we give a brief overview of some core protocols and standards used in online communications.
One of the oldest standards for asynchronous messaging is the Simple Mail Transfer Protocol (SMTP) [Postel, 1982]. In essence, it allows email servers to interoperate, enabling Alice to send a mail from her Gmail account to Bob’s Yahoo account. SMTP was
not designed to provide any form of confidentially and mails are sent in plaintext. As a result, email servers have complete access to the content of mails sent via SMTP. In 2013, the Snowden revelations showed that the NSA targeted email servers as part of the PRISM surveillance program [Greenwald, 2013]. In 1991 Phil Zimmermann developed Pretty Good Privacy (PGP), which was later turned into an open standard in RFC4880 [Callas et al., 2007]. PGP significantly improved the security of email communication, as it could be used for signing, encrypting and decrypting emails and files. In 1993 Zimmermann became the subject of a controversial criminal investigation for exporting munitions without a license. PGP never used keys shorter than 128-bits in length, and ciphers with keys longer than 40-bits were consider munitions under US export regulations at the time. However, Zimmermann was able to circumvent regulations by printing the source code to PGP in a book that was the legally exported globally1. Users could then scan and compile the source code to use PGP. The charges against Zimmermann were later dropped. Whilst PGP relies on a so-called web of trust, in which users sign each others keys, another standard, S/MIME (Secure/Multipurpose Internet Mail Extension) depends on a centralised public key infrastructure to manage keys [Ramsdell, 2004]. As a result, S/MIME if often used in large organisations but has not enjoyed widespread adoption amongst the general public. Also PGP has some drawbacks. If Alice’s private key is compromised, all previously sent messages can be decrypted by an adversary.
Furthermore, PGP fails to provide a user-friendly solution for secure communications to non-technical users, as users are expected to understand concepts such as public-key cryptography and key management [See Figure 1.1].
user@host / $ gpg --list-public-keys smith@kth.se peter.smith@epfl.ch pub rsa2048 2018-11-03 [SCEA] [expires: 2021-01-10]
429D86EBCD838B9F45B5AAEA1A233544E7530609
uid [ultimate] Peter Smith (work) <smith@kth.se>
uid [ultimate] Peter Smith (private) <peter@home.se>
pub rsa4096 2019-11-12 [SC] [expires: 2020-10-12]
A75704A2CB6932375B5F30A4B138C0DAB8E41E6B
uid [ultimate] Peter Smith <peter.smith@epfl.ch>
sub rsa4096 2019-11-12 [E] [expires: 2020-10-12]
Figure 1.1: PGP hasn’t been adopted by the general public as non-technical users might find it hard to use. Inspecting public keys with gpg, the OpenPGP part of the GNU Privacy Guard (GnuPG).
Chat Protocols
Chat protocols were originally envisioned to serve low-latency synchronous communications, contrary to mail protocols that were aimed at high-latency asynchronous communications. However, recently this distinction has become less clear, as chat protocols have been designed to operate also in asynchronous settings. One of the first standardised chat protocols was XMPP (Extensible Messaging and Presence Protocol)
1See https://philzimmermann.com/EN/essays/index.html
[Saint-Andre, 2004]. XMPP was designed for “streaming XML elements in order to exchange messages and presence information in close to real time”, and was originally based on the messaging service jabber.org. Whilst XMPP does not provide any form of confidentially [more on this in Section 1.3], XMPP is frequently used over an encrypted channel such as TLS [Saint-Andre, 2011]. Over time, end-to-end security mechanisms have been proposed for XMPP, including Jabber OpenPGP (XEP-0027) and more recently Off-the-Record (OTR) Messaging (XEP-0364) [Muldowney, 2014, Whited, 2019]. OTR is a security enhancement compared to PGP, in that the former provides deniable authentication [more on that in Section 1.4]. The major drawback of OTR is that it is designed for synchronous messaging between two parties and, thus, cannot be used for group messaging or asynchronous messaging. On the other hand, text messages sent with SMS in GSM are only encrypted to the cell phone tower. After being received and decrypted at the tower, messages are sent to mobile carriers and stored in plaintext.
Algorithms
The main public-key algorithms used in the OpenPGP standard are; RSA for encrypting or singing, as well as ElGamal for encrypting and DSA for signing, with most implementations having an upper bound of 4096 bits for public keys. OpenPGP also supports a variety of symmetric-key algorithms, notably; Triple DES, Blowfish, as well as AES with 128, 192 and 256 bit keys [Callas et al., 2007]. As mentioned above, S/MIME relies on a public key certificates, as does TLS/SSL. The X.509 standard defines certificates that bind a public key to an identity. The certificates are either signed by a certificate authority or self-signed [See Figure 1.2].
Certificate:
Data:
Version: 3 (0x2) Serial Number:
04:00:00:00:00:01:15:4b:5a:c3:94 Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Validity
Not Before: Sep 1 12:00:00 1998 GMT Not After : Jan 28 12:00:00 2028 GMT
Subject: C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public-Key: (2048 bit)
Modulus:
00:da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:
...
Exponent: 65537 (0x10001) X509v3 extensions:
X509v3 Key Usage: critical Certificate Sign, CRL Sign X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Subject Key Identifier:
60:7B:66:1A:45:0D:97:CA:89:50:2F:7D:04:CD:34:A8:FF:FC:FD:4B Signature Algorithm: sha1WithRSAEncryption
d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:32:b5:
...
Figure 1.2: A X.509 self-signed root certificate representing a certificate authority.
1.2 Outline
The remainder of this thesis is split into the following sections. We start by introducing some security notions as well as objectives for designing secure messaging protocols. The rest of Chapter 1 is meant to lay the foundations for the cryptography needed to understand the main results. Familiar readers may wish to skip these sections. Chapter 2 covers the most essential paradigms needed for secure messaging. The main contributions of the thesis can be found in Chapter 3, which analyses two different asynchronous group key agreement protocols, namely Asynchronous Ratcheting Trees (ART) and TreeKEM. Furthermore, we present our own asynchronous group key agreement protocol, Tripartite ART. The rest of the chapter is a comparison of specific parts of the protocols, namely the update operation.
Chapter 4 concludes the thesis and offers a summary of our results as well as some discussion.
1.3 Objectives of Secure Messaging
When designing a messaging protocol we wish to have the following desirable properties.
• Alice and Bob should not have to be online at the same time, that is, the protocol is asynchronous.
• Authenticity (of keys): Alice is convinced that she is in fact communicating with Bob and not a malicious Mallory posing as Bob.
• Confidentiality: Alice can communicate with Bob without Eve being able to eavesdrop on their conversation.
• Integrity: Alice can detect whether a message received from Bob has been modified by malicious Mallory.
1.4 Security Notions
First we introduce a few security notions with the help of some informal definitions. These will be useful throughout the remainder of this thesis. The term post-compromise security (PCS), sometimes referred to as self-healing or future secrecy, was first introduced by Cohn- Gordon et al. in 2016. Intuitively, post-compromise security protects sessions from past compromises, whilst forward secrecy protects sessions from future compromises. Even if a party’s secrets have been previously compromised, a protocol between Alice and Bob provides PCS, if communications eventually return to become authenticated and private [Cohn-Gordon et al., 2016]. On the other hand, a protocol between Alice and Bob provides forward secrecy (FS) if previous communications remain private, even if long-term secret keys are compromised in the future. In some situations the mere fact that a conversation between Alice and Bob took place can be undesirable. Therefore, we may want Alice and Bob to be able to plausibly deny the existence of their communication. We say that a protocol between Alice and Bob provides deniability if an attacker cannot obtain a cryptographic proof of communications between the two parties.
At the time of its initial release, more than 20 years ago, Transport Layer Security (TLS) version 1.0 offered standardised means of confidential communication. Whilst the most recent version of TLS enforces forward secrecy trough the use of a ephemeral Diffie-Hellman key exchange [Rescorla, 2018], the protocol still fails to provide other desirable security guarantees. Should a server’s long term private key be exposed, future communications can become exposed. Work by Cohn-Gordon et al. shows how to formalise post-compromise security and proves that TLS version 1.3 lacks PCS [Cohn-Gordon et al., 2016]. The Off-the-Record Messaging protocol provides deniable authentication. That is, messages are not digitally signed such that Carol, a generic third party, can verify them [Borisov et al., 2004]. In fact, anyone could forge messages to make them look as if they came from Alice or Bob. However, whilst communicating with one another, Alice and Bob are provided authenticity and integrity. This is achieved by appending all information necessary to forge messages to encrypted messages. Hence, if an adversary is able to create digitally authentic messages in a conversation, she is also able to forge messages in the conversation. Whilst OTR itself has not enjoyed widespread adoption, some of its techniques can be found in multiple cryptographic constructions, not least in the Signal protocol, and its double-ratcheting algorithm. The Signal protocol, which was developed outside of the academic community, provides both forward secrecy and post-compromise security.
1.5 Relevant Previous Work
Due to its reduced cost, the concept of Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] was the first practically viable proposal to achieve post-compromise security asynchronously in a group setting. The asynchronous key-encapsulation mechanism for tree structures used in MLS finds its roots in ART. At EUROCRYPT 2019 Alwen et al.
gave a formal security analysis of the Signal protocol and showed that Signal provides both post-compromise security and forward secrecy [Alwen et al., 2019a]. Recent work by Alwen et al. showed that TreeKEM had weak forward secrecy. However, we note that the analysis was done on version 7 of MLS, which has evolved considerably since then [Alwen et al., 2019b]. Cremers et al. study the post-compromise security disadvantages with multiple groups [Cremers et al., 2019].
1.6 Introductory Cryptography
We now introduce some fundamental cryptographic primitives that are essential for the remainder of this thesis.
Definition 1 (Symmetric Cryptosystem). We define a symmetric cryptosystem to be the tuple of two algorithms (Enc, Dec):
• Enc(k, x) encrypts the plaintext x using the key k.
• Dec(k, c) decrypts the ciphertext c using the key k.
Definition 2 (Correctness of a Symmetric Cryptosystem). A symmetric cryptosystem (Enc, Dec) is correct if
∀x ∈ P, ∀k ∈ K Dec(k, Enc(k, x)) = x
where P and K are the set of plaintexts and the set of keys respectively.
Definition 3 (Public-Key Cryptosystem). We define a public-key cryptosystem to be the tuple of three algorithms (Gen, Enc, Dec):
• Gen(1k) generates a key pair (sk, pk), where sk and pk denote the secret key and public key respectively and k is the security parameter.
• Enc(pk, x) encrypts the plaintext x using the public key pk.
• Dec(sk, c) decrypts the ciphertext c using the secret key sk.
Definition 4 (Correctness of a Public-Key Cryptosystem). A public-key cryptosystem (Gen, Enc, Dec) is correct if
∀x ∈ P Dec(sk, Enc(pk, x)) = x, where (pk, sk) ← Gen(1k) and P is the set of plaintexts.
In Section 3.3, we will need an updatable public-key cryptosystem in order to achieve forward secrecy [Alwen et al., 2019b, Jost et al., 2019].
Definition 5 (Updatable Public-Key Cryptosystem). We define an updatable public-key cryptosystem to be the tuple of three algorithms (Gen, Enc, Dec):
• Gen(sk0) outputs an initial public key pk0, given a uniformly random key sk0.
• Enc(pk, x) encrypts the plaintext x using the public key pk and outputs a new public key pk0.
• Dec(sk, c) decrypts the ciphertext c using the secret key sk and outputs a new secret key sk0
Definition 6 (Correctness of a Updatable Public-Key Cryptosystem). An updatable public-key cryptosystem (Gen, Enc, Dec) is correct if ∀xi∈ P and ∀sk0∈ K
P
pk0← Gen(sk0); (ci, pki) ← Enc(pki−1, xi);
(x0i, ski) ← Dec(ski−1, ci) : xi= x0i
= 1,
where P and K are the set of plaintexts and the set of keys respectively.
Informally, a key derivation function (KDF) generates a random key from a secret value and a public value such as a salt, with the help of a standard hash function. Let KDF denote a HMAC-based Extract-and-Expand Key Derivation Function (HKDF) as defined in RFC5869 [Krawczyk and Eronen, 2010].
Establishing a shared secret over an insecure channel is central to a vast number of cryptographic protocols. The Diffie-Hellman Key Exchange [Diffie and Hellman, 1976]
provides an elegant solution to this problem and is widely used in practice.
Definition 7 (Diffie-Hellman Key Exchange). Let G be a cyclic group of prime order p with a generator g. Alice chooses her secret key skA∈ Z∗pand computes her public key pkA= gskA. Then Bob chooses his secret key skB ∈ Z∗p and computes his public key pkB = gskB. After exchanging their public keys pkA and pkB, Alice and Bob check that pkB ∈ hgi \ {1} and pkA∈ hgi \ {1}. Finally, they can compute a shared secret key k
k = KDF(gskAskB)
= KDF (pkB)skA
= KDF (pkA)skB . Elliptic curve cryptography
The Diffie-Hellman key exchange is simplest over a finite cyclic group such as Z∗p, where p is a prime. However, in practice the exchange is often done over an elliptic curve group, since this requires shorter keys for the same level of security. An elliptic curve E, over the finite field Fp, is a plane algebraic curve defined by an equation of the form
y2= x3+ ax + b,
where a, b ∈ Fp. Furthermore, an elliptic curve is required to be non-singular, i.e. the discriminant
∆ = (4a3+ 27b2)
is not equal to zero.
Definition 8 (Elliptic Curve Diffie-Hellman Key Exchange). Let the sextuple (p, a, b, G, n, h)
denote the elliptic curve domain parameters over Fp, where p is prime and specifies the finite field Fp, a, b ∈ Fp specify the curve E(Fp) defined by the equation
E : y2≡ x3+ a · x + b mod p,
G = (xG, yG) is a base point on E(Fp), n is a prime denoting the order of G, and the integer h which is the cofactor h = 1n|E(Fp)|. The cofactor gives the number of cyclic subgroups of E, each consisting of n/h points.
Alice chooses her secret key dA∈ [1, n − 1] and computes her public key, which is represented by a point QA= dA· G. Then Bob chooses his secret key dB ∈ [1, n − 1] and computes his public key, which is represented by a point QB= dB· G. After exchanging their public keys QA and QB, Alice and Bob compute the points (xA, yA) = dA· QB and (xB, yB) = dB· QA
respectively. Finally, since
(xA, yA) = dA· QB
= dA· dB· G
= dB· dA· G
= dB· QA = (xB, yB) they can compute a shared secret key k = KDF(xA) = KDF(xB).
Definition 8 is important in Section 3.4, where we introduce our own asynchronous group key agreement protocol. Additionally, the elliptic curve Diffie-Hellman key exchange, relies on another version of the discrete logarithm problem, that is assumed to be hard.
Definition 9 (Elliptic Curve Discrete Logarithm Problem). Given an elliptic curve E over Fp and points P, Q ∈ E(Fp), where Q lies in the subgroup generated by P , the elliptic curve discrete log problem is to find n ∈ Z such that n · P = Q.
1.7 KEM
Key Encapsulation Mechanisms (KEM) provide a method by which symmetric keys can be protected with the help of a public-key cryptosystem. Using key encapsulation, we essentially get two independent layers; one public-key and one symmetric-key layer.
Definition 10 (KEM). We define a KEM to be the tuple of three algorithms (Gen, Encaps, Decaps):
• Gen(1k) probabilistically generates a key pair (sk, pk), where sk and pk denote the secret key and public key respectively and k is the security parameter.
• Encaps(pk) probabilistically generates a symmetric key k and a ciphertext c that encapsulates k using a public key pk.
• Decaps(sk, c) deterministically regenerates a symmetric key k from a ciphertext c using a secret key sk.
Definition 11 (Correctness of a KEM). A key encapsulation mechanism (Gen, Encaps, Decaps) is correct if for all key pairs (sk, pk) generated by Gen the following condition holds: if (c, k) is the output of Encaps(pk) then Decaps(sk, c) = k.
We envision a KEM using Diffie-Hellman between Alice and Bob. Alice generates a symmetric key k and a ciphertext c that encapsulates k, using Bob’s public key pkB:
(c, k) = Encaps(pkB).
Bob regenerates k from c using his secrete key skB: k = Decaps(skB, c).
Alice encrypts with Bob’s public key pkB= (p, q, g, y = gx) and Bob decrypts with his secret key skB= (p, q, g, x):
Encaps(pkB) r ←$[0, q − 1]
c ← gr mod p z ← yr mod p k ← KDF(c||z) return (c, k)
Decaps(skB, c) z ← cx mod p k ← KDF(c||z) return k
Further cryptographic primitives will be introduced when and where necessary.
Secure Messaging
In this Chapter the Signal protocol and some of its underlying building blocks are introduced.
These are used to construct multiple other secure messaging protocols.
2.1 The Signal Protocol
The Signal protocol finds its roots in industry and has enjoyed widespread adoption amongst multiple messaging platforms. WhatsApp, Facebook Messenger Secret Conversation, as well as the Signal App currently use some form of the Signal protocol [WhatsApp, 2016, Facebook, 2017, Marlinspike and Perrin, 2016]. It is important to note that Facebook does not encrypt messages by default and messages are sent in plain text.
However, users can enable so-called Secret Conversations to benefit from the security guarantees provided by the Signal protocol. Nevertheless, there are some significant drawbacks in Facebook’s implementation of the Signal protocol. Most importantly, metadata including delivery and read receipts are not encrypted. It is unclear, why this is the case. Facebook simply states that conversation metadata does not contain message plaintext [Facebook, 2017]. We postulate this to be motivated by economic incentives. In his autobiography, Permanent Record, Edward Snowden makes a point of emphasising the importance of metadata [Snowden, 2019]. Whilst most messages exchanged online do not include state secrets, metadata is of significant interest to adversaries, due to its privacy implications.
The Signal protocol relies on two building blocks outlined in the remainder of this chapter, namely the Double Ratchet Algorithm and the so-called extended triple Diffie-Hellman (X3DH) key agreement protocol.
2.2 X3DH
The Extended Triple Diffie-Hellman (X3DH) key agreement protocol uses a sequence of Diffie-Hellman computations to establish a shared key between two parties [See Figure 2.1].
The protocol works in an asynchronous setting, meaning Alice and Bob do not have to be online at the same time. However, it does require the parties have previously published some information on the server. After authenticating each other, based on their public keys, Alice and Bob enjoy both forward secrecy and deniability as a result of X3DH. In essence, X3DH consists of three stages.
1. Bob publishes the following public keys to the server;
• identity key IKB,
• signed prekey SPKB,
• prekey signature SigIKB(SPKB),
• and a set of one-time prekeys {OPK1B, . . . , OPKnB}, where each of the keys are DH keys of the form gx.
2. Alice receives Bob’s public keys in a so-called ”prekey bundle” from the server and uses it to send an initial message to Bob.
• The OPKiB sent in the bundle is then deleted from the server. If there are no more one-time prekeys remaining, Alice will receive a prekey bundle without a one-time prekey.
• Alice verifies Bob’s prekey signature SigIKB(SPKB) and generates a temporary key pair using an ephemeral public key EKA.
• Alice computes a sequence of Diffie-Hellman values and uses the concatenation of their outputs as the input to a KDF in order to derive a share secret key k.
k = KDF DH(IKA, SPKB) || DH(EKA, IKB) || DH(EKA, SPKB) If the prekey bundle contains a one-time prekey
k = KDF DH1|| DH2|| DH3|| DH4, where
DH1= DH(IKA, SPKB) DH2= DH(EKA, IKB) DH3= DH(EKA, SPKB) DH4= DH(EKA, OPKiB)
• Finally, Alice sends Bob a message stating her identity key IKA and ephemeral key EKA as well as which of Bob’s prekeys she used.
3. Bob receives and processes Alice’s message.
• From the message Bob receives Alice’s identity key IKAand ephemeral key EKA.
• In the same way that Alice did, Bob uses his corresponding secret keys to compute the shared secret k.
Alice
IKA
EKA SPKB
IKB Bob
OPKiB 1
2 3 4
Figure 2.1: The three Diffie-Hellman operations making up X3DH are DH1 = DH(IKA, SPKB), DH2 = DH(EKA, IKB) and DH3 = DH(EKA, SPKB). The shared key k is computed as k = KDF(DH1||DH2||DH3). If the prekey bundle contains a one-time prekey OPKiB, then k is computed as k = KDF(DH1||DH2||DH3||DH4), where DH4= DH(EKA, OPKiB).
A trivial denial of service attack on X3DH would be to query the server for Bob’s OPKs until these have been exhausted. That is why the protocol is modified to compute the shared key k as k = KDF(DH1||DH2||DH3), if no one-time prekey is in the prekey bundle.
However, we show that one-time prekeys are needed in order to provide a form of forward secrecy. Suppose Alice sends a message to Bob. Then assume that both Alice and Bob delete the message. Now, we are interested in the time at which all the key material needed to decrypt a transcript of network packets sent will be deleted. After sending a message to Bob, Alice will immediately erase her ephemeral key EKA. Thus, the set of keys {IKA, EKA} required by Alice to decrypt the transcript is no longer complete. Since the protocol is asynchronous and Bob may not be online, he will not delete anything. However, once Bob receives and processes the message, he will delete his one-time prekey OPKiB, and the set of keys {IKB, SPKB, OPKiB} required by Bob to decrypt the transcript is no longer complete.
Bob’s IKB is never meant to be deleted, and his SPKB is only intended to be rotated occasionally so that delayed messages can be processed. In the event that no OPKiBis used, {IKB, SPKB} will be sufficient for Bob to decrypt a transcript of network packets sent. Thus, forward secrecy would be lost.
2.3 Hash Ratchets & the Double Ratchet Algorithm
In this Section we introduce some helpful definitions to more formally capture properties of cryptographic hash functions.
Definition 12 (One-Way Function). A function ensemble {fn: {0, 1}n→ {0, 1}m(n)}n∈N is said to be one-way if for all polynomial time adversaries A, a uniformly random x ∈ {0, 1}n and for all sufficiently large n
P[A(fn(x)) = x0∧ fn(x0) = fn(x)] = negl(n) ,
where fn is polynomial-time computable and negl(n) < 1/nc for every constant c > 0.
Definition 13 (Second-Preimage Resistance). A function ensemble {fn : {0, 1}n → {0, 1}m(n)}n∈N is said to be second-preimage resistant if for all polynomial time adversaries A, a uniformly random x ∈ {0, 1}n and for all sufficiently large n
P[A(fn(x)) = x0∧ x0 6= x ∧ fn(x0) = fn(x)] = negl(n) ,
where fn is polynomial-time computable and negl(n) < 1/nc for every constant c > 0.
A hash function is collision resistant if it is hard to find two different inputs that hash to the same output. On a side note, we observe that according to Definition 14, SHA-256 is clearly not collision resistant. A simple argument based on the pigeonhole principle, shows that every hash function with more inputs than outputs will necessarily have collisions. Treating the function as a black box, it is assumed that finding collisions requires about 2n/2 chosen inputs, i.e. meeting the birthday-bound for a completely random function, which is the best one can hope for. However, this is an asymptotic notion, and in practice SHA-256 is collision resistant.
Definition 14 (Collision Resistance). A function ensemble {fn: {0, 1}n→ {0, 1}m(n)}n∈N is said to be collision resistant if for all polynomial time adversaries A, a uniformly random x ∈ {0, 1}n and for all sufficiently large n
P[A(n) = (x, x0) ∧ x 6= x0∧ fn(x0) = fn(x)] = negl(n) ,
where fn is polynomial-time computable and negl(n) < 1/nc for every constant c > 0.
Cryptographic hash functions are one-way functions that are both second-preimage resistant and collision resistant. However, hash functions are often modelled with help of random oracles, which in practice are replaced by a standardised hash function such as SHA-256.
The term ratchet comes from the mechanical device that only allows movement in one direction, whilst preventing movements in the reverse direction. Similarly, hash ratchets make use of hash functions, meaning the output of a hash ratchet cannot efficiently be reversed. Hash ratchets form an essential building block in the Double Ratchet Algorithm and other cryptographic constructions, providing both forward secrecy and post-compromise security.
Double Ratchet Algorithm
Given a shared secret, the Double Ratchet algorithm Marlinspike and Perrin [2016] is used by two parties to exchange messages whilst ensuring both forward secrecy and post-compromise security. After agreeing on a shared secret through the help of a key exchange such as X3DH,
the Double Ratchet is used to send and receive encrypted messages. New keys are derived from previous keys for every message that is sent. This is called a KDF chain [see Figure 2.2] and ensures that earlier keys cannot be recovered.
KDF KDF key
Input
Chain key Output key
Input KDF
Chain key Output key
Input KDF
Chain key Output key
Figure 2.2: In a KDF chain, part of the output from a KDF is used as the input to a following KDF. The other part is used as an output key. Since each output appears random, a KDF chain provides forward secrecy.
The algorithm uses two different types of ratchets, namely a Diffie-Hellman ratchet and a symmetric-key ratchet. Sending and receiving messages requires a symmetric-key ratchet, whose output keys are used directly to encrypt each message with a unique message key.
Alice and Bob each store a KDF key for their sending and receiving chains. For the symmetric-key ratchet, the ratchet advances by one step as messages are sent/received and the output keys are used to encrypt/decrypt messages. Although the symmetric-key ratchets ensure forward secrecy, should one party’s sending and receiving chain keys be compromised, an adversary will be able to compute future message keys and decrypt following messages. Hence, an extra mechanism is needed to provide post-compromise security. For this the Double Ratchet makes uses of a Diffie-Hellman ratchet [see Figure 2.3] which updates chain keys based on Diffie-Hellman outputs. Alice and Bob both generate a (sk, pk) pair each, which becomes the ratchet key pair. Every message sent also contains the sender’s current pk. Once a message has been received, the DH ratchet is incremented by one, replacing the local key pair with the new one.
pkB0
DH Sending chain
skA1; pkA1
= Receiving chain DH
pkB0; skB0
pkA1
Sending chain DH
pkB
1; skB
1
Receiving chain = DH
pkB
1
DH Sending chain
skA2; pkA2
= Receiving chain DH
pkA2
Sending chain DH
pkB
2; skB
2
Alice Bob
Figure 2.3: Diffie-Hellman ratchet. Alice is initialised with Bob’s ratchet pkB0. Alice performs a DH computation with pkB0 and skA1, the output is used to derive a new sending chain key. The next message sent by Alice includes her pkA
1. Bob then performs a DH computation using pkA1 and skB0. The output is used to derive his new receiving chain key, which is the same as Alice’s sending chain key. Bob then computes a new pair (pkB1; skB1) and derives a new key for his sending chain using pkA
1 and skB
1.
However, Figure 2.3 hides some details, in that the DH outputs are used as KDF inputs to a root chain. The KDF output from the root chain is then used as sending and receiving keys. In summary, Alice and Bob each store a KDF key for three KDF chains; a sending chain (symmetric-key ratchet) and receiving chain (symmetric-key ratchet) [see Figure 2.2], as well as a root chain (DH-ratchet) [see Figure 2.3].
Secure Group Messaging
A group of users that wish to send each other encrypted messages need a mechanism by which they can establish symmetric encryption keys. The Double Ratchet Algorithm [Marlinspike and Perrin, 2016], proposed by Marlinspike and Perrin often emerges as a popular solution for groups of size two, and has been well studied [Cohn-Gordon et al., 2017]. Whilst the Double Ratchet offers both FS and PCS, it is still efficient enough for heavy use over low- bandwidth networks. However, in a group setting Signal would require the setup of pairwise channels between each member of the group. Similar to the complete graph on n vertices Kn
requiring n2 edges, a group of n members would require n(n−1)2 secure channels [See Figure 3.1]. Clearly this is not practical for larger group sizes, since it scales in Θ(n2). Whilst generally not desirable, introducing a trusted third party would reduce the complexity of this problem to be linear with respect to the group size.
Figure 3.1: Using the Signal protocol for a group of 8 users would require 28 channels.
Another approach is to use sender keys only, essentially a single ratchet as opposed to a double ratchet. Users send their messages to the server where they are then broadcasted to the rest of the group. Whilst this method scales linearly with respect to the size of the group, it doesn’t provide post-compromise security.
3.1 Messaging Layer Security (MLS)
In an attempt to fix the aforementioned shortcomings, as well as offering the possibility of interoperability between different messaging services, the MLS protocol enables asynchronous key establishment whilst providing both post-compromise security and forward secrecy. Due to the use of tree structures, MLS enables users to derive and update shared keys at a cost that scales logarithmically with respect to the group size. The first asynchronous group key establishment protocol to provide post-compromise security was Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018]. Cohn-Gordon et al.’s seminal work lends many of its ideas to MLS and is described in Section 3.2.
3.1.1 Background
Whilst a lot of the work surrounding MLS is still ongoing with many issues still unaddressed, the purpose of MLS is defined as follows. MLS is not intended to be a fully fledged instant messaging protocol, but rather to be embedded in an existing protocol such as XMPP [Saint- Andre, 2011]. Furthermore, an internet threat model is assumed, that is, MLS should provide security against both passive and active network adversaries, providing forward secrecy as well as post compromise security. From an architectural point of view, a service provider implementing MLS will present two abstract services allowing group members to send and receive messages securely, as well as a directory.
• An Authentication Service (AS) responsible for maintaining long term identities of users as well as issuing credentials enabling users to authenticate each other. In essence a certificate authority.
• A Delivery Service (DS) responsible for receiving and redistributing messages amongst group members. The DS also stores and delivers initial public key material required by clients in order to proceed with the group secret key establishment process.
3.1.2 Operations
Throughout the life cycle of a group, three major operations take place.
• Add: A current member adds a new member to the group, giving rise to a new group secret.
• Update: A member updates her secret, giving rise to a new group secret.
• Remove: A member is removed from the group, giving rise to a new group secret.
Before a group is created, users publish their KeyPackages to a directory provided by the messaging service. These are used to introduce a user to a new group [see Figure 3.2].
A B C Directory Group Channel
KeyPackageA
KeyPackageB
KeyPackageC
Figure 3.2: Users A, B and C publish their KeyPackages to a directory
When a user A wants to create a group with B and C, A first downloads the KeyPackages of B and C. A then initialises a group state containing only herself and uses the KeyPackages to compute Welcome and Add messages in order to add B and C. The Welcome messages are sent directly to the new members, whereas the Add messages are broadcast to the group, and processed in sequence by B and C. Messages received before a client has joined the group are ignored. Only after A has received its Add messages back from the server does A update its state to reflect their addition [see Figure 3.3].
A B C Directory Group Channel KeyPackageB
KeyPackageC
state.init()
Add(A->AB) Commit(Add) Welcome(B)
state.init()
Add(A->AB) Commit(Add)
state.add(B) state.join()
Add(AB->ABC) Commit(Add) Welcome(C)
state.init()
Add(AB->ABC) Commit(Add)
state.add(C) state.add(C) state.join() -
- - - - - - - - - - -
Figure 3.3: User A creates a group with users B and C.
To provide forward secrecy and post-compromise security of messages, members periodically update their secrets. Any member can do this by generating a fresh KeyPackage and sending an Update message followed by a Commit message. Once all group members have processed an update, the group’s shared secret will be unknown to an adversary that had compromised the sender’s prior secret [see Figure 3.4]. It is left to the application to determine a policy for regularly sending Update messages. This policy can be as strong as requiring an Update and Commit after each application message, or weaker, such as once every hour, day, etc.
A B . . . Z Directory Group Channel Update(B)
Commit(Update)
Update(B) Commit(Update)
state.update(B) state.update(B) state.update(B) -
- -
Figure 3.4: User B sends an update.
Sending Messages
Messages are encrypted using a group secret I and are then broadcasted to the group. Thus, messages are authenticated to some degree, in that only group members can derive I. To ensure strong authentication messages could of course be signed by members. However, this would of course preclude any form of deniability [this remains an open issue in MLS].
Furthermore, messages remain secret from non-group members, since only group members can derive I and decrypt the messages.
Of the aforementioned operations, our work mainly focuses on the update operation. In it’s essence, an update generates new key material and gives rise to a new group secret. Thus, it is an essential part in providing post-compromise security.
3.2 Asynchronous Ratcheting Trees
Asynchronous Ratcheting Trees (ART) were first proposed by Cohn-Gordon et al. in 2018 [Cohn-Gordon et al., 2018]. ART allow users to agree on a shared group secret that is derived from a sequence of Diffie-Hellman key exchanges, even if users are not online at the same time. We note the similarity to Merkle Trees [Merkle, 1988], which enable the efficient verification of changes to a large data structures. In essence, Merkle Trees are binary trees in which every leaf node is labelled with the hash of a data block, and every non-leaf node is labelled with the hash of its child nodes.
Similarly, ART is based on left-balanced binary trees, where each leaf node represents a member of the group. We note that the number of members in a group does not necessarily have to be a power of two. However, we do maintain a left-balanced binary tree, to ensure that all members agree on the data structure. Given a list of n users, there is a unique left-balanced binary tree structure with these users as leaves.
In ART, each group member is required to store their public-private key pair (pk, sk), the group secret I, as well as the public keys stored on the copath {pk1, . . . , pklog
2(n)} to the root.
pkO = gskO; skO= f gskMskN
= f pkskMN
= f pkskNM
pkM = gskM; skM = f gskIskJ
= f pkskIJ
= f pkskJI
pkI = gskI; skI = f gskAskB
= f pkskAB
= f pkskBA
pkA; skA pkB; skB
pkJ= gskJ; skJ = f gskCskD
= f pkskCD
= f pkskDC
pkC; skC pkD; skD
pkN = gskN; skN = f gskKskL
= f pkskKL
= f pkskLK
K
E F
L
G H
Figure 3.5: ART - At each node a public key pk and a secret key sk is stored (separated by a semicolon). For intermediate nodes, the children’s secret keys are used as the exponents to compute sk. f (·) maps a group element to an integer, f (·) : G → Z/|G|Z, where G is an arbitrary Diffie-Hellman group. The path from C to the root is marked in red and the nodes lying on the copath of C are marked in bold.
In order to achieve post-compromise security a compromised group member needs to initiate an update, without the interference of an adversary, giving rise to a new group secret. We refer to Figure 3.5 for the following example. For C to perform an update, C computes a new pk0C; sk0C pair as well as all the new keys on the path from C to the root, i.e. pk0J = gsk0J; sk0J = f pksk
0 C
D , pk0M = gsk0M; sk0M = f pksk
0 J
I and pk0O = gsk0O; sk0O = f pksk
0 M
N . This requires that C knows the public keys on its copath, pkD, pkI and pkN.
Once C has computed the new group secret sk0O, C must distribute the newly computed public keys pk0C, pk0J, pk0M and pk0O so that the other group members can process the update and compute the new group secret sk0O. To compute sk of a non-leaf node, a member must know the sk of one of that node’s children and the pk to the other child. Thus, in order to compute the group secret a member must know one sk, namely its own, and all the pks along its copath to the root.
For A to process the update made by C and derive the new group secret, A must compute all (pk, sk) pairs along its path to the root with help of the public keys stored on its copath, i.e.
pkI = gskI; skI = f pkskBA, pk0M = gsk0M; sk0M = f pk0skJ I and pk0O= gsk0O; sk0O= f pkskN0M.
Sending an update requires a member to generate dlog2(n)e new key pairs and distribute dlog2(n)e new public keys. Processing an update requires a member to perform dlog2(n)e operations in the worst case, and 2 on average [See Section 3.4.1 for details], in order to
compute the new group secret.
3.3 Tree KEM
Currently TreeKEM is the asynchronous group key establishment mechanism used in MLS.
Similar to ART, TreeKEM uses a left-balanced binary tree. However, each node stores secret and public key material from an arbitrary updatable public key cryptosystem [see Definition 5] as well as a symmetric secret referred to as a path secret. The reason we need an updatable public key cryptosystem is to achieve forward secrecy and stems from the work done by Alwen et al. based on [Jost et al., 2019]. Essentially, by using an updatable public key cryptosystem, the threat of old key material being used to circumvent update operations, is reduced.
(pkO, skO) ← DKP(sO) sO← KDF(sM)
(pkM, skM) ← DKP(sM) sM ← KDF(sJ)
(pkI, skI) ← DKP(sI) sI ← KDF(sA)
sA= KDF(skA) pkA; skA
sB= KDF(skB) pkB; skB
(pkJ, skJ) ← DKP(sJ) sJ← KDF(sC)
sC= KDF(skC) pkC; skC
sD= KDF(skD) pkD; skD
(pkN, skN) ← DKP(sN) sN ← KDF(sK)
K
E F
L
G H
Figure 3.6: TreeKEM - At each node a public key pk, a secret key sk and a symmetric secret is stored (separated by a semicolon).
As in the previous schemes, TreeKEM requires compromised users to initiate an update, without the interference of an adversary, to achieve post-compromise security. This gives rise to a new group secret. We notice that unlike ART, the keys at each internal node only depend on one of the children as opposed to both. This particular design choice has not been documented to the author’s knowledge. However, it seems plausible to postulate this being due to post-compromise security requiring a compromised user to make an update. Hence, a newly generated key would not benefit from depending on another user’s input, whose key has not been compromised. The symmetric secret sx at the non-leaf node x is computed as sx= KDF(sx−1). The pkx; skx pair is computed as (pkx, skx) = DKP(sx), where DKP is a function that produces an asymmetric key pair for the KEM from a symmetric secret.
We refer to Figure 3.6 for the following example. For C to perform an update, C computes a new pk0C; sk0C pair as well as the new symmetric secret s0C = KDF(sk0C). Furthermore, C computes all the new key material from C to the root, i.e. s0J= KDF(s0C) and (pk0J, sk0J) = DKP(s0J), s0M = KDF(s0J) and (pk0M, sk0M) = DKP(s0M) and finally s0O = KDF(s0M) and (pk0O, sk0O) = DKP(s0O). For each node vη on the copath from C to the root, the symmetric secret stored at the parent vη+1 is encrypted using the public key at vη. I.e. C computes the following cipher texts; cD = Enc(pkD, s0J), cI = Enc(pkI, s0M) and cN = Enc(pkN, s0O).
This requires that C knows the public keys on its copath, pkD, pkI and pkN. Once C has computed the new group secret sk0O, C must distribute the cipher texts cD, cI and cN so that the other group members can process the update and compute the new group secret sk0O. For A to process the update made by C and derive the new group secret, A must update the new (pk, sk) pairs and s values along its path using the cipher text sent by C.
First, A can decrypt cI = Enc(pkI, s0M) using skI, which in turn is computed using sA. Then A computes (pk0M, sk0M) = DKP(s0M) and finally s0O= KDF(s0M) and (pk0O, sk0O) = DKP(s0O).
Sending an update requires a member to generate dlog2(n)e new key pairs and symmetric secrets, perform dlog2(n)e encryptions, and distribute dlog2(n)e cipher texts. Processing an update requires a member to perform one decryption and compute dlog2(n)e key pairs and symmetric secrets in the worst case, in order to compute the new group secret. On average, 2 key pairs and 2 symmetric secrets need to be computed to process an update [See Section 3.4.1 for details].
3.4 Tripartite Asynchronous Ratcheting Trees
In this section we introduce a novel asynchronous group key establishment mechanism based on ART and a tripartite Diffie-Hellman key exchange as proposed by Joux [Joux, 2000]. In its essence the tripartite Diffie-Hellman key exchange allows for three parties, Alice, Bob and Charlie to agree on a shared secret over an insecure channel using a public key cryptosystem based on Elliptic Curve Diffie-Hellman [See Def. 3 and Def. 8]. To the author’s knowledge there are currently no generalisations of the Diffie-Hellman key exchange for more than three parties that require only a single round of communication. A protocol taking more than one round would require parties to be connected at the same time making it impractical.
Multilinearity
Let G1, . . . , Gn and GT be additive cyclic groups of prime order q. In cryptography, a n- multilinear map is a function e : G1× · · · × Gn → GT such that for any integers a1, . . . , an and elements gi∈ Gi,
e(g1a1, . . . , gnan) = e(g1, . . . , gn)Qni=1ai.
In addition, e(·) should be efficiently computable and satisfy some security properties. There exist constructions of cryptographic 2-multilinear maps, known as bilinear maps. However, the problem of constructing n-multilinear maps for n > 2 appears to be much more difficult and the security of the proposed candidates is still unclear. [Boneh and Silverberg, 2003] In the case of bilinear maps (or pairings), for our purposes, the following definition is relevant.
Let G1, G2 be two additive cyclic groups of prime order p, and GT another cyclic group
