sign in sign up
<<
Home , Double Ratchet Algorithm

–

WhatsApp End-to-End

Signal, X3DH, Double Ratchet Algorithm & XEdDSA/VXEdDSA

Michael Bolli, Patrick Kofmel 1.1, January 17, 2017

Module: BTI 7311 Computer Science Seminar Term: Autumn Term 2016/2017 Supervisor: Prof. Dr. Rolf Haenni

Bern University of Applied Sciences Engineering and Information Technology

Computer Science

Abstract Right when the court fight between Apple and the FBI was at its highest point, WhatsApp came along, stating that they were turning on end-to-end encryption for their over 1 billion users. With this step, WhatsApp gained a lot of points with privacy advocates, but painted a pretty big target on its back for the US government. In this seminar paper, I will explain how the technology behind WhatsApp end-to-end encryption works. First, a few crypto primitives are illustrated, to provide some context or to serve as a reference. The emphasis though lies on the Protocol, developed by . The main topics there are the X3DH exchange protocol, the Double Ratchet algorithm and the XEdDSA signature scheme.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 2

Table of contents 1 Introduction 4 2 Key concepts 4 3 Used crypto primitives and characteristics 5 3.1 Asymmetric/Public key crypto 5 3.2 5 3.3 Cryptographic deniability 5 3.4 Digital signatures 5 3.5 One-way hash function 5 3.6 Message code 6 3.7 Diffie-Hellman key agreement protocol 6 3.8 HMAC based HKDF 6 3.9 Authenticated Encryption with Associated Data AEAD 7 4 The 8 4.1 Extended triple Diffie-Hellman key agreement protocol (X3DH) 8 4.1.1 Used keys and functions 8 4.1.2 The three phases 8 4.1.3 Setting overview 10 4.2 The Double Ratchet Algorithm 10 4.2.1 KDF Chains 11 4.2.2 Symmetric-key ratchet 12 4.2.3 Diffie-Hellman ratchet 12 4.2.4 Double Ratchet 13 4.3 The (V)XEdDSA Signature Scheme 14 4.3.1 XEdDSA 15 5 References 16 6 Versions 17

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 3

1 Introduction

Since 2012, when sent by messaging apps overtook SMS texts for the first time (Bell, 2013), WhatsApp and other services got more and more under fire for their security issues. The NSA scandal didn’t help; encrypted messaging services like Threema and Telegram got popular quickly. WhatsApp silently introduced a “commercially reasonable” encryption in the middle of 2012, only for iOS and Android, though and without specifying the cryptographic methods, which brought more security analysts to the scene. Quickly it was deducted that this current encryption was not secure at all ([email protected], 2012; Kennell, 2012). From 2012 to 2014 even more vulnerabilities were found, e.g. the “WhatsApp Message Handler Vulnerability” which crashed the app when receiving a certain 2 KB message, or the “Photo Privacy Bug” after the introduction of WhatsApp Web (Khandelwal, 2014). It was high time then for WhatsApp to invest in reliable security. At the end of 2014 the partnership of WhatsApp and Open Whisper Systems was made official (Marlinspike, Open Whisper Systems partners with WhatsApp to provide end-to-end encryption, 2014). OWS developed the encrypted messaging app and same-named protocol TextSecure. Together they announced proper end-to-end encryption using TextSecure, which was soon renamed to Signal. In April of 2016 the companies announced availability of end-to-end encryption on all architectures and that users could verify each other’s keys. In this seminar paper, I will introduce the Signal Protocol, which is now also used by and . As a reference, I will first describe some crypto terms for better understanding the protocol itself.

2 Key concepts

Concept Description Crypto techniques

Confidentiality Information is kept secret from all but (A)Symmetric Key Crypto authorized parties.

Integrity Messages have not been modified in transit. Hash, HMAC, Signature

Authentication The sender of a message is authentic. HMAC, Asymmetric Key Crypto, Signature

Non-repudiation The sender of a message cannot deny the Asymmetric Key Crypto, creation of the message. Signature

Freshness Messages cannot be replayed. Nonce, Perfect Forward Secrecy

Trust Receiver can believe that the sender is who Certificates he says he is.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 4

3 Used crypto primitives and characteristics

