whatsapp end-to-end encryption - michael bollitmp.bolli.us/signal.pdf · 2017. 1. 18. · whatsapp...

–

WhatsApp End-to-End Encryption

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

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

2

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 Signal Protocol,

developed by Open Whisper Systems. The main topics there are the X3DH key

exchange protocol, the Double Ratchet algorithm and the XEdDSA signature scheme.


3

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 Forward secrecy 5

3.3 Cryptographic deniability 5

3.4 Digital signatures 5

3.5 One-way hash function 5

3.6 Message authentication code 6

3.7 Diffie-Hellman key agreement protocol 6

3.8 HMAC based key derivation function HKDF 6

3.9 Authenticated Encryption with Associated Data AEAD 7

4 The Signal Protocol 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


4

1 Introduction

Since 2012, when messages 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 Facebook

Messenger and Google Allo. 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

authorized parties.

(A)Symmetric Key Crypto

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

creation of the message.

Asymmetric Key Crypto,

Signature

Freshness Messages cannot be replayed. Nonce, Perfect Forward Secrecy

Trust Receiver can believe that the sender is who

he says he is.

Certificates


5

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 key exchange doesn’t need to happen on a secure

channel. 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 cryptosystem.

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 cryptographic protocol 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 plaintext 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

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


6

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 cryptosystems. 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).


7

3.9 Authenticated Encryption with Associated Data AEAD

For many encryptions, 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:

(ciphertext, 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).


8

4 The Signal Protocol

Developed by Open Whisper Systems in 2013 under the name TextSecure Protocol, Signal

provides end-to-end encryption for instant messaging conversations. The protocol consists of

the Double Ratchet Algorithm, a triple Diffie-Hellman key exchange and is using prekeys,

Curve25519, AES-256 and HMAC-SHA256.

4.1 Extended triple Diffie-Hellman key agreement protocol (X3DH)

The X3DH key agreement protocol establishes a shared secret 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 𝑆𝑃𝐾𝐵

- Bob’s one-time prekey1

𝑂𝑃𝐾𝐵

- 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(𝑆𝑃𝐾𝐵))

- A set of Bob’s one-time prekeys (𝑂𝑃𝐾𝐵1, 𝑂𝑃𝐾𝐵

2, 𝑂𝑃𝐾𝐵

3, …)

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.


9

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 𝑆𝑃𝐾𝐵

- Bob’s prekey signature4

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(𝐸𝐾𝐴 , 𝑆𝑃𝐾𝐵) DH4 = DH(𝐸𝐾𝐴 , 𝑂𝑃𝐾𝐵) 𝑆𝐾𝐴𝐵 = KDF(DH1 || DH2 || DH3 || DH4)

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.

Figure 2: Alice's ephemeral

key pair (Marlinspike &

Perrin, 2016)


10

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.


11

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.


12

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)


13

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.


14

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 Digital Signature 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 Discrete Logarithm

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(𝑞))

𝑏 8 ∗ (ceil (|𝑝|+1

8)) (bitlength for encoded point or integer)


15

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


16

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


17

6 Versions

Version Date Description Author

0.1 02.12.2016 First draft, drawing of X3DH protocol

flow

Michael Bolli

0.2 06.01.2017 Added some crypto primitives Michael Bolli

0.3 07.01.2017 Added crypto key concepts and the 1st

phase of X3DH

Michael Bolli

0.4 08.01.2017 Added the 2nd

phase of X3DH, added

Diffie-Hellman description

Michael Bolli

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

algorithm

Michael Bolli

0.7 13.01.2017 Finished section about the Double

Ratchet algorithm

Michael Bolli

0.8 14.01.2017 Added first part of the XEdDSA

signature scheme

Michael Bolli

0.9 15.01.2017 Finished section about eh XEdDSA

signature scheme

Michael Bolli

1.0 16.01.2017 Added the abstract Michael Bolli

1.1 17.01.2017 Corrections from feedback Michael Bolli

whatsapp end-to-end encryption - michael bollitmp.bolli.us/signal.pdf · 2017. 1. 18. · whatsapp...

Documents