On Asynchronous Group Key Agreements Tripartite Asynchronous Ratchet Trees

Home , Algebraic Eraser, Double Ratchet Algorithm, GNU Privacy Guard, Pretty Good Privacy, Secure messaging, Signal (software)

DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020

PHILLIP GAJLAND

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

On Asynchronous Group Key Agreements

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 Abstract

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

1 Sammanfattning

Amnet¨ om säkra meddelanden har p˚a senare tid skapat uppmärksamhet inom kryptografiska samfundet. Förkommunikationer mellan tv˚aparter ger paradigmer s˚asom Double Ratchet, som används i Signal-protokollet, starka bevisbara säkerhetsgarantier som forward secrecy och post-compromise security. Variationer av Signal-protokollet används mycket i praktiken och ärinbäddadei flera välkändameddelandetjänsters˚asomSignal, WhatsApp och Facebook Secret Conversations. Däremotärprotokoll som erbjuder lika starka garantier och som skalar väli gruppsituationer n˚agotmindre studerade och ofta eftersatta i praktiken. Detta motiverade behovet av arbetsgruppen IETF Messaging Layer Security (MLS). Det förstakontinuerliga gruppnyckelprotokollet (CGKA) som föreslogsvar Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] och lade grunden för TreeKEM [Barnes et al., 2019], det CGKA-protokoll som förnärvarande föreslagitsförMLS. I detta examensarbete föresl˚arvi ett nytt asynkront gruppnyckelprotokoll baserat p˚aen en-rundad Tripartite Diffie–Hellman [Joux, 2000]. Vidare visar vi att v˚artprotokoll kan generaliseras förn-ary trädmed hjälpav ett en-rundat (n + 1)-vägDiffie-Hellman nyckelutbyte, baserat p˚aen multilinjärmappning [Boneh and Silverberg, 2003]. Vi analyserar ART, TreeKEM och v˚araförslag ur ett teoretiskt perspektiv samt visar att v˚araförslag förbättrar kostnaden föruppdateringsoperationer. Slutligen presenterar vi n˚agradiskussioner och förbättringarav IETF MLS-standarden.

Nyckelord: MLS, s¨aker meddelandehantering, kryptograﬁ.

Phillip Gajland (Stockholm / Lausanne - Spring 2020) On Asynchronous Group Key Agreements

2 ”Ich will! – Das Wort ist m¨achtig, Spricht’s einer ernst und still; Die Sterne reißt’s vom Himmel Das eine Wort: Ich will!” - Große

3 Acknowledgements

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˚astadfor 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 oﬃce 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.

4 Contents

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

5 List of Figures

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 Diﬃe-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 i prekey OPKB, then k is computed as k = KDF(DH1||DH2||DH3||DH4), i where DH4 = DH(EKA, OPKB)...... 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 Diﬃe-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 pkA1 .

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 pkA1 and skB1 ...... 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 Diﬃe-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

6 LIST OF TABLES PKG

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

7 Chapter 1

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 ﬁrst 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.

Email 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

8 CHAPTER 1. BACKGROUND PKG 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 [email protected] [email protected] pub rsa2048 2018-11-03 [SCEA] [expires: 2021-01-10] 429D86EBCD838B9F45B5AAEA1A233544E7530609 uid [ultimate] Peter Smith (work) uid [ultimate] Peter Smith (private)

pub rsa4096 2019-11-12 [SC] [expires: 2020-10-12] A75704A2CB6932375B5F30A4B138C0DAB8E41E6B uid [ultimate] Peter Smith 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 ﬁnd 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 ﬁrst standardised chat protocols was XMPP (Extensible Messaging and Presence Protocol)

1See https://philzimmermann.com/EN/essays/index.html

9 CHAPTER 1. BACKGROUND PKG

[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 conﬁdentially [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 Oﬀ-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].

10 CHAPTER 1. BACKGROUND PKG

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 certiﬁcate representing a certiﬁcate 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.

11 CHAPTER 1. BACKGROUND PKG

• Authenticity (of keys): Alice is convinced that she is in fact communicating with Bob and not a malicious Mallory posing as Bob.

• Conﬁdentiality: 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 modiﬁed 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.

12 CHAPTER 1. BACKGROUND PKG

1.5 Relevant Previous Work

Due to its reduced cost, the concept of Asynchronous Ratcheting Trees (ART) [Cohn-Gordon et al., 2018] was the ﬁrst practically viable proposal to achieve post-compromise security asynchronously in a group setting. The asynchronous key-encapsulation mechanism for tree structures used in MLS ﬁnds 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.

Deﬁnition 1 (Symmetric Cryptosystem). We deﬁne 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.

Deﬁnition 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.

Deﬁnition 3 (Public-Key Cryptosystem). We deﬁne 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.

Deﬁnition 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].

13 CHAPTER 1. BACKGROUND PKG

Deﬁnition 5 (Updatable Public-Key Cryptosystem). We deﬁne 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

Deﬁnition 6 (Correctness of a Updatable Public-Key Cryptosystem). An updatable public-key cryptosystem (Gen, Enc, Dec) is correct if ∀xi ∈ P and ∀sk0 ∈ K pk0 ← Gen(sk0); (ci, pki) ← Enc(pki−1, xi); P 0 0 = 1, (xi, ski) ← Dec(ski−1, ci): xi = xi 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.