3.1 Asymmetric/Public key crypto Two keys are used: A public key to be distributed, and a private key which must be kept private. If somebody wants to send me e.g. an encrypted e-mail, he uses my public key to encrypt it, and I use my private key to decrypt it. For this to be secure, it must be difficult to calculate a private key from its public key. In comparison to symmetric crypto, the doesn’t need to happen on a . In many cases, asymmetric crypto is used as a convenient way to securely transfer a session key for a subsequent symmetric encryption, which is much more efficient. This is called a hybrid . Public key algorithms are used in many known standards like TLS, S/MIME, PGP and GPG. With key distribution algorithms like Diffie-Hellman and signatures like DSA, public key crypto is fundamental for today’s crypto world.

3.2 Forward secrecy A has (perfect) forward secrecy if the compromise of long-term keys does not allow an attacker to obtain past session keys (Paar & Pelzl, 2010, p. 341). A system therefore needs to generate a new set of key agreement parameters for each session. These parameters can never be re-used and should never be stored. Now, an attacker managing to compromise a shared session secret would only compromise that particular session.

3.3 Cryptographic deniability It might be necessary for a sender of a message to deny sending that message, even if he was forced to give up the encryption key. Cryptographic deniability makes it impossible to prove the existence of the message without the right encryption key. This can be done by encrypting a message in such a way that using key 퐾퐴 to decrypt the cipher text results in another message than by using key 퐾퐵.

3.4 Digital signatures To prevent forgery or tampering with messages, digital signatures can be used to provide integrity, authentication, and non-repudiation. Digital signatures employ asymmetric and consist of the following three parts: Key generation, signing and verifying. The key generation algorithm outputs the private key and a corresponding public key. The signing algorithm takes a message and the private key to produce a signature. The verifying algorithm verifies the authenticity of the message using the public key and the signature.

3.5 One-way hash function A hash function calculates from an input message of any length, an output string of a fixed length. This means it needs to be deterministic, so the same message always results in the same hash. It is called a one-way function because the design makes it easy to compute the output from the input message, but very hard to generate an input message from its hash value. Another property is the so-called avalanche effect, which describes that even a minimal change to the message drastically changes the output hash. Hashes are used in many applications, these being digital signatures, message authentication codes (see below), fingerprinting and data integrity.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 5

3.6 Message authentication code A MAC consists of key generation, signing and verifying algorithms. MACs share some properties with digital signatures, as they also provide message integrity and authentication (but not non- repudiation). Due to the use of block ciphers or hash functions (which would be a HMAC) instead of asymmetric crypto, they are much more performant though. A MAC takes a secret key and a message as input, and calculates a MAC output. This enables a recipient/verifier to detect any changes to the message content by running the message through the same MAC function with the same key and finally comparing the resulting MACs.

3.7 Diffie-Hellman key agreement protocol The Diffie-Hellman key exchange enables two parties to calculate a common secret key by communicating over an insecure channel. Apart from Signal, it’s also used in many major ∗ protocols like SSH, TLS and IPsec. Its basic idea is that exponentiation in ℤ푝, 푝 prime, is a one- way function and that exponentiation is commutative (Paar & Pelzl, 2010, p. 206): 푘 = (훼푥)푦 ≡ (훼푦)푥 mod 푝 Using this idea, the protocol looks like this:

Figure 1: Diffie-Hellman key agreement protocol (Schneider, 2016)

Alice wants to establish a secret key with Bob through an insecure channel. In the set-up protocol the public parameters 𝑔 ∈ {2, 3, … , 푝 − 2} and a large prime 푝 are generated and published. Alice can then choose her private key 푎 ∈ {2, 3, … , 푝 − 2}, and calculate her public key 퐴 = 𝑔푎 mod 푝. Alice sends the public key to Bob, which after his calculations does the same. With this public key, they can now each generate a joint secret key: 퐾 ≡ (퐵)푎 mod 푝 ≡ 𝑔푏푎 mod 푝 ≡ (퐴)푏 mod 푝 ≡ 𝑔푎푏 mod 푝 This key K can now be used for further communications e.g. with a symmetric key cipher like AES or 3DES.

