Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
–
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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).
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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).
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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.
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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)
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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).
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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
Berner Fachhochschule | Haute école spécialisée bernoise | Bern University of Applied Sciences
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