Deﬁnition 7 (Diﬃe-Hellman Key Exchange). Let G be a cyclic group of prime order p with

∗ skA a generator g. Alice chooses her secret key skA ∈ Zp and computes her public key pkA = g . ∗ skB Then Bob chooses his secret key skB ∈ Zp and computes his public key pkB = g . 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 )

skA = KDF (pkB)

skB = KDF (pkA) .

Elliptic curve cryptography

∗ The Diffie-Hellman key exchange is simplest over a finite cyclic group such as Zp, 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)

14 CHAPTER 1. BACKGROUND PKG is not equal to zero.

Deﬁnition 8 (Elliptic Curve Diﬃe-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 1 h which is the cofactor h = n |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).

Deﬁnition 8 is important in Section 3.4, where we introduce our own asynchronous group key agreement protocol. Additionally, the elliptic curve Diﬃe-Hellman key exchange, relies on another version of the discrete logarithm problem, that is assumed to be hard.

Deﬁnition 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 ﬁnd 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.

Deﬁnition 10 (KEM). We deﬁne 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.

15 CHAPTER 1. BACKGROUND PKG

• 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.

Deﬁnition 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 Diﬃe-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).

x Alice encrypts with Bob’s public key pkB = (p, q, g, y = g ) and Bob decrypts with his secret key skB = (p, q, g, x):

Encaps(pkB) Decaps(skB, c) x r ←$ [0, q − 1] z ← c mod p c ← gr mod p k ← KDF(c||z) z ← yr mod p return k k ← KDF(c||z) return (c, k) Further cryptographic primitives will be introduced when and where necessary.

16 Chapter 2

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 Diﬃe-Hellman (X3DH) key agreement protocol uses a sequence of Diﬃe-Hellman computations to establish a shared key between two parties [See Figure 2.1].

17 CHAPTER 2. SECURE MESSAGING PKG

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), 1 n • and a set of one-time prekeys {OPKB,..., OPKB}, 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.

i • The OPKB 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 veriﬁes Bob’s prekey signature SigIKB (SPKB) and generates a temporary key pair using an ephemeral public key EKA. • Alice computes a sequence of Diﬃe-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) i DH4 = DH(EKA, OPKB)

• 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 IKA and ephemeral key EKA. • In the same way that Alice did, Bob uses his corresponding secret keys to compute the shared secret k.

18 CHAPTER 2. SECURE MESSAGING PKG

Alice Bob

IKA IKB

EKA 3 SPKB 4

i OPKB

Figure 2.1: The three Diﬃe-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 i one-time prekey OPKB, then k is computed as k = KDF(DH1||DH2||DH3||DH4), where i DH4 = DH(EKA, OPKB).

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 modiﬁed 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 i receives and processes the message, he will delete his one-time prekey OPKB, and the set of i keys {IKB, SPKB, OPKB} 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 i occasionally so that delayed messages can be processed. In the event that no OPKB is used, {IKB, SPKB} will be suﬃcient 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 deﬁnitions to more formally capture properties of cryptographic hash functions.

19 CHAPTER 2. SECURE MESSAGING PKG

n m(n) Deﬁnition 12 (One-Way Function). A function ensemble {fn : {0, 1} → {0, 1} }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 suﬃciently large n

0 0 P[A(fn(x)) = x ∧ fn(x ) = fn(x)] = negl(n) ,

c where fn is polynomial-time computable and negl(n) < 1/n for every constant c > 0.

Deﬁnition 13 (Second-Preimage Resistance). A function ensemble n m(n) {fn : {0, 1} → {0, 1} }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 suﬃciently large n

0 0 0 P[A(fn(x)) = x ∧ x 6= x ∧ fn(x ) = fn(x)] = negl(n) ,

c where fn is polynomial-time computable and negl(n) < 1/n 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.

n m(n) Deﬁnition 14 (Collision Resistance). A function ensemble {fn : {0, 1} → {0, 1} }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 suﬃciently large n

0 0 0 P[A(n) = (x, x ) ∧ x 6= x ∧ fn(x ) = fn(x)] = negl(n) ,

c where fn is polynomial-time computable and negl(n) < 1/n 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 eﬃciently 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,

20 CHAPTER 2. SECURE MESSAGING PKG 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 key

Input KDF

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.

21 CHAPTER 2. SECURE MESSAGING PKG

Alice Bob

pkB0 pkB0 ; skB0

DH Sending chain = Receiving chain DH

skA1 ; pkA1 pkA1

DH Receiving chain = Sending chain DH

pkB1 pkB1 ; skB1

DH Sending chain = Receiving chain DH

skA2 ; pkA2 pkA2

Sending chain DH

pkB2 ; skB2

Figure 2.3: Diﬃe-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 pkA1 . 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 pkA1 and skB1 .

22 CHAPTER 2. SECURE MESSAGING PKG

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].

23 Chapter 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 oﬀers both FS and PCS, it is still eﬃcient 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 n n(n−1) requiring 2 edges, a group of n members would require 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.

24 CHAPTER 3. SECURE GROUP MESSAGING PKG

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 deﬁned as follows. MLS is not intended to be a fully ﬂedged 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 certiﬁcate 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].