3.8 HMAC based key derivation function HKDF A key derivation function (KDF) is a basic and essential component of . It takes weak key material (e.g. Diffie-Hellman exchanged shared secrets, which are not uniformly distributed over {0, 1}푛) and a pseudo random KDF key (e.g. HMAC-SHA256), to turn it into cryptographically stronger key material. This has mainly two uses, which can be combined: Take the potentially weak source keying material and extract from it a fixed-length pseudorandom key, or expand a key into several additional pseudorandom cryptographic keys (Krawczyk, 2010).

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 6

3.9 Authenticated Encryption with Associated Data AEAD For many , it’s not enough to ensure just confidentiality. The attacker might use active techniques, and the receiver might want to ensure the data has really been constructed by a sender with the right key. This is where AEAD is used, as it provides confidentiality, integrity and data authenticity simultaneously. Additionally, AEAD can authenticate (not encrypt) a part of its input (e.g. a header), which is called associated data. An AEAD implementation provides an encryption and a decryption function: (, MAC) = encrypt(푝푙푎𝑖푛푡푒푥푡, 푘푒푦 [, ℎ푒푎푑푒푟]) plaintext = decrypt(푐𝑖푝ℎ푒푟푡푒푥푡, 푘푒푦, 푀퐴퐶 [, ℎ푒푎푑푒푟]) The header part is intended to provide authenticity and integrity protection e.g. for networking, for which confidentiality is unnecessary or unwanted, but authenticity is desired. There are three main approaches to authenticated encryption: Encrypt-then-MAC (e.g. IPsec), Encrypt-and-MAC (e.g. SSH) and MAC-then-Encrypt (e.g. TLS). Today the use of Encrypt-then-MAC is encouraged, as any modifications to the ciphertext (i.e. a chosen ciphertext attack) that do not have a valid MAC code can be filtered out before decryption, protecting against any attacks on the implementation. Also this way the MAC cannot be used to infer anything about the plaintext. Other popular AEAD algorithms and modes are OCB (Offset Codebook Mode), CCM (Counter with CBC-MAC), EAX and GCM (Galois/Counter Mode).

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 7

4 The Signal Protocol

Developed by Open Whisper Systems in 2013 under the name TextSecure Protocol, Signal provides end-to-end encryption for conversations. The protocol consists of the Double Ratchet Algorithm, a triple Diffie-Hellman key exchange and is using prekeys, , AES-256 and HMAC-SHA256.

4.1 Extended triple Diffie-Hellman key agreement protocol (X3DH) The X3DH key agreement protocol establishes a key between two parties (see 3.7) who mutually authenticate each other based on their public keys. X3DH provides forward secrecy (see 3.2) and cryptographic deniability (see 3.3). X3DH is designed for asynchronous settings where Bob is offline, but has published some information to a server. Alice wants to use that information to send encrypted data to Bob, and also establish a shared secret key for future communication (Marlinspike & Perrin, 2016).

4.1.1 Used keys and functions In a protocol run X3DH uses five essential elliptic curve keys (also see 4.3):

- Alice’s (long-term) identity key 퐼퐾퐴 - Alice’s ephemeral key 퐸퐾퐴 (valid for one protocol run) - Bob’s (long-term) identity key 퐼퐾퐵 - Bob’s (periodically changed) signed prekey 푆푃퐾퐵 1 - Bob’s one-time prekey 푂푃퐾퐵 - Shared secret key 푆퐾퐴퐵 Depending on the X3DH setup, these keys are either in the X25519 or X448 form (WhatsApp is using X25519). The signed prekey is signed by the corresponding identity key. As 256 or 512-bit hash function may be used (e.g. SHA-256), and additionally an encoding function Encode(푃퐾) must be defined to encode an elliptic curve public key into a byte sequence.

4.1.2 The three phases X3DH has three phases, which are explained with the mentioned setting in mind (also see the probably clarifying overview in 4.1.3): 4.1.2.1 Phase 1: Publishing Bob’s keys to the server Bob needs to publish the following public keys to a trusted2 server:

- Bob’s identity key 퐼퐾퐵 - Bob’s signed prekey 푆푃퐾퐵 - Bob’s prekey signature Sig(퐼퐾퐵, Encode(푆푃퐾퐵)) 1 2 3 - A set of Bob’s one-time prekeys (푂푃퐾퐵 , 푂푃퐾퐵 , 푂푃퐾퐵 , …) This needs to be done only once (e.g. at registration), except if the amount of stored one-time prekeys is getting low and needs to be refilled. At some interval (e.g. once a week), Bob will also upload a new signed prekey and prekey signature, which will replace the existing ones. To ensure forward secrecy, Bob should then delete the now invalid private keys.

1 A prekey is a previously generated key which in this case got published by Bob to the server maybe weeks before Alice decided to contact Bob.

2 Provided that Alice and Bob authenticated each other, a malicious server could either stop all communication, or refuse to hand out one-time prekeys, leading to weaker forward secrecy.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 8

4.1.2.2 Phase 2: Sending the initial message Alice wants to talk to Bob3, which means she needs to do a X3DH key agreement now. Upon request the server provides her with the so-called “prekey bundle”, containing:

- Bob’s identity key 퐼퐾퐵 - Bob’s signed prekey 푆푃퐾퐵 4 - Bob’s prekey signature Sig(퐼퐾퐵, Encode(푆푃퐾퐵)) - A one-time prekey 푂푃퐾퐵

After sending the one time prekey 푂푃퐾퐵, it needs to be removed from server storage.

Alice first verifies the prekey signature. If it’s valid, Alice generates an ephemeral key pair 퐸퐾퐴. She then goes on calculating the shared master secret with the following algorithm. Note that the first two DH5’s provide mutual authentication, whereas the last two provide forward secrecy:

DH1 = DH(퐼퐾퐴, 푆푃퐾퐵) DH2 = DH(퐸퐾퐴, 퐼퐾퐵) DH3 = DH(퐸퐾퐴, 푆푃퐾퐵) Figure 2: Alice's ephemeral DH4 = DH(퐸퐾퐴, 푂푃퐾퐵) key pair (Marlinspike & 푆퐾퐴퐵 = KDF(DH1 || DH2 || DH3 || DH4) Perrin, 2016) The outputs DH1- DH4 and her ephemeral private key need to be deleted afterwards. The next step is to compute a so-called associated data byte sequence, which contains identity information for both parties. Alice may also append additional information like Alice and Bob’s usernames or certificates:

AD = Encode(퐼퐾퐴) || Encode(퐼퐾퐵) Alice can now start sending Bob messages, even if he’s offline. Here’s the initial message:

- Alice’s identity key 퐼퐾퐴 - Alice’s ephemeral key 퐸퐾퐴 - An identifier stating which one of Bob’s prekeys was used - The initial message ciphertext The message is encrypted with an AEAD encryption scheme (see 3.9), using AD as associated data and a key. This key can either be the shared secret 푆퐾퐴퐵 or a derived key from e.g. a KDF (see 3.8) or Pseudo Random Function (PRF), keyed by 푆퐾퐴퐵. Until Bob responds, Alice includes this information in the header of all messages sent, in order to enable Bob to build a corresponding session. 4.1.2.3 Phase 3: Receiving the initial message Upon receiving Alice’s initial message, Bob repeats the DH and KDF calculations from the previous section to get the same shared secret key 푆퐾퐴퐵. After completion, he deletes the DH values.

Like Alice he then constructs the associated data byte sequence AD using 퐼퐾퐴 and 퐼퐾퐵.Now Bob can decrypt the initial ciphertext using 푆퐾퐴퐵 and AD.

3 Alice and Bob might first want to compare their identity keys through some authenticated channel. WhatsApp provides a QR code mechanism to do that.

4 Sig(PK, M) is an XEdDSA signature (see 4.3) on the byte sequence M, verifiable with public key PK. Encode(PK) converts a X25519 or X448 publickey PK into a byte sequence and needs to be defined by the implementing application.

5 DH(PK1, PK2) is the output of the Elliptic Curve Diffie-Hellman function X25519 or X448.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 9

If the decryption fails, Bob cancels the protocol and deletes 푆퐾퐴퐵. If it succeeds, Bob deletes the used one-time prekey (the private key) for forward secrecy. Bob and Alice can now continue using 푆퐾퐴퐵 or keys derived from it for further communication. 4.1.3 Setting overview

Figure 3: X3DH Protocol