25 CHAPTER 3. SECURE GROUP MESSAGING PKG

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 ﬁrst 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 reﬂect their addition [see Figure 3.3].

26 CHAPTER 3. SECURE GROUP MESSAGING PKG

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.join() state.add(B) 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.

27 CHAPTER 3. SECURE GROUP MESSAGING PKG

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 {pk ,..., pk } to the 1 log2(n) root.

28 CHAPTER 3. SECURE GROUP MESSAGING PKG

skO skM skN pkO = g ; skO = f g

skN = f pkM

skM = f pkN

skM skI skJ skN skK skL pkM = g ; skM = f g pkN = g ; skN = f g

skJ skL = f pkI = f pkK

skI skK = f pkJ = f pkL

skI skAskB skJ skC skD pkI = g ; skI = f g pkJ = g ; skJ = f g

skB skD = f pkA = f pkC K L

skA skC = f pkB = f pkD

pkA; skA pkB; skB pkC ; skC pkD; skD E F 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 Diﬃe-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 0 0 0 new pkC ; skC pair as well as all the new keys on the path from C to the root, i.e. pkJ = 0 sk0 0 sk0 0 sk0 skJ 0 C 0 skM 0 J 0 skO 0 M g ; skJ = f pkD , pkM = g ; skM = f pkI and pkO = g ; skO = f pkN . This requires that C knows the public keys on its copath, pkD, pkI and pkN . 0 Once C has computed the new group secret skO, C must distribute the newly computed 0 0 0 0 public keys pkC , pkJ , pkM and pkO so that the other group members can process the update 0 and compute the new group secret skO. 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. sk 0 0sk 0 sk0 skI A 0 skM 0 I 0 skO 0 M pkI = g ; skI = f pkB , pkM = g ; skM = f pkJ and pkO = g ; skO = f pkN .

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

29 CHAPTER 3. SECURE GROUP MESSAGING PKG 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 Deﬁnition 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 ) (pkN , skN ) ← DKP(sN )

sM ← KDF(sJ ) sN ← KDF(sK )

(pkI , skI ) ← DKP(sI ) (pkJ , skJ ) ← DKP(sJ ) K L sI ← KDF(sA) sJ ← KDF(sC )

sA = KDF(skA) sB = KDF(skB) sC = KDF(skC ) sD = KDF(skD) E F G H pkA; skA pkB; skB pkC ; skC pkD; skD

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 beneﬁt 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.

30 CHAPTER 3. SECURE GROUP MESSAGING PKG

We refer to Figure 3.6 for the following example. For C to perform an update, C computes 0 0 0 0 a new pkC ; skC pair as well as the new symmetric secret sC = KDF(skC ). Furthermore, C 0 0 0 0 computes all the new key material from C to the root, i.e. sJ = KDF(sC ) and (pkJ , skJ ) = 0 0 0 0 0 0 0 0 DKP(sJ ), sM = KDF(sJ ) and (pkM , skM ) = DKP(sM ) and ﬁnally sO = KDF(sM ) and 0 0 0 (pkO, skO) = DKP(sO). 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 0 0 0 the following cipher texts; cD = Enc(pkD, sJ ), cI = Enc(pkI , sM ) and cN = Enc(pkN , sO). This requires that C knows the public keys on its copath, pkD, pkI and pkN . Once C has 0 computed the new group secret skO, 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 0 skO. 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. 0 First, A can decrypt cI = Enc(pkI , sM ) using skI , which in turn is computed using sA. Then 0 0 0 0 0 0 0 0 A computes (pkM , skM ) = DKP(sM ) and ﬁnally sO = KDF(sM ) and (pkO, skO) = DKP(sO).

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, Qn a1 an i=1 ai e(g1 , . . . , gn ) = e(g1, . . . , gn) . 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

31 CHAPTER 3. SECURE GROUP MESSAGING PKG

of order p. A bilinear pairing is a map: e : G1 × G2 → GT , which satisﬁes the following properties:

∗ • Bilinearity: ∀a, b ∈ Fp and ∀P ∈ G1,Q ∈ G2

e(a · P, b · Q) = e(P,Q)ab.

• Non-degeneracy: If g1 and g2 are generators of G1 and G2, respectively, then e(g1, g2) is a generator of GT . This is equivalent to e(g1, g2) 6= 1. • Computability: There exists an eﬃcient algorithm to compute e(·). In addition, for security purposes, the discrete logarithm problem is required to be hard in both G1 and G2.

Tripartite Diffie-Hellman We now briefly describe a tripartite Diffie-Hellman protocol using the so-called Weil pairing [Joux, 2000]. Similar to the two party version [See Definition 8], we are given an elliptic curve E, but this time two independent base points P and Q. Two points P and Q are said to be independent, if no integer d exists such that P = d · Q or Q = d · P . Alice, Bob and

Charlie each choose their secret key values dA, dB and dC respectively. They then compute and broadcast their public keys, represented by two points on the curve; (PA,QA), (PB,QB) and (PC ,QC ), where Pi = di · P and Qi = di · Q. Finally Alice, Bob and Charlie compute their shared secret skABC as

Alice: F (dA,PB,QC ) = F (dA,QB,PC ) = skABC

dA dA e(PB,QC ) = e(QB,PC ) = skABC