4.2 The Double Ratchet Algorithm The Double Ratchet algorithm is used by two parties to exchange encrypted messages based on a shared secret key (Marlinspike & Perrin, 2016). It is called double ratchet because it combines a Diffie-Hellman key exchange ratchet with a symmetric-key ratchet. After using X3DH to agree on a shared secret key, Alice and Bob can use the Double Ratchet algorithm to send and receive encrypted messages. Bob’s signed prekey 푆푃퐾퐵 becomes Bob’s initial ratchet public key for Double Ratchet initialization. Their master/session key 푆퐾퐴퐵 negotiated by X3DH, is used as the Double Ratchet’s initial root key. From this root key, a chain key gets derived, from which a message key gets derived. This message key changes for each message transmitted. The chain key “ratchets” forward with every message sent, and a new X3DH agreement is performed with each message roundtrip to create a fully new chain key.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 10

4.2.1 KDF Chains As defined in 3.8, a KDF takes a random KDF key and some input data and returns output data indistinguishable from randomness. A KDF chain therefore is a chain of KDFs, where the output of the previous KDF is fed as the KDF key into the next KDF.

Figure 4: A KDF chain (Marlinspike & Perrin, 2016, p. 4)

A KDF chain meets the properties defined in (Barak & Halevi, 2005): - Resilience: The output keys look random to an observer with no knowledge of the KDF keys. This holds even if that observer has complete control over the KDF inputs. - Forward security: Past output keys look random to an observer, even if he learns the KDF key at some point in time - Break-in recovery: Future output keys look random, even to an observer with the KDF key (provided that future inputs have added sufficient entropy) In a Double Ratchet session between Alice and Bob, each party stores a root chain, a sending chain and a receiving chain. The receiving chain of Bob is the sending chain of Alice. In every message exchange, Alice and Bob also swap new Diffie-Hellman public keys. The corresponding output secrets become the inputs to the root chain. The output keys from the root chain become the new KDF keys for the sending and receiving chains. That’s the Diffie- Hellman ratchet. The sending and receiving chains advance as each message is sent and received. Their output keys are used to encrypt and decrypt the messages. This is called the symmetric-key ratchet.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 11

4.2.2 Symmetric-key ratchet The output keys of the sending and receiving chains are called message keys. They ensure that each message is encrypted with a unique key, which can be deleted after encryption or decryption. So, after every message, a new key is derived from the current chain key as seen in Figure 5.

Figure 5: Deriving a new message key via symmetric-key ratchet (Marlinspike & Perrin, 2016, p. 5)

4.2.3 Diffie-Hellman ratchet Every message begins with a header which contains the sender’s current ratchet public key (a Diffie-Hellman public key). When Alice receives Bob’s new ratchet public key, she performs a DH ratchet step, which replaces the current ratchet key pair with a new key pair. When she answers the message, Bob will do the same. This results in a ping-pong behavior as the parties take turns replacing ratchet key pairs. An attacker might compromise a current ratchet private key, but this key will soon be replaced with an uncompromised one. Figure 6 shows such a DH ratchet for one party. The public key with the white arrow is Bob’s current ratchet public key. With the first DH output Alice derives the new sending chain to match Bob’s receiving chain. After that, Alice uses the second DH output to generate a new sending chain. Note that of course the DH output for Alice and Bob is the same, resulting also in the same chains.

Figure 6: A complete DH ratchet (Marlinspike & Perrin, 2016, p. 12)

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 12

4.2.4 Double Ratchet When we combine the symmetric-key and DH ratchets, we get the Double Ratchet. Each time when a message is sent or received, a symmetric-key ratchet step is applied to the sending or receiving chain to derive a new message key. When a message header contains a new ratchet public key, a DH ratchet step is performed to replace the chain keys. This happens prior to the symmetric-key ratchet. As seen in Figure 7, the initial state is that Alice generates a new ratchet key pair with Bob’s ratchet public key and a shared secret, and thus feeds the DH output to the root KDF to calculate a new root key (RK) and sending key (CK). Alice’s first message causes the sending chain to symmetric-key-ratchet forward, so that it can be encrypted with the new message key A1. In the case of WhatsApp, a message key is calculated as (WhatsApp Inc., 2016): A1=HMAC-SHA256(CK, 0x01) Each time when a message key is generated, the chain key then gets updated: CK=HMAC-SHA256(CK, 0x02) The response B1 from Bob contains a new ratchet public key, so Alice applies a DH ratchet step to get a new root key, from which to derive new receiving and sending chain keys. In the case of WhatsApp, a new chain key and root key are calculated as:

CK, RK=HKDF(RK, X3DH(EKA,EKB)) After that, with a symmetric-key ratchet step to the receiving chain, she gets the message key to decrypt the actual message. Every message has a message number correlating to the sending/receiving chains. This way, messages can arrive delayed, out of order or can be lost entirely without problems.

Figure 7: State of the chains after Alice sent a message and got a response from Bob (Marlinspike & Perrin, 2016, p. 14)

Figure 8: Another view on the Double Ratchet algorithm. Clearly visible: All sub keys are derived from a DH ratchet.

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 13

4.3 The (V)XEdDSA Signature Scheme The XEdDSA (or XEd25519 or XEd448 for specific curves) and VXEdDSA signature schemes (see 3.4) are Edwards-curve Algorithms based on Twisted Edwards curves. In elliptic curve cryptography, a public key is essentially a point on a curve. Explaining elliptic curves goes beyond the scope of this document, although there is a nice explanation on Ars Technica (Sullivan, 2013). Furthermore, Figure 9 shows what an elliptic curve and its used values could look like.

Figure 9: On the left the elliptic curve, on the right the actually used values mod 89 (Eichsleder, 2016)

The main reason why nowadays ECDSA is the algorithm of choice compared to e.g. RSA is that it’s easier to factor large numbers (RSA) than to solve the Elliptic Curve Problem. This means that with ECDSA you can get the same level of security as RSA but with much smaller keys. A 256-bit elliptic curve key provides as much protection as a 3248-bit asymmetric key, according to the ECRYPT II recommendations (Giry, 2012). This in turn means less latency for TLS connections and faster loading times of e.g. websites. More detailed information about (V)XEdDSA is available in (Perrin, 2016), but some algorithms are explained in the following. There will be pseudocode, so here are the elliptic curve parameters used for reference. Integer variables are in lower case (푥, 푦), while points and other variables are in upper case (푃, 푄). Byte sequences are in bold (풙, 푷), || means byte concatenation.

Name Definition

퐵 Base point

퐼 Identity point

푝 Field prime

푞 Order of base point (prime; 푞 < 푝; 푞퐵 = 퐼)

푐 Cofactor

푑 Twisted Edwards curve constant

퐴 Montgomery curve constant

푛 Nonsquare integer modulo p

|푝| ceil(log2(푝))

|푞| ceil(log2(푞))

|푝|+1 푏 8 ∗ (ceil ( )) (bitlength for encoded point or integer) 8

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 14

4.3.1 XEdDSA The XEdDSA sign function requires the following inputs:

Name Definition

푘 Montgomery private key (integer mod q)

푴 Message to sign

풁 64 Bytes secure random data

xeddsa_sign(k, 퐌, 퐙): A, a = calculate_key_pair(k) r = hash1(퐚 || 퐌 || 퐙) (mod q) 퐑 = rB h = hash(퐑 || 퐀 || 퐌) (mod q) s = r + ha (mod q) return 퐑 || s The function calculate_key_pair() converts a Montgomery private key k to a twisted Edwards public and private key (A, a). The default hash function is SHA-512. The output of xeddsa_sign() is a signature (푹 || 푠), a byte sequence of length 2푏 bits, where 푏 is the bitlength for an encoded point or integer. The XEdDSA verify function requires the following inputs:

Name Definition

풖 Montgomery public key

푴 Message to verify

푹 || 푠 Signature to verify

xeddsa_verify(퐮, 퐌, (퐑 || 퐬)): if u >= p or R. y >= 2|p| s >= 2|q|: return false A = convert_mont(u) if not on_curve(A): return false h = hash(퐑 || 퐀 || 퐌) (mod q) Rcheck = sB − hA if bytes_equal(퐑, 퐑퐜퐡퐞퐜퐤): return true return false The function convert_mont() converts a Montgomery u coordinate to a twisted Edwards point A. VXEdDSA extends XEdDSA to make it a verifiable random function, as defined in (Micali, Rabin, & Vadhan, 1999).

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 15