Bob: F (dB,PA,QC ) = F (dB,QA,PC ) = skABC

dB dB e(PA,QC ) = e(QA,PC ) = skABC

Charlie: F (dC ,PA,QB) = F (dC ,QA,PB) = skABC

dC dC e(PA,QB) = e(QA,PB) = skABC

Given the public keys (PA,QA), (PB,QB) and (PC ,QC ), it should be hard to compute skABC . Whilst the fine details of the underlying elliptic curve cryptography are somewhat involved, we note that a similar scheme can be built using the Tate pairing instead of the Weil pairing to define a different function F 0.

Tripartite ART Using the aforementioned scheme, we now construct an asynchronous ratchet tree based on ternary trees. Similar to the binary ART construction, 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 {pk ,..., pk }. We note that each node now has two siblings as 1 2 log3(n) opposed to just one.

32 CHAPTER 3. SECURE GROUP MESSAGING PKG

pkM ; skM = skJKL

= F (skJ , pkK , pkL)

= F (skK , pkJ , pkL)

= F (skL, pkK , pkJ )

pkJ ; skJ = skABC

= F (skA, pkB, pkC ) pkK ; skK = skDEF pkL; skL = skGHI = F (skB, pkA, pkC )

= F (skC , pkB, pkA)

pkA; skA pkB; skB pkC ; skC D E F G H I

Figure 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.

Send Update A compromised group member needs to initiate an update, without the interference of an adversary, in order to to achieve post-compromise security. We refer to Figure 3.7 for the 0 0 following example. For C to perform an update, C computes a new pkC ; skC pair as well as all 0 0 0 0 the new keys on the path from C to the root, i.e. pkJ ; skJ = skABC0 and pkM ; skM = skJ 0KL [See Algorithm 1]. This requires that C knows the public keys on its copath, pkA, pkB, pkK 0 and pkL. Once C has computed the new group secret skM , C must distribute the newly 0 0 0 computed public keys pkC , pkJ , and pkM so that the other group members can process the 0 update and compute the new group secret skM . To compute sk of a non-leaf node a member must know the sk of one of its children and the pk to the other two children. Thus, in order to compute the group secret a member must know one sk and all the pks along its copath to the root.

Algorithm 1 Update as performed by a sender v of the update. P and Q are two points 0 0 00 00 on the curve E.(Pi ,Qi) and (Pi ,Qi ) denote the public keys of the two siblings of node i. 1: function Send-Update(ratchet tree τ, vertex v)

2: skv : dv ←$ [1, n] . n is a prime denoting the order of P and Q 3: pkv :(Pv = dv · P,Qv = dv · Q) 4: for i = 1 to d . d = depth of τ at v, i.e. dlog3(n)e 0 00 0 00 5: ski : di ← F (di−1,Pi−1,Qi−1) = F (di−1,Qi−1,Pi−1) 6: pki :(Pi = di · P,Qi = di · Q)

7: return {pkv, pk1,..., pkd}

33 CHAPTER 3. SECURE GROUP MESSAGING PKG

Process Update For A to process the update made by C and derive the new group secret, A must compute all 0 0 (pk, sk) pairs along its path with help of the public keys stored on its copath, i.e. pkJ ; skJ = 0 0 0 0 F (skA, pkB, pkC ), and pkM ; skM = F (skJ , pkK , pkL).

Algorithm 2 After v has sent an update, each group member u needs to process it. P and 0 0 00 00 Q are two points on the curve E.(Pi ,Qi) and (Pi ,Qi ) denote the public keys of the two siblings of node i.

1: function Process-Update(ratchet tree τ, vertex v, public keys {pkv, pk1,..., pkd}) 2: k = min x ∈ {1, . . . , d} such that sku is below pkx in τ 3: for i = k to d . d = depth of τ at v, i.e. dlog3(n)e (in the worst case) 0 00 0 00 4: ski : di ← F (di−1,Pi−1,Qi−1) = F (di−1,Qi−1,Pi−1) 5: pki :(Pi = di · P,Qi = di · Q)

Sending an update requires a member to generate dlog3(n)e new key pairs and distribute dlog3(n)e new public keys. Processing an update requires a member to perform dlog3(n)e operations in the worst case, and 1.5 on average, in order to compute the new group secret [See Section 3.4.1 for details].

3.4.1 Comparison of Update operations In this section we give a detailed analysis of the complexity of processing an update using ART, TreeKEM and Tripartite ART.

Asynchronous Ratcheting Trees We start by looking at ART. Let the random variable X denote the number of operations needed to process an update by a group member selected uniformly at random. Note from Figure 3.5 that once C has performed an update half of the group members (E, F , G and H) 0 0 0 skN pk only need to compute pkO; skO = g M in order to process the update. Thus, it follows that 1 [X = 1] = . P 2 More generally, the probability that a group member selected uniformly at random has to perform x operations in order to process an update is given by 1 [X = x] = . P 2x

In the worst case log2(n) operations need to be done to process an update. This is the case for the direct sibling of the group member initiating the update. 1 1 P[X = log2(n)] = = . 2log2(n) n

34 CHAPTER 3. SECURE GROUP MESSAGING PKG

Now, we are interested in the average number of operations required by a group member to process an update using ART. More formally,

n X E[X] = i · P[X = i] i=1 n X i = ≤ 2. 2i i=1