5 References [email protected]. (2012, September 12). Reverse Engineering: How WhatsApp (not) securing your data. Retrieved from https://web.archive.org/web/20150107085402/http://pastebin.com/g9UPuviz Barak, B., & Halevi, S. (2005, September 1). A model and architecture for pseudo-random generation with applications to /dev/random. Retrieved from iacr.org: http://eprint.iacr.org/2005/029.pdf Bell, L. (2013, April 29). App messaging overtakes SMS texts for the first time. Retrieved from The Inquirer: http://www.theinquirer.net/2264700 Eichsleder, M. (2016, June). Elliptic Curves over R and Fp. Retrieved from TikZ for Cryptographers: http://www.iacr.org/authors/tikz/tikz/Elliptic%20Curves/ec_curves_Fp_R.pdf Giry, D. (2012). ECRYPT II Report on Key Sizes. Retrieved from https://keylength.com: https://www.keylength.com/en/3/ Kennell, K. (2012, September 12). WhatsApp is broken, really broken. Retrieved from fileperms.org: https://web.archive.org/web/20150108072201/http://fileperms.org/whatsapp-is- broken-really-broken.html Khandelwal, S. (2014, December 01). Crash Your Friends' WhatsApp Remotely with Just a Message. Retrieved from The Hacker News: http://thehackernews.com/2014/12/crash- your-friends-whatsapp-remotely_1.html Krawczyk, H. (2010). Cryptographic Extraction and Key Derivation: The HKDF Scheme. Retrieved from iacr.org: https://eprint.iacr.org/2010/264.pdf Marlinspike, M. (2014, November 18). Open Whisper Systems partners with WhatsApp to provide end-to-end encryption. Retrieved from Open Whisper Systems: https://whispersystems.org/blog/whatsapp/ Marlinspike, M., & Perrin, T. (2016, November 20). The Double Ratchet Algorithm. Retrieved from Open Whisper Systems Inc.: https://whispersystems.org/docs/specifications/doubleratchet/doubleratchet.pdf Marlinspike, M., & Perrin, T. (2016, November 04). The X3DH Key Agreement Protocol. Retrieved from Open Whisper Systems Inc.: https://whispersystems.org/docs/specifications/x3dh/x3dh.pdf Micali, S., Rabin, M., & Vadhan, S. (1999, October). Verifiable Random Functions. In Proceedings of 40th Annual Symposium on Foundations of Computer Science (pp. 120-130). New York, NY: IEEE. Paar, C., & Pelzl, J. (2010). Understanding Cryptography. Berlin Heidelberg: Springer-Verlag. Perrin, T. (2016, October 20). The XEdDSA and VXEdDSA Signature Schemes. Retrieved from Open Whisper Systems: https://whispersystems.org/docs/specifications/xeddsa/xeddsa.pdf Schneider, C. R. (2016, December). Diffie-Hellman Key Exchange. Retrieved from TikZ for Cryptographers: http://www.iacr.org/authors/tikz/tikz/Discrete%20Log/dhkex.pdf Sullivan, N. (2013, October 24). A (relatively easy to understand) primer on elliptic curve cryptography. Retrieved from Ars Technica: http://arstechnica.com/security/2013/10/a- relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/ WhatsApp Inc. (2016, Dezember 10). Whatsapp Security Whitepaper. Retrieved from https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 16

6 Versions

Version Date Description Author

0.1 02.12.2016 First draft, drawing of X3DH protocol Michael Bolli flow

0.2 06.01.2017 Added some crypto primitives Michael Bolli

0.3 07.01.2017 Added crypto key concepts and the 1st Michael Bolli phase of X3DH

0.4 08.01.2017 Added the 2nd phase of X3DH, added Michael Bolli Diffie-Hellman description

0.5 09.01.2017 Added the 3rd phase of X3DH protocol Michael Bolli

0.6 10.01.2017 Added first part of the Double Ratchet Michael Bolli algorithm

0.7 13.01.2017 Finished section about the Double Michael Bolli Ratchet algorithm

0.8 14.01.2017 Added first part of the XEdDSA Michael Bolli signature scheme

0.9 15.01.2017 Finished section about eh XEdDSA Michael Bolli signature scheme

1.0 16.01.2017 Added the abstract Michael Bolli

1.1 17.01.2017 Corrections from feedback Michael Bolli

Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences 17