We can put an upper bound on the expectation, giving E[X] = 2. Simply put, this means that on average a member will have to perform 2 operations in order to process an update in ART.

Tripartite ART Now, we turn to Tripartite ART. Here we note from Figure 3.7 that once C has performed an update, two thirds of the group members only need to compute 0 0 0 0 pkM ; skM = F (skK , pkJ , pkL) = F (skL, pkK , pkJ ) in order to process the update. Thus, 2 [X = 1] = . P 3

Using the same reasoning as for ART, it follows that for Tripartite ART 2 [X = x] = , P 3x 2 2 P[X = log3(n)] = = 3log3(n) n and

n X E[X] = i · P[X = i] i=1 n X 2 · i 3 = ≤ . 3i 2 i=1

∆ Asynchronous Ratcheting Trees As previously stated, there appear to be no generalisations of the Diﬃe-Hellman key exchange for more than three parties that require only a single round of communication. However, work by Boneh and Silverberg shows that an (n + 1)-way Diﬃe Hellman key exchange, can be based on an n-multilinear map [Boneh and Silverberg, 2003] with certain cryptographic properties. Thus, we are interested in studying Asynchronous Ratcheting Trees of arbitrary degree. We recall from graph theory, that for any graph G

δ(G) ≤ d(G) ≤ ∆(G)

35 CHAPTER 3. SECURE GROUP MESSAGING PKG where δ(G) = min{d(V ) | v ∈ V (G)}, d(G) and ∆(G) = max{d(V ) | v ∈ V (G)} denote the minimum, average and maximum degree of a vertex in G respectively. In the case of binary trees and ART ∆(G) = 2, and when n is large d(G) ≈ ∆(G). Whilst for ternary trees and Tripartite ART ∆(G) = 3 ≈ d(G). Trivially δ(G) = 1 follows from the leaf nodes. Now, we study the complexity of processing an update for trees where every internal node has degree ∆(G). 1 Essentially, we consider an ART scheme for n group members based on ∆n−1 ∆-ary trees, with a total of ∆−1 nodes. We get that ∆ − 1 [X = 1] = P ∆ and ∆ − 1 [X = x] = . P ∆x

The ∆−1 direct siblings of the group member initiating the update need log∆(n) operations to process the update and clearly ∆ − 1 ∆ − 1 P[X = log∆(n)] = = . ∆log∆(n) n Finally, we wish to express the expected number of operations required to process an update in terms of ∆;

n X E[X] = i · P[X = i] i=1 n X (∆ − 1) · i ∆ = ≤ ∆i ∆ − 1 i=1 1 < E[X] ≤ 2.

Regardless of the degree of internal nodes, it follows from the above that processing an update requires a constant number of operations on average. Furthermore, E[X] lies in the interval (1, 2) and is minimised for increasing ∆.

Summary As the depth of the tree is reduced, so is the cost of update operations, both for sending and processing an update. However, the increased cost comes in having to store more public keys [see Table 3.1]. Thus, it would make sense to choose a ∆ ART construction. However, it is unclear how such a scheme could be built in practise, as is remains unknown how to construct a one-round (n + 1)-way Diﬃe-Hellman key exchange, based on a n-multilinear map. Using Joux’s one-round Tripartite Diﬃe-Hellman key exchange, our Tripartite ART construction can, in fact, be implemented in practise.

1For the sake of improved readability, we abuse the graph theoretic notation somewhat and let ∆ = ∆(G).

36 CHAPTER 3. SECURE GROUP MESSAGING PKG s s ) ) Send n n ( ( s 2 2 ) ) s n , ( denotes the 2 pk ) and pk ( worst n ) ) + log ) + log ( n n pk 1 2 ( ( sk Enc ) 2 2 ; ) + log n ) log ( n pk n log log 2 ( TreeKEM ( 2 2 )( s log n ( log log 2 avg. log 2 + 2 process update pk ) ) ) n sk ( n ; ( pk ) ∆ n pk ∆ ) worst ( n log 0 0 ( ∆ )( ART indicates the amount of key material that n ∆ ( 1) log log ∆ ∆ ) denotes a key pair of an arbitrary public-key 1 log − − ∆ sk log ∆ ; avg. (∆ pk ) ) sk n ; ( pk ) 3 pk n pk ) Transmission ( ) worst n 0 0 3 log ( n )( ( 3 n 3 ( log 3 log log 5 . · log 1 Tripartite ART avg. 2 ) ) d though. As usual, ( sk n ; ( pk pk ) 2 n pk ) ) ( worst n n 0 0 2 log ( ( )( cache 2 2 n ART indicates the number of public keys need to be stored along the path in order to ( log 2 log log 2 avg. log ) sk ) ; Storage sk ; pk pk (path) (copath) key generations ( public key encryptions key computations ( public key decryptions o o o o N N N N denotes a symmetric secret Cache s Transmission Storage Comparison of ART, Tripartite ART and TreeKEM - listing the number of elementary cryptographic operations. denotes the number of operations done by a group member initialising an update. Similarly, Send update Process Update cryptosystem and needs to be broadcastedcompute to the make an values stored update. computed, at the intermediate remaining nodes. keys along When the updates path are need processed, to be on average only a constant number of keys need to be Table 3.1: update number of operations done by each group member to process an update.

37 Chapter 4

Discussion

In this Chapter we summarise our results and provide some useful discussion about open problems in MLS.

4.1 Results and Conclusion

In this thesis we presented a new asynchronous group key agreement protocol based on a one-roud Tripartite Diffie-Hellman. For our protocol, initiating an update operation requires the generation of dlog3(n)e key pairs, compared with dlog2(n)e in ART. TreeKEM requires the generation of dlog2(n)e key pairs and symmetric secretes, as well as one public key encryption. For Tripartite ART, the processing of updates requires users to compute 1.5 key pairs on average and dlog3(n)e in the worst case. On the other hand, ART and TreeKEM need 2 on average and dlog2(n)e in the worst case. TreeKEM has the additional cost of 1 public key decryption and the computation of dlog2(n)e symmetric secrets. Unfortunately, there are drawbacks to this approach and the overhead incurred by our protocol is two-fold. One, devices will need to store 2 · dlog3(n)e public keys as opposed to dlog2(n)e for ART and TreeKEM. However, we argue that this extra cost of storing public keys on a modern device is of minor significance. On the other hand, it is likely that, in practice the computations of a shared secret in Tripartite Diffie-Hellman as opposed to standard Diffie-Hellman will be more expensive, and to provide equivalent levels of security, larger keys would be required. For instance, to obtain 128-bits of security an ECDH key of length 256-bits is usually required, a significant improvement to 3072-bits for standard Diffie-Hellman. However, in order to implement Tripartite ART, we would need to use a pairing friendly curve. Such curves submit groups G1,G2, and GT , each of prime order p, such that an efficiently computable paring function e : G1 × G2 → GT exists where

e(a · P, b · Q) = e(P,Q)ab = T ab for all a, b ∈ Fp and P ∈ G1, Q ∈ G2, and T ∈ GT [Bowe, 2019]. An example of such a curve

38 CHAPTER 4. DISCUSSION PKG could be BLS12-381 [Bowe, 2017], which requires 381-bit keys for 128-bits of security. Wahby and Boneh implement constant-time ﬁeld arithmetic and curve operations for BLS12-381 in 3520 lines of C [Wahby and Boneh, 2019].

Post Compromise Security and Forward Secrecy In order to more formally capture the definition of forward secrecy and post-compromise security, we make use of security games, which describe an interaction between two players, often called the adversary and challenger. The game explicitly specifies a winning state that the adversary is trying to achieve, such as correctly guessing a particular piece of hidden information. In this style of definition, the security is defined through a statement of the form: for all adversaries, the probability of the state being reached does not exceed some fixed threshold. The paper entitled Security Analysis and Improvements for the IETF MLS Standard for Group Messaging [Alwen et al., 2019b] formalises forward secrecy as well as post-compromise security in a security game. Alwen et al. show that TreeKEM (version 7) achieves post-compromise security, but fails to provide forward secrecy. The issues with TreeKEM’s forward secrecy originate from the fact that its users do not erase old keys sufficiently fast. During an update, TreeKEM uses public key encryption (PKE) to encrypt the symmetric secrets stored at each node. However, after processing an update, parties do not delete or modify the PKE secret keys used to decrypt the symmetric secret, since these might be needed to process future updates. Therefore, corrupting any member other than the update initiator would violate forward secrecy, since I would be revealed to an adversary. Depending on the order of updates, for I to remain secret upon state compromise of an arbitrary user, logarithmically many additional updates are needed in the best case, and linearly many in the worst case. Moreover, unless the sibling of the update initiator performs an update, I is never forward secret. However, using an updatable public key encryption system fixes this. On the other hand, ART does not rely on PKE to encrypt any additional secrets stored at each node [Cohn-Gordon et al., 2018]. Instead, the construction relies entirely on a DH operations, whereby secret keys stored at a given node can only be derived from nodes further down in the tree. A formal security analysis of ART is given in [Cohn-Gordon et al., 2018] and shows that ART does achieve forward secrecy and post-compromise security. Whilst a formal security analysis of Tripartite ART remains as future work, similar to ART, our construction does not require the encryption of information stored at internal nodes and, hence, we postulate the forward secrecy properties to be similar to ART.

4.2 Open Questions for the IETF MLS Standard

Finally, we present some informal discussion about some of the open issues in the IETF MLS Standard.

39 CHAPTER 4. DISCUSSION PKG

Sequencing of State Changes There is a risk that two group members initiate an update (or another operation) simultaneously, based on the same state. In this case a conflict needs to be resolved. Sometimes, a total ordering is important for security, for instance all updates should be handled before removes. We demonstrate this with the following example. Assume that Alice sends an update based on state γ. At the same time Bob removes Alice based on state γ. If group members process the update followed by the remove, then a new group secret is derived, and then Alice is removed from the group. Finally, the group secret will be known to all current group members, apart from Alice who has been removed from the group. However, if Alice is first removed from the group and the update is then processed, the group secret will be known by Alice, although she is no longer part of the group. Thus, we wish to enforce a strict ordering of messages. In the case of MLS, there are currently two proposals. Either have a server enforced ordering or a client enforced ordering. If the former is to be used, incoming messages are added to a queue and dispatched in the same order. Due to the confidentiality of messages, the server is trusted to resolve race conditions, and the first message to arrive at the server is accepted whilst the second is rejected. We now briefly describe a system for client-enforced ordering. All messages include a counter such that the ordering is clear. The counter is signed by users so that the counter cannot be modified by the server. In the case that Alice and Bob send messages with the same counter, ties are broken in the following way. Let PRG(·) denote a pseudorandom generator that maps a seed to a pseudorandom output. Group members evaluate PRG(pkA || counter) and PRG(pkB || counter), the greater value is then accepted whilst the other is rejected. The rejected message then needs to be re-sent. We argue that a client enforced ordering is safer, since it does not rely on the server. Implementing such a system would be somewhat more complex and could result in a client getting starved, if they fail to get a proposal accepted.

Suggestions for Future Work Two key areas that could be explored are: 1. Currently MLS doesn’t allow for direct messages to be sent to a subset of group members. There are ongoing discussions as to whether this falls outside of the scope of MLS 1. In that case, an obvious way to approach this problem would be to use existing protocols such as Signal to establish a secure channel between two parties. However, it appears to be an interesting research direction to see whether the TreeKEM construction can be used to send messages to subsets of users. This could be useful for delivery and read receipts. If a messages is intended for users located under the same sub-tree then the root of the sub-tree could be used to encrypt the message. However, if the message is intended for users located under diﬀerent sub-trees, it may be somewhat more involved. 2. Since forward secrecy and post-compromise security depend on the deletion and replacement of keying material, any client which is persistently oﬄine may still be

1https://github.com/mlswg/mls-protocol/issues/301

40 CHAPTER 4. DISCUSSION PKG

holding old keying material and thus be a threat to both FS and PCS if the client is later compromised. Should such users be evicted from the group if they are inactive for a prolonged amount of time? If so, how would this be implemented?

41 References

Joel Alwen, Sandro Coretti, and Yevgeniy Dodis. The Double Ratchet: Security Notions, Proofs, and Modularization for the Signal Protocol . In Yuval Ishai and Vincent Rijmen, editors, Advances in Cryptology – EUROCRYPT 2019, pages 129–158, Cham, 2019a. Springer International Publishing. ISBN 978-3-030-17653-2.

Joel Alwen, Sandro Coretti, Yevgeniy Dodis, and Yiannis Tselekounis. Security Analysis and Improvements for the IETF MLS Standard for Group Messaging . Cryptology ePrint Archive, Report 2019/1189, 2019b.

Richard Barnes, Benjamin Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, and Raphael Robert. The Messaging Layer Security (MLS) Protocol . Internet-Draft draft-ietf-mls-protocol-09, Internet Engineering Task Force, nov 2019. URL https:// datatracker.ietf.org/doc/html/draft-ietf-mls-protocol-09.

Dan Boneh and Alice Silverberg. Applications of multilinear forms to cryptography . In Topics in algebraic and noncommutative geometry (Luminy/Annapolis, MD, 2001), volume 324 of Contemp. Math., pages 71–90. Amer. Math. Soc., Providence, RI, 2003. doi: 10.1090/conm/324/05731. URL https://doi.org/10.1090/conm/324/05731.

Nikita Borisov, Ian Goldberg, and Eric Brewer. Oﬀ-the-record communication, or, why not to use PGP . WPES’04: Proceedings of the 2004 ACM Workshop on Privacy in the Electronic Society, pages 77–84, 2004. doi: 10.1145/1029179.1029200.

Sean Bowe. BLS12-381: New zk-SNARK elliptic curve construction , 2017. URL https: //electriccoin.co/blog/new-snark-curve/.

Sean Bowe. Faster Subgroup Checks for BLS12-381 . Cryptology ePrint Archive, Report 2019/814, 2019.

J Callas, L Donnerhacke, H Finney, D Shaw, and R Thayer. OpenPGP Message Format . RFC 4880, RFC Editor, nov 2007. URL http://www.rfc-editor.org/rfc/rfc4880. txt.

K Cohn-Gordon, C Cremers, and L Garratt. On Post-compromise Security . In 2016 IEEE 29th Computer Security Foundations Symposium (CSF), pages 164–178, jun 2016. doi: 10.1109/CSF.2016.19.

42 REFERENCES PKG

Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt, and Douglas Stebila. A Formal Security Analysis of the Signal Messaging Protocol . Proceedings - 2nd IEEE European Symposium on Security and Privacy, EuroS and P 2017, (July):451–466, 2017. doi: 10.1109/EuroSP.2017.27.

Katriel Cohn-Gordon, Cas Cremers, Luke Garratt, Jon Millican, and Kevin Milner. On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees . In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, CCS ’18, pages 1802–1819, New York, NY, USA, 2018. Association for Computing Machinery. ISBN 9781450356930. doi: 10.1145/3243734. 3243747. URL https://doi.org/10.1145/3243734.3243747.

Cas Cremers, Britta Hale, and Konrad Kohbrok. Eﬃcient Post-Compromise Security Beyond One Group . Cryptology ePrint Archive, Report 2019/477, 2019.

W Diﬃe and M Hellman. New Directions in Cryptography . IEEE Trans. Inf. Theor., 22 (6):644–654, sep 1976. ISSN 0018-9448. doi: 10.1109/TIT.1976.1055638. URL https: //doi.org/10.1109/TIT.1976.1055638.

Facebook. Messenger Secret Conversations . 2017. URL https://fbnewsroomus.files.wordpress.com/2016/07/ messenger-secret-conversations-technical-whitepaper.pdf.

Glenn Greenwald. NSA Prism Program Taps in to User Data of Apple, Google and Others , jun 2013. URL http://www.theguardian.com/world/2013/jun/06/ us-tech-giants-nsa-data.

Daniel Jost, Ueli Maurer, and Marta Mularczyk. A Uniﬁed and Composable Take on Ratcheting . In Dennis Hofheinz and Alon Rosen, editors, Theory of Cryptography, pages 180–210, Cham, 2019. Springer International Publishing. ISBN 978-3-030-36033-7.

Antoine Joux. A One Round Protocol for Tripartite Diﬃe–Hellman . In Wieb Bosma, editor, Algorithmic Number Theory, pages 385–393, Berlin, Heidelberg, 2000. Springer Berlin Heidelberg. ISBN 978-3-540-44994-2.

H Krawczyk and P Eronen. HMAC-based Extract-and-Expand Key Derivation Function (HKDF) . RFC 5869, RFC Editor, may 2010. URL http://www.rfc-editor.org/rfc/ rfc5869.txt.

Ewen Macaskill and Gabriel Dance. NSA Files: Decoded What the revelations mean for you. , 2013. URL https://www.theguardian.com/world/interactive/2013/nov/01/ snowden-nsa-files-surveillance-revelations-decoded{\#}section/7.

Moxie Marlinspike and Trevor Perrin. Double Ratchet Algorithm . Signal, page 35, 2016. URL https://signal.org/docs/specifications/doubleratchet/ doubleratchet.pdf.

Ralph C Merkle. A Digital Signature Based on a Conventional Encryption Function . In Carl Pomerance, editor, Advances in Cryptology — CRYPTO ’87, pages 369–378, Berlin, Heidelberg, 1988. Springer Berlin Heidelberg. ISBN 978-3-540-48184-3.

43 REFERENCES PKG

Thomas Muldowney. XEP-0027: Current Jabber OpenPGP Usage . 2014. URL https: //xmpp.org/extensions/xep-0027.html.

Jonathan B Postel. Simple Mail Transfer Protocol . STD 10, RFC Editor, aug 1982. URL http://www.rfc-editor.org/rfc/rfc821.txt.

B Ramsdell. Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Speciﬁcation . RFC 3851, RFC Editor, jul 2004. URL http://www.rfc-editor.org/ rfc/rfc3851.txt.

E Rescorla. The Transport Layer Security (TLS) Protocol Version 1.3 . RFC 8446, RFC Editor, aug 2018.

P Saint-Andre. Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence . RFC 3921, RFC Editor, oct 2004.

P Saint-Andre. Extensible Messaging and Presence Protocol (XMPP): Core . RFC 6120, RFC Editor, mar 2011. URL http://www.rfc-editor.org/rfc/rfc6120.txt.

Edward Snowden. Permanent Record . Metropolitan Books, New York, NY, USA, 1 edition, 2019. ISBN 978-1-250-23723-1.

Riad S Wahby and Dan Boneh. Fast and simple constant-time hashing to the BLS12-381 elliptic curve . Cryptology ePrint Archive, Report 2019/403, 2019.

WhatsApp. WhatsApp Encryption Overview . 2016. URL https: //scontent.whatsapp.net/v/t61/68135620{\_}760356657751682{\_ }6212997528851833559{\_}n.pdf/WhatsApp-Security-Whitepaper.pdf?{\_}nc{\_ }ohc=zJMEhQ11Oq8AX{\_}01Ld3{\&}{\_}nc{\_}ht=scontent.whatsapp.net{\&}oh= 876a039cc90b6cec25ec8496dee0169f{\&}oe=5E49A925.

Sam Whited. XEP-0364: Current Oﬀ-the-Record Messaging Usage . 2019. URL https: //xmpp.org/extensions/xep-0364.html.

44 List of acronyms

AEAD authenticated encryption with associated data. ART Asynchronous Ratcheting Trees. AS Authentication Service.

CGKA Continuous Group Key Agreement.

DES Data Encryption Standard. DH Diﬃe-Hellman. DKP derive key pair. DS Delivery Service. DSA Digital Signature Algorithm.

ECDH Elliptic Curve Diﬃe-Hellman.

FS forward secrecy.

GnuPG GNU Privacy Guard.

HPKE hybrid public key encryption.

IETF Internet Engineering Task Force.

KDF key derivation function. KEM key encapsulation mechanism.

MLS messaging layer security.

OPK one-time prekey.

45 List of acronyms PKG

OTR Oﬀ-the-Record Messaging.

PCS post-compromise security. PGP Pretty Good Privacy. PKE public key encryption. PKI public key infrastructure.

RSA Rivest Shamir Adleman.

S/MIME Secure/Multipurpose Internet Mail Extensions. SMTP Simple Mail Transfer Protocol.

TLS Transport Layer Security.

X3DH extended triple Diﬃe-Hellman. XML Extensible Markup Language. XMPP Extensible Messaging and Presence Protocol.

46 TRITA -EECS-EX-2020:511