More is Less: On the End-to-End Security of Group Chats in

Signal, WhatsApp, and Threema

Paul Rösler, Christian Mainka, Jörg Schwenk
{paul.roesler, christian.mainka, joerg.schwenk}@rub.de
Horst Görtz Institute for IT Security
Chair for Network and Data Security
Ruhr-University Bochum
January 6, 2018

Abstract
Secure instant messaging is utilized in two variants: one-to-one communication and group communication.
While the first variant has received much attention lately (Frosch et al., EuroS&P16; Cohn-Gordon et al.,
EuroS&P17; Kobeissi et al., EuroS&P17), little is known about the cryptographic mechanisms and security
guarantees of secure group communication in instant messaging.
To approach an investigation of group instant messaging protocols, we first provide a comprehensive and
realistic security model. This model combines security and reliability goals from various related literature
to capture relevant properties for communication in dynamic groups. Thereby the definitions consider their
satisfiability with respect to the instant delivery of messages. To show its applicability, we analyze three widely
used real-world protocols: Signal, WhatsApp, and Threema. Since these protocols and their implementations
are mostly undocumented for the public and two out of three applications among them are closed source, we
describe the group protocols employed in Signal, WhatsApp, and Threema. By applying our model, we reveal
several shortcomings with respect to the security definition. Therefore we propose generic countermeasures
to enhance the protocols regarding the required security and reliability goals. Our systematic analysis reveals
that (1) the communications’ integrity – represented by the integrity of all exchanged messages – and (2) the
groups’ closeness – represented by the members’ ability of managing the group – are not end-to-end protected.
We additionally show that strong security properties, such as Future Secrecy which is a core part of the
one-to-one communication in the Signal protocol, do not hold for its group communication.

1 Introduction
Short Message Service (SMS) has dominated the text-based communication on mobile phones for years.
Instant Messaging (IM) applications started by providing free-of-charge SMS functionality, but today provide
numerous additional features, and therefore dominate the messaging sector today [1, 15, 27].
One of the main advantages of IM applications over SMS is the possibility to easily communicate with
multiple participants at the same time via group chats. IM chats thereby allow sharing of text messages and
attachments, such as images or videos, for both, direct communication and group communication. Groups are
mainly defined by a list of their members. Additionally, meta information is attached to groups, for example,
a group title. Depending on the IM application and its underlying protocol, groups are administrated by
selected users, or can be modified by every user in a group.
With the revelation of mass surveillance activities by intelligence agencies, new IM applications incor-
porating end-to-end encryption launched, as well es established IM applications added encryption to their
protocols to protect the communication towards the message delivering servers. Hence analyses, investigating
these protocols, also include malicious server-based attacks [31, 34].

1
 In contrast to open standardized communication protocols like Extensible Messaging and Presence Pro-
tocol (XMPP) or Internet Relay Chat (IRC), most IM protocols are centralized such that users of each
application can only communicate among one another. As a result, a user cannot choose the most trustwor-
thy provider but needs to fully trust the one provider that develops both, protocol and application.
End-to-end encryption is the major security feature of secure instant messaging protocols for protecting
the protocol security when considering malicious server-based attacks. Additionally further security prop-
erties like future secrecy have been claimed [44], analyzed [29], and proven [20]. Forward secrecy and future
secrecy are properties that describe the preservation or recovery of security if user secrets are leaked to
the attacker at a later (resp. earlier) point of time. End-to-end encryption is part of all major IM apps,
including Signal [48], WhatsApp [65], Threema [60], Google Allo [47], and Facebook Messenger [46]. One
of the main achievements of secure instant messengers is the usability of its end-to-end encryption. After
the application installation, keys are automatically generated, and encryption is (or can easily be) enabled.
Experienced users may do some simple checks to verify the public key of their counterpart [24], but this is
often an optional step.
Contrary to classical multi-user chats, for example, to IRC in which all members are online, groups in IM
protocols must work in asynchronous settings; Groups must be createable and messages must be deliverable
even if some group members are offline.
The fact that widely used secure instant messenger protocols are neither open source nor standardized
makes it harder to analyze and compare their security properties. This leads to two major challenges.
First, the applications must be reverse engineered [10, 29, 30] for retrieving a protocol description. Second,
third-party implementations are often blocked by providers [64] such that an active analysis is even more
complicated.
When analyzing the protocols, the security properties in the setting of asynchronous, centralized mes-
saging must be investigated with the whole group environment in mind. The security of a protocol does not
only rely on single messages, exchanged between two group members. For example, the abstract security
goal confidentiality is based on the composition of the strength of the encryption algorithm for protecting
the content of single messages and the protocol’s strength to ensure that users who do not belong to a group
must not be able to add themselves to the group or receive messages from the group without the members’
permission. Additionally, the integrity of the communication is not restricted to the non-malleability of single
exchanged messages but also consists of the correct message delivery between the communicating users.
Established definitions like reliable multicast [14, 32] and related formalizations like group communication
systems (GCS) [19] provide a set of properties that need to be reached for achieving a secure and reliable
group communication. However, they do not fully match the described setting and over-accomplish the
reliability requirements at costs of the instant delivery of messages. Therefore, the modeling of our security
and reliability definitions bases on the related literature and the satisfiability of real-world requirements such
as asynchronous communication and instant message delivery. For this purpose we also considered represen-
tative secure instant messengers by extracting security properties from their features (provider statements
or visual user interface). We matched these properties to definitions from the mentioned and further related
fields of research (e.g., authenticated key exchange, reliable broadcast, GCS) and thereby provide a novel
comprehensive security model for the investigation of secure group instant messaging protocols.
We investigate three popular secure instant messengers: Signal [48], Threema [60], and WhatsApp [65].
Signal can be seen as a reference implementation for other secure instant messenger protocols that implement
the Signal key exchange protocol like Facebook Messenger, Google Allo and other messengers. However,
our analysis shows that the integration of the Signal key exchange protocol does not imply same group
communication protocols. We chose to analyze WhatsApp, because it is one of the most widely used instant
messenger applications with more than one billion users [54]. We additionally chose to analyze Threema
as a widely used representative for the class of proprietary and closed source instant messengers – not
implementing the Signal key exchange protocol. Signal and Threema are both used by at least one million
Android users [53, 59]. Based on this examination, we apply our model and evaluate the security properties.
In our systematical analysis, we reveal several discrepancies between the security definition of our model and
the security provided by the group communication protocols of these applications.

2
Our contributions are outlined as follows:
I We present and discuss a realistic and comprehensive security model for the analysis of group communi-
cation in secure instant messenger protocols (§ 2). Therefore we employ definitions from related literature
and fit them to the setting of instant message delivery in groups. As such, we lift strong notions of relia-
bility to a realistic model and combine them with well established security goals to introduce a formalism
that is applicable for real-world protocols.
I We describe the group communication protocols of Signal (§4), WhatsApp (§5), and Threema (§6) and
thereby present three fundamentally different protocols for secure and instant group communication to
enable further scientific analyses.
We analyze them by applying our model and thereby reveal several insufficiencies showing that traceable
delivery, closeness and thereby confidentiality of their group chat implementations are not achieved. As
a result, we show that none of these group communication protocols achieves future secrecy.
I We provide and compare generic approaches to secure group communications, based on our observations
and related literature (§8).
All findings have been responsibly disclosed to the application developers.

2 Security Model
Secure instant messaging protocols should satisfy the general security goals Confidentiality, Integrity, Au-
thenticity and Reliability. Some of them even claim advanced security goals like Future Secrecy.
One could expect that protocols for group communication reach the same properties – as well as several
others –, that are naturally achieved in a two-party scenario. Intuitively, a secure group communication
protocol should provide a level of security comparable to when a group of people communicates in an
isolated room: everyone in the room hears the communication (traceable delivery), everyone knows who
spoke (authenticity) and how often words have been said (no duplication), nobody outside the room can
either speak into the room (no creation) or hear the communication inside (confidentiality), and the door to
the room is only opened for invited persons (closeness).
Even though some of these requirements seem to be well understood, it is essential for a comprehensive
analysis to take them into account.

2.1 Notation and Assumptions

The instant messenger protocols in scope are centralized : all exchanged messages are transmitted via a
central server, that receives messages from the respective senders, caches them, and forwards them as soon
as the receivers are online. Hence the protocols are executed in an asynchronous environment in which only
the server is always online.
We generally define a group gr as the tuple
∗ ∗
gr = (ID gr , Ggr , Ggr , info gr ), Ggr ⊆ Ggr ⊆ U
∗
where U is the set of protocol users, Ggr is the set of members in the group and Ggr is the set of administrators
of the group. The group is uniquely referenced by ID gr . Additionally, a title and other usability information
can be configured in info gr . We denote communicating users as A, B, C, .., U, .., X ∈ U and an administrator
as U ∗ ∈ Ggr
∗
.
Every user maintains long-term secrets for initial contact with other users and a session state for each
group in which she is member. The session state contains housekeeping variables and secrets for the exclusive
usage in the group. Messages delivered in a group are not stored in the session state.
By distinguishing between delivery and receiving of messages, we want to emphasize that a received
message is first processed by algorithms before the result is presented to the user.

3
Figure 1: Overview over syntax of group instant messaging protocols showing the interacting user’s interfaces
on left and the interfaces of the application to the network on the right.

2.2 Syntax
In order to provide a precise security model for secure group instant messaging, we define a group instant
messaging protocol as the tuple of algorithms

Σ = ((snd, rcv),
(SndM, Add, Leave, Rmv, DelivM, ModG, Ack))

The first two algorithms (snd, rcv) provide the application access to the network (network interface). Thereby
snd outputs ciphertexts and rcv takes and processes ciphertexts. The latter seven algorithms process actions
of the user or deliver remote actions of other users to the user’s graphical interface (user interface)1 . Each
protocol specifies these algorithms and the interfaces among them. To denote that one algorithm algA has
an interface to another algorithm algB we write algAalgB .
Every algorithm has modifying access to the session state of the calling user U for the communication in
group gr. A schematic depiction of the syntax can be seen in Figure 1.
I snd → ~c: Outputs a vector of ciphertexts, designated to the central server, to the network.
I rcvsnd,DelivM,ModG,Ack (c): Receives ciphertext c from the central server and processes it by invoking one
of the delivery algorithms and possibly the snd algorithm.
Actions of user U are processed by the following algorithms, which then invoke the snd algorithm for
distributing the actions’ results to the members Vi ∈ Ggr of group gr:

I SndMsnd (gr, m) → id : Processes the sending of content message m to group gr.

I Addsnd (gr, V ) → id : Processes adding of user V to gr.
I Leavesnd (gr) → id : Processes leaving of user U from gr.
I Rmvsnd (gr, V ) → id : Processes removal of user V from gr.
Every algorithm that processes the calling user’s actions outputs a unique reference string id . In order to
simplify the later defined security goals, we subsume the previous four algorithms as Actn(gr) → id .
Actions initiated by other users are first received as ciphertexts by the rcv algorithm and then passed to
the following algorithms, which deliver the result to user U :
I DelivM → (id , gr, V, m): Stores m with reference string id from sender V in group gr for displaying it to
user U .
1 For clarity, our syntax disregards irrelevant features of instant messaging applications, such as the update of the group title.

4
Figure 2: Double checkmarks in Signal (upper screenshot) and WhatsApp (lower screenshot) indicating that
a group message was successfully delivered to all members’ devices.

I ModG → (id , gr0 ): Updates the description of group gr with ID gr = ID gr0 to gr0 after the remote mod-
ification with reference string id .
I Ack → id : Acknowledges that action with id was delivered and processed by all its designated receivers.
One practical implementation of the Ack algorithm for the acknowledgment of message delivery towards the
sender is depicted in Figure 2: the first checkmark is set when the message is delivered to the central server,
and the second checkmark is only set if the message was delivered to all group members.
For the same reason, for which we subsumed user actions under Actn(gr) → id , we denote both algorithms
DelivM and ModG as Deliv → (id , gr).

2.3 Threat Model

We consider three types of adversaries against secure instant messaging protocols. Thereby we define the
adversaries aiming to break one of the subsequently defined security goals in one designated group named
the target group.
Malicious User. Since all protocols are open for new users, the adversary may act as a malicious user who
can arbitrarily deviate from the protocol specification. To exclude trivial attacks against the instant delivery
of messages, we assume that members of the target group behave correctly by always following the protocol
description.
Network Attacker. This adversary has full control over the communication network, and may access and
modify all unprotected traffic.
Malicious Server. This adversary models attackers with access to the group instant messaging protocol
alone. Motivated by our aim to analyze the reliance of the instant messaging protocols on the transport layer
protection, we regard this attacker type. Besides the direct impersonation of the central server [31, 34], this
adversary models attacks against the transport layer security between users and the central server [4, 6, 41].
To analyze protocols’ resilience against the compromise of user secrets, for the definition of Perfect
Forward Secrecy and Future Secrecy, the following two capabilities are added to the previously described
adversaries.
Long-term Secret Compromise. This enables the adversary to compromise a particular user during
or after the protocol execution, to obtain her long-term secrets. As described for the malicious user, im-
personations are considered as trivial attacks and therefore sessions, started after the compromise, are not
considered as secure.
Session State Compromise. This enables the adversary to compromise a user to obtain the full session
state at some intermediate stage of the protocol execution. In contrast to the long-term secret compromise,
this additional capability is not restricted regarding the impersonation of members in the target group explic-
itly because the respective definitions of Perfect Forward Secrecy and Future Secrecy consider it accordingly.

2.4 Security Goals

Security and reliability in dynamic group communication can be divided into three aspects: 1) confidentiality
of the conversations’ content, 2) integrity of the conversation and 3) the confidentiality induced by the group

5
management. Except from the last aspect, all defined goals are both applicable for group messaging and
direct messaging. Indeed some of them are commonly ruled out because they seem to be reached trivially
in a two party setting.
In addition to the subsequently defined security and reliability goals, there exist stronger definitions for
the purpose of secure communication in groups [26, 32]. As we will argue in section 8, these definitions are
not applicable for instant messaging in the described setting.
Confidentiality. We employ the one-way security notion for the confidentiality of the communicated
content. As such, the definition of pure confidentiality is only applicable for non-compromising adversaries.
We make then use of this definition for Perfect Forward Secrecy and Future Secrecy to regard compromising
adversaries.
I End-to-end Confidentiality. No message m sent by a member U ∈ Ggr in the target group gr via SndM(gr, m)
can be obtained by the adversary.

For defining confidentiality under session state compromise, we say messages of U in gr for messages that
are sent by U by calling SndM(gr, ms ) and messages that are delivered to U via DelivM → (id , gr, V, mr ).
I Perfect Forward Secrecy. On leakage of user U ’s session state, confidentiality of past messages of U in gr
is maintained.
Future Secrecy – also known as Post-Compromise Security [20] – intuitively means that the protocol contin-
uously renews the session state of a user’s session and thereby invalidates old states in this session. Known
protocols [9, 20, 21] reach this property by the interaction with the session partners.
Accordingly we define one group round-trip as the sequence of actions after which all members of a group
output ciphertexts via snd and all group members received the ciphertexts designated to them via rcv.
I Future Secrecy. Let λ be a constant, then λ group round-trips after the leakage of user U ’s session state,
confidentiality of future messages of U in gr is established.
The definition for groups can easily be applied to the two user setting. The proof of Cohn-Gordon et al. [20]
shows that Signal provides Future Secrecy for λ = 1 for a static ‘group’ of size 2.
Integrity. Defining integrity as a goal for a consecutive communication not only targets end-to-end integrity
of single messages, but the whole communicated content.
I Message Authentication. If a message m is delivered to V ∈ Ggr by DelivM → (id , gr, U, m), then it was
indeed sent by user U by calling SndM(gr, m).

While it is implied by Message Authentication that other users cannot plant messages into a communication
between two parties, for groups it is necessary to be required2 :
I No Creation. If a message m is delivered to member U ∈ Ggr via DelivM → (id , gr, V, m) with sender V ,
then V ∈ Ggr holds.

Every member in a group can contribute content messages and it is therefore important for the receiver to
know the exact sender. This differs for the initiation of group management actions (see Confidentiality by
Group Management). Certainly, the following security goals are applicable to all actions a user initiates.
For generality the definitions make use of the abstract algorithm names for actions of a user and for the
respective delivery by its receivers3 .

I No Duplication. For every user action Actn(gr) → id initiated by user U for group gr the resulting delivery
algorithm Deliv → (id , gr) is invoked at most once by each group member Vi ∈ Ggr .
2 Pleasenote that disregarding No Creation and Closeness as required goals provides a weak definition of Reliable Multicast.
3 If
Actn(gr) → id refers to the SndM algorithm, then Deliv → (gr, id) refers to the DelivM algorithm. All remaining actions
by a user are delivered by the algorithm ModG.

6
I Traceable Delivery. If the delivery of user action Actn(gr) → id by user U is acknowledged to user V 0 ∈ Ggr
by invoking Ack → id , then the respective Deliv → (id , gr) algorithm was invoked by all members
Vi ∈ Ggr \ {U }.
Intuitively Traceable Delivery means that if a member is notified about the termination of an action performed
in the group, then the respective delivery was invoked by all its members4 . Please note that we do not restrict
who obtains acknowledgments by the protocol. Commonly the initiator of an action is informed about the
delivery state. Acknowledging the leaving of a user to this leaving user is, however, of little value.
We want to remark that Traceable Delivery provides no guarantees for the delivery of sent messages; it
only provides guarantees regarding the validity of acknowledgments. A delivery guarantee can indeed not
be provided since the centralized server can always refuse ciphertexts’ forwarding.

I Weak FIFO Order. If user U calls Actn1 (gr) → id 1 before Actn2 (gr) → id 2 , then member V ∈ Ggr will
not invoke Deliv1 → (id 1 , gr) after she invoked Deliv2 → (id 2 , gr).
I Weak Causal Order. If user U1 calls Actn1 (gr) → id 1 and user U2 calls Actn2 (gr) → id 2 after she in-
voked Deliv1 → (id 1 , gr), then member V ∈ Ggr will not invoke Deliv1 → (id 1 , gr) after she invoked
Deliv2 → (id 2 , gr).

In contrast to all other security and reliability goals, ordering – in its strict definition – limits the instant
delivery of messages: a later message would only be delivered if all its predecessors were delivered. For this
reason we relax the definition such that the instant delivery is possible under the restriction that message
omissions are accepted as long as the order among delivered messages is preserved.
Confidentiality by Group Management. Group protocols must fulfill additional requirements to meet
confidentiality as a security goal. While authenticity for content messages is defined via Message Authenti-
cation, the following definitions also imply authenticity for group management actions:

I Additive Closeness. If member U ∈ Ggr modifies the member set Ggr old
to Ggr0 via (id , gr0 ) ← ModG :
old ∗ ∗
|Ggr | < |Ggr0 |, ID gr = ID gr0 , then an administrator U ∈ Ggr called Add(gr, V ) to add new member
old
V = Ggr0 \ Ggr to the group.

I Subtractive Closeness. If member U ∈ Ggr modifies the member set Ggr old
to Ggr0 via (id , gr0 ) ← ModG :
old
|Ggr | > |Ggr0 |, ID gr = ID gr0 , then either an administrator U ∗ ∈ Ggr
∗
called Rmv(gr, V ) to remove member
old
V = Ggr \ Ggr0 from the group, or member V called Leave(gr) to leave the group.

While Additive Closeness is a security goal, Subtractive Closeness is defined as a correctness property and
thereby targets reliability. Turning the latter into a security definition, requiring the enforcement of member
set reduction, is of no value in a centralized server structure where the server can drop every ciphertext.
Since Traceable Delivery is applied to all user actions, a certain security assertion can be made: if a member
invokes Ack → id for the removal operation with the same id , then the removal was conducted by all
remaining members.
Secure and Reliable Group Instant Messaging.

Definition 1 A protocol Σ is a Secure and Reliable Group Instant Messaging Protocol if it fulfills End-to-
end Confidentiality, Message Authentication, No Creation, No Duplication, Traceable Delivery, Additive
Closeness, and Subtractive Closeness in the presence of Malicious User, Network Attacker, and Malicious
Server.
Furthermore the protocol may reach Perfect Forward Secrecy and Future Secrecy to defend compromising
adversaries.
4 It may seem that this property is implied by Message Authentication and No Creation. It would therefore be necessary

to implement Ack by explicit acknowledgment messages that are processed as content messages. In order to keep our model
generic, we define Traceable Delivery independent of assumptions on the implementation.

7
 Substantiating reliability of the protocol is reached if it provides Weak FIFO Order and Weak Causal
Order. Our ordering definitions, however, illustrate that there exists a tradeoff between reliability and instant
message delivery. As such we address ordering as a soft goal for secure and reliable instant messaging. An
additional discussion regarding this tradeoff can be found in section 8.

3 Methodology
We describe our general evaluation methodology in the following.
Test Setup. For all three investigated protocols, we used the official Android versions provided by the
Google Play Store. In order to analyze groups, we created a group of at least three members using three
different devices.
Protocol Descriptions. We derived the protocol descriptions by analyzing the source code and debugging
the implementations. For Signal, we used source code available on Github [56, 57]. Since neither WhatsApp
nor Threema provide official open source implementations, our analysis of these protocols mainly bases on
the traffic that was received by unofficial protocol implementations [10, 30]. The respective messages and
operations were sent by the official applications running on different devices and transmitted via the official
messenger servers.
Proof-of-Concepts. In order to substantiate the described protocol shortcomings, we were able to imple-
ment proof-of-concept exploitations for a subset of them. Attacks involving a malicious server could only
partially be exploited since we did not have access to the official servers. The protocol descriptions however
strongly suggest our evaluation results. Details are given in sections 4.3, 5.3, and 6.3.
Responsible Disclosure. All tested and untested weaknesses were acknowledged by the developers during
the responsible disclosure process. An overview on the results of our protocol evaluation can be found in
section 7. Threema has already updated its application in response.
Constraints of Attack Descriptions. Even though the developers do not explicitly claim to satisfy our
definition of security, we will call discrepancies between the security provided by the protocols and security
required by our definition attacks since our model requires its fulfillment.
Description of an Example Protocol Run.
In order to provide a comparable description of the protocols, Figures 4 (Signal), 6 (WhatsApp) and
8 (Threema) depict an example protocol run of each protocol containing direct and group communication.
The figures are meant to highlight the differences in the three group messaging protocols. The depicted
protocol sequence covers the key usage for the following actions:
(1) User A sends a direct message m = "Hi" to user B.
(2) User A sends a group message m = "Hey" to a group with members G = {A, B, C}.

(3) User A receives the information that user B leaves the group with members G = {A, B, C}, such that
its members are G = {A, C} afterwards.
(4) User A sends a group message m = "Ho" to the group with members G = {A, C}.
(5) User A creates a group with members H = {A, B, C}.

(6) User A sends a group message m = "Yo" to the group with members H = {A, B, C}.
(7) User A receives a group message m = "Yey" from user C to the group with members H = {A, B, C}.

8
4 Signal
Signal is an open source instant messaging application available for Android, iOS, and as a Google Chrome
extension [58]. It is well-known for its key exchange that reaches the goals Perfect Forward Secrecy and
Future Secrecy. Previous analyses focused on the key exchange protocol and direct messaging between two
participants [20, 29].
Signal provides group messaging of text messages and other content such as pictures or videos. We
restrict our investigation to group messaging including the transmission of text content.
In Signal, a user is allowed to run multiple devices simultaneously, for instance, one mobile app (iOS or
Android) plus an arbitrary number of Google Chrome extensions. Thereby sending and receiving of messages
from all connected devices is possible and the chats (groups, and direct messages) are synchronized among
them. Our analysis does not consider this feature and assumes multiple users with one device each to form
groups because this strengthens the comparability of the analyzed protocols.
The Signal application implements Curve25519 [12] and HMAC-SHA256 [7] for the key derivation (Dou-
ble Ratchet algorithm). The HMAC is also used for message authenticity in combination with AES-CBC-
PKCS5Padding [23] for preserving confidentiality of the messages. We assume these implementations secure
and did not look for implementation issues therein.
In the following sections, we shortly introduce the general protocol setting stripped down to the essence
necessary to understand the group communication. We then describe the group protocol and evaluate it
regarding the defined model. Figures 4, 6, and 8 depict an example protocol run of the analyzed protocols
and thereby give an overview on the fundamental differences in Signal, WhatsApp, and Threema.

4.1 General Initialization Protocol

4.1.1 Session Establishment with the Server
For identification and authentication, each user (more precisely, each device) holds credentials. This is a
user name, which corresponds to the user’s phone number, and a password that is randomly chosen by the
Signal server during the device’s initial usage. The credentials are sent to the Signal server in every request.
Additionally, Signal uses Transport Layer Security (TLS) as a cryptographic primitive to protect the channel
between users and the server.

4.1.2 Key Agreement and Key Derivation

The initial shared secret (root key) between two parties is calculated with the X3DH Key Agreement Protocol
[39] that uses static and ephemeral Diffie-Hellman shares of both parties. This root key initializes the Double
Ratchet algorithm (DR algorithm) [38], which can be seen as a stateful encryption algorithm [8]. The
algorithm’s state – consisting of multiple keys – is updated asymmetrically by both parties during the
communication and symmetrically as long as only one communication party contributes messages. This
key update process is called ratcheting. When only the symmetric updating is conducted – as in WhatsApp
groups – this is called symmetric ratcheting. The DR algorithm is consequently the combination of symmetric
and asymmetric ratcheting. Thereby the initialization keys of the symmetric ratcheting are called chain keys.
By its characteristics, the symmetric ratcheting cannot provide Future Secrecy but provides Perfect Forward
Secrecy of the resulting keys. The asymmetric ratcheting provides both properties such that the combination
(DR algorithm) also provides both properties.
The encryption DRE and decryption DRD of the DR algorithm have modifying access to the keys which
are stored in the state (denoted as A, B in Figures 3 and 5). The key for encrypting and decrypting is
generated as soon as it is needed and removed directly afterwards. Only intermediate keys (e.g., chain keys)
that are not used for encryption and decryption are stored in the state.
$
c←
− DREA,B (m), m := DRDA,B (c)

9
A schematic description of the DR algorithm when used in the Signal and WhatsApp messaging protocol
can be seen in Figure 9. The usage of the key streams can be seen in the example protocol run in Figures 4
and 6.

4.2 Group Protocol

Figure 3: Schematic depiction of Signal’s traffic, generated for a message m from sender A to receivers B
and C in group gr with Ggr = {A, B, C}. Transport layer protection is not in the analysis scope (gray).

In contrast to other secure group messaging protocols (e.g., WhatsApp and Threema), Signal imple-
ments non-administered groups such that all members of a group can manipulate the group management
∗
information (i.e. Ggr = Ggr ). The group is uniquely referenced by a random 128 bit vector ID gr .

4.2.1 Group Messages

A group message in Signal is treated as a direct message but the group ID is additionally attached to the
encrypted plaintext. By using this approach, the Signal server cannot distinguish a group message from a
direct message. Together with the timestamp tm , the message is statefully end-to-end encrypted for each
member of the group. Every resulting ciphertext is then sent to the server together with the respective
receiver ID and the timestamp via TLS. The server forwards the end-to-end encrypted messages to the
respective group members via TLS, as well. When the server forwards the message to the receivers, it
replaces the receiver’s ID by the sender ID.
Figure 3 describes the format of a group message from member A to members B and C in group gr that
is sent via the server S 5 .
Messages for group management contain the updated group information in the end-to-end encrypted
message part:

m,
 if SndM(gr, m)
old
m := (Ggr , info gr ), if Add(gr, V ) : Ggr := Ggr ∪ {V }

leave, if Leave(gr)


The server acknowledges messages from the sender, and the receivers acknowledge the receipt to the
server. These acknowledgments contain the sender ID and the timestamp tm of the original message but not
the group ID. Once a receiver’s acknowledgment is gained, the server forwards this receipt acknowledgment
to the sender. All acknowledgments are not end-to-end encrypted, thus only rely on TLS. The sender collects
the members’ acknowledgments and displays a successful receipt (see checkmarks in Figure 2) as soon as all
receivers’ acknowledgments arrived.
5 We omitted irrelevant fields regarding our evaluation in the message format. The whole format can be found in the format

description [55]. We also left out Google’s Cloud Messaging (GCM) service for clarity.

10
4.2.2 Group Management
The group management consists of two protocol flows: an update flow and a flow that is processed once a
user leaves the group.
The update flow is used for the creation of a group, for adding users, and for changing group information
like the title of a group. For creating and updating a group, the modifying member sends an end-to-end
encrypted message to each group member, containing the new set of members Ggr and the new group
information info gr . Signal does not allow removing of other members from a group. As a result an update
message, containing not the complete member set Ggr , does not lead to the removal of missing group members.
If a member choses to leave the group, she sends a leave information together with ID gr end-to-end
encrypted to every other member.

Figure 4: Schematic depiction of key streams of A and ciphertexts from and to A that are used when sending
and receiving direct and group messages and modifying the groups in Signal. The legend of the graphic also
regards to Figures 6 and 8.

4.2.3 Example Protocol Run

Figure 4 depicts an example protocol run. We denote the key derivation function (ratcheting) by an arrow,
which forks multiple keys used for encryption and decryption (strongly simplified). The only difference
between group messages and direct messages can be found inside the end-to-end encrypted plaintext. Sum-
marized, one group message results in multiple direct messages. The group management messages are also
communicated via multiple direct messages.
As Figure 4 shows, A maintains two separate key streams, one for the communication with B and the
one for C. Both are separately used for direct and group communication (with B resp. C).

4.3 Security Evaluation and Observations

We practically verified two weaknesses of Signal and created proof-of-concepts for them. First, we burgle into
a group by writing group management messages into it. Second, we make a victim believe that a message is
delivered while it is not.

4.3.1 Burgle into the Group

Performing the following steps allows an attacker to become a member of the targeted group. The at-
tacker can read any further group communication and contribute own content to the group chat. Because
every group member in Signal has administrative privileges, the attacker automatically becomes a group
administrator.
Preconditions. The attacker only needs to know the group ID ID gr and the phone number B of one
member.
I Malicious User. In the simplest case, the attacker was a former member of the group, and has recorded
the group ID using a modified client software.

11
I Session State Compromise. ID gr is stored in the session state and can thereby be revealed via this com-
promise.

Description. The attacker A, knowing the secret group ID gr , sends the following group update m =
({A}, info gr )) to the known phone number B, using Signal’s direct messaging channel between A and B:

(B, t, DREA,B (ID gr , t, ({A}, info gr )).

In fact, A could also send a content message such that only this message is sent to B in the group without
adding A to the group. This message breaks the No Creation security goal. After receiving and validating
this message, B’s receiving Signal application updates its own group description:
new
Ggr := Ggr ∪ {A}.
new
B will use this set Ggr in all future communications with the group. However until now, A will only receive
group messages from B, but not from the other members.
This changes once group member B sends a second update message to the group. For example, if B
changes the group icon (which is part of info gr ), she will send some message

(U, t0 , DREB,U (ID gr , t0 , (Ggr

new
, info 0gr ))
new
to all members U ∈ Ggr . After receiving this message, each member U will update her group member set
new
to Ggr . From now on, A receives all group messages.
To all other group members except B, it seems that B has added A to the group, which would be fine
since B was a member and thereby an administrator of the group.
Optimizations. If A knows the phone number of multiple members, A can send this group update message
(or a content message) to all of them. Thereby No Creation and Additive Closeness is broken for a larger
set of members, and it is more likely that one of these members sends the second update message.
Impact. The protocol does not provide the following security goals:
I No Creation. A group member B accepts a content message by A, who is not part of the group.
I Additive Closeness. By sending an update message, A can add herself to the group which breaks Additive
Closeness.
I Future Secrecy. After adding herself to the group, the confidentiality of future plaintext messages is com-
promised.

4.3.2 Forging Acknowledgments

Signal provides information on the receipt status of messages for the sender in groups and for direct messaging
(see Figure 2). However, this information can be forged by the Signal server.
Even though the Signal protocol internally provides two features to detect that sent messages were not
received by the desired recipient, the detection is not effective. Hence messages can stealthily be dropped
during the transmission.
Preconditions.
I Malicious Server. The attacker A must be able to directly deliver a message to the victim’s Signal appli-
cation. Therefore, A must either compromise the Signal server, or be able to bypass the transport layer
protection.

Description. As soon as a sender B sends a group message

(U, tm , DREB,U (ID gr , tm , m))

12
to all members U ∈ Ggr , the attacker A drops the message, for instance, she does not forward it to member
X. She then sends multiple acknowledgment response messages to B:

(U, tm , ACK), ∀U ∈ Ggr \ {B}

B’s application displays the successful delivery even though member X never saw message m.
Impact. The attack violates the following security goal:
I Traceable Delivery. The receivers, for whom the message was dropped, never see B’s message. As a
consequence, B’s device indicates a successful message delivery (see Figure 2) while members did not
receive the message.
Despite the fact that the DR algorithm provides a continuous key stream, omissions of keys are ignored at
the receiver’s side and thereby the statefulness of the key stream is not used. Since receiver acknowledgments
in Signal are not end-to-end encrypted, A can drop messages and create the acknowledgments itself. Dropping
messages is however slightly restricted: the client application only maintains the last 2000 keys such that
a further deviation of the sender’s and receiver’s key streams causes the encryption to fail 6 . As a result
Traceable Delivery is neither provided for group messages nor for direct messages by Signal.

4.3.3 Ordering
The Malicious Server cannot only drop messages, but also reorder them. The receiving application orders
simultaneously received messages by the timestamp which is manipulable for the server. The decryption of
received messages follows this order. Since old omitted keys are removed after a 2000 new keys are derived,
reordering by the server is restrictedly possible. Henceforth neither FIFO Order nor Causal Order are
provided by Signal.

5 WhatsApp
WhatsApp is a closed source instant messaging protocol. It uses the Signal protocol for key exchange and
encryption but is independent of Signal’s messaging protocol – especially, it is independent of the Signal
group communication protocol. WhatsApp is available for most mobile operating systems7 .
Even though WhatsApp is a closed source application, there exist open source implementations [30,
42] whose usage is forbidden and aimed to be prevented by WhatsApp [64]. We used a fork8 of Galal’s
implementation [30] to analyze the traffic, generated by the official WhatsApp Android application9 .
The algorithms for exchanging the keys and encrypting on the end-to-end layer use the same cryptographic
primitives as the implementation of Signal relies on. The signatures of group messages are calculated on
Curve25519 [12].
Our analysis confirms the description of WhatsApp’s technical white paper [33] regarding the implemen-
tation of the Signal key exchange protocol but further examines the messaging protocol as a whole. As a
result, we present several protocol and implementation shortcomings.

5.1 General Initialization Protocol

5.1.1 Session Establishment with the Server
WhatsApp uses Noise Pipes [49] to protect the communication between the clients and the server on the
transport layer [33]. The Noise Pipes are implemented with Curve25519, AES-GCM, and SHA256.
6 https://github.com/WhisperSystems/libsignal-protocol-java/blob/master/java/src/main/java/org/

whispersystems/libsignal/state/SessionState.java#L41
7 https://www.whatsapp.com/download/
8 https://github.com/colonyhq/yowsup
9 Version 2.17.107 from the Google Play Store

13
Figure 5: Schematic depiction of traffic, generated for a message m from sender A to receivers B, C in group
gr with Ggr = {A, B, C} in WhatsApp.

5.1.2 Key Agreement and Key Derivation

The Signal key exchange protocol, consisting of the X3DH Key Agreement Protocol [39] and the DR algorithm
[38], is integrated in WhatsApp in order to establish a confidential channel for messaging between two
users [33]. A detailed description of these building blocks can be found in section 4 and Figure 9.

5.2 Group Protocol

WhatsApp limits the maximum number of users in a group to 256. A group is uniquely referenced by ID gr ,
∗
containing the creator’s user ID and a timestamp. The initial set of administrators Ggr contains the group
creator. By adding members to the administrator set, this set can be enlarged. The content of messages
is protected on the end-to-end layer while group modification messages are only protected on the transport
layer. As a result, the WhatsApp server is mainly responsible for the distribution of group messages based
on the group management. This is a main difference in comparison to Signal and Threema.
Although WhatsApp integrates the Signal key exchange protocol for direct messaging, keys in groups are
used very differently: instead of sending encrypted messages to each group member separately (cf. section 4),
each user generates a symmetric key (chain key) for encrypting only her messages to the group. The key
is then once transported to every other group member using the DR algorithm for direct messaging. The
dedicated group key is not refreshed by Diffie-Hellman ratcheting but only with the symmetric key derivation
function in contrast to direct messaging.

5.2.1 Group Content Messages

All messages between the users and the server are transport layer encrypted. On the end-to-end layer only
the actual content is encrypted and integrity protected under the symmetric ratcheted encryption SRE (see
subsubsection 4.1.2) with a message key from the symmetric ratcheting of the sender’s chain key. As a result,
the sender calculates one ciphertext for the whole group. This ciphertext is then signed with the current
signature key for the respective group (denoted as Sig in Figure 5). The receiving members can compute
the symmetric key for the decryption from the sender’s chain key, that was sent with her first message after
a group management operation (see below). Apart from the ciphertext, the transcript to the server also
contains ID gr and a message identifier ID m . The server adds the sender ID, a readable sender name and a
timestamp tm to the message for the receivers.
Notifications on the receipt status for the sender and an acknowledgment for the WhatsApp server are
sent protected on the transport layer only. The server forwards the receipt statuses to the sender. As soon as
all members’ receipts are collected by the sender, the successful delivery is displayed by the double checkmark
(see Figure 2). Additionally, the individual receipt statuses are listed in an extended menu.
As a result, group messages only result in one ciphertext to the server independent of the group size.
The WhatsApp application enables users, for sending a message, to highlight a reference to a previous
message. The protocol therefore attaches the whole referenced message and its ID ID m to the newly sent

14
message, such that the referenced message, the new message, and the ID of the referenced message are
encrypted.

5.2.2 Group Management

Group administrators send group modifications to the server. These modification messages are only en-
crypted on the transport layer and no cryptography is used to protect them on the end-to-end layer between
a group’s members.
The modification messages contain the tuple OP = (action, H) where action indicates the operation
type like adding or removing of members, adding of administrators, leaving of members and H is the set
of affected users. After an administrator sent a message of this format to the server, the information is
distributed to all group members:

(A, ID gr , name A , ID OP , tOP , OP )

The session state of each member consist of the chain key and a signature key pair. Both are generated
freshly for the first message to a new group or for the first message to the group after a user left or was
removed from it as it can be seen in Figures 6 and 9. After the generation, the public signature key and the
chain key are distributed to all members via direct messaging between the sender and the respective receiver
using the DR algorithm. Consequently, the first message after which the group secrets are updated results
in |Ggr | ciphertexts. When a user is added to the group, the current chain key and the signature key of each
member is sent along with the first message after adding the new user the same way.

Figure 6: Schematic depiction of key streams of A and ciphertexts from and to A that are used when sending
and receiving direct and group messages and modifying the groups in WhatsApp.

5.2.3 Example Protocol Run

Figure 6 depicts an example protocol run. In contrast to Signal, WhatsApp maintains different key streams
for direct messaging and for group messaging. Keys for the group communication are generated once they
are used and distributed via the direct communication channels. If a group is created or a user is removed
from a group, each member generates a new group key. Every member needs to store one key for every
direct communication and one key for every member in each group. The information on group modifications
is not end-to-end encrypted.

15
5.3 Security Evaluation and Observations
We observed two shortcomings in the design of WhatsApp’s group protocol that allow to (1) burgle into a
group and to (2) forge acknowledgments. The shortcomings have similar results as the attacks on Signal,
although the underlying protocol and exploitation differ.

5.3.1 Burgle into a Group

The subsequently described protocol design weakness allows an attacker A, controlling some of the messages
sent by the WhatsApp server, to become a member of the group or add other users to the group without
any interaction of the other users.
Preconditions. The attacker A needs to modify the group information at the client side.
I Malicious Server. can send group modification messages to the group members.
Description. Suppose we have a group gr with three members B, C, D whereas B is the group administrator:
∗
gr = (ID gr , Ggr = {B, C, D}, Ggr = {B}, info gr )
The attacker A can then break Additive Closeness in the group by conducting the following steps. The
attacker sends the following group modification message to users C, D10 :
(B, ID gr , name B , ID m , tm , (add, {A}))
Each receiving member sets
new
Ggr := Ggr ∪ {A}
and sends her current chain key and signature public key to A as soon as she sends a message to the group.
Since the modification of the group information is not bound to a cryptographic operation, it is not
necessary that a group member initiates the operation. The WhatsApp server can thereby forge a message
that indicates an added member for a group.
Optimizations. The attack can be optimized by also adding A to B’s view of the group. There are different
approaches to achieve this: (a) if B’s client accepts group modification messages with source B even though
new
B did not originate the operation, the described message is also sent to B to update Ggr := Ggr ∪ {A},
(b) if B’s client accepts this message from a non-administrative member, the message is sent to B with
source C or D, (c) in bigger groups with two or more administrators, the attacker pretends the message to
be originated from one administrator when sending it to another.
Impact. Due to the described attack, the protocol does not reach:
I Additive Closeness. A can write to the group and read messages.

5.3.2 Forging Acknowledgments

Even though WhatsApp’s graphical user interface implies that a sender sees the receipt status of sent
messages (double checkmark), this weakness allows the attacker to stealthily drop messages.
Preconditions. The attacker needs to drop messages and send notifications to the sender.
I Malicious Server. can manipulate the transcript between sender and receivers.
Description. The attacker drops a group message from the sender and replies with acknowledgments,
indicating the successful receipt for all members. These acknowledgments are of the form
(U, ID gr , ID m , tm , ack), U ∈ Ggr \ {A}
where A is the original sender of the message.
Impact.
10 Schematic representation of modification message for adding a new member to a group.

16
I Traceable Delivery. WhatsApp’s delivery state information is vulnerable towards the described attacker.
Although the key derivation from the chain key provides a consecutive key stream, the omission of message
keys is ignored by the receivers to a certain degree. Our practical evaluation showed that 1999 omitted keys
were ignored. Additionally the receiver’s acknowledgments are not authenticity protected. Consequently
Traceable Delivery is not provided because the attacker can drop sent messages and tamper the receiver’s
receipt status arbitrarily by sending forged receipt notifications to the sender. Although our description
covers the group setting, this weakness directly applies for direct messaging.

5.3.3 No Future Secrecy

Since Diffie-Hellman key ratcheting, as one main component of the DR algorithm, is not integrated into the
encryption of group messages, Future Secrecy cannot be reached in WhatsApp.

5.3.4 Ordering
The sending time for a message is set at the server side. The receiving clients decrypt and display the
messages in the order the server transmits them. If messages are received in a different order than they were
encrypted, this is disregarded by the client as the omission of message keys is. As a result a Malicious Server
cannot only drop messages but also reorder them because they are not listed in the order of encryption but
in the order of transmission by the server. By employing a reference to a previous message, Causal Order is
at least preserved for this reference.

5.4 Impact of the Weaknesses’ Combination

The described weaknesses enable attacker A, who controls the WhatsApp server or can break the transport
layer security, to take full control over a group. Entering the group however leaves traces since this operation
is listed in the graphical user interface. The WhatsApp server can therefore use the fact that it can stealthily
reorder and drop messages in the group. Thereby it can cache sent messages to the group, read their content
first and decide in which order they are delivered to the members. Additionally the WhatsApp server can
forward these messages to the members individually such that a subtly chosen combination of messages can
help it to cover the traces.

6 Threema
Threema is a proprietary closed source instant messenger protocol available for most mobile operating systems
[60]. It uses a centralized server architecture for relaying messages to the respective receivers and distributing
user keys. The messenger application provides direct messaging and group chats. In both settings not only
text messages but also pictures, arbitrary files, contacts and other content can be sent.
Even though the application is closed source, there are open source implementations available: we based
our analysis on the implementation of Berger [10] which was based on an analysis of Ahrens [3]. We used the
open source implementation only for analyzing the protocol flow and for proof-of-concept exploitation. We
then observed the results of an attack on a parallel running, original Android application from the Google
Play Store, which simulates the victim.11

6.1 General Initialization Protocol

During the creation of an identity, the application of user A generates a Diffie-Hellman share pk ltA , sends
it to the central key server of Threema with a fresh proof of possession of the corresponding private part
and stores this private part sk ltA locally. The Diffie-Hellman share represents the long term public key of the
11 Version v.2.92.323

17
Figure 7: Schematic depiction of traffic, generated for a message m from sender A to receivers B, C in group
gr with Ggr = {A, B, C} in Threema.

user. It is used to authenticate the user during the session key agreement with the server and for all key
agreements with other users.

6.1.1 Session Establishment with the Server

ses
Once the application is started, a proprietary key exchange protocol is executed to derive a session key kA,S
for the channel between the user A (client) and the Threema server S. Both, the server’s and the client’s
long term keys are used for the authentication. The protocol is built up on three dependent Diffie-Hellman
key exchanges (DHKEs).
The session channel encryption and the end-to-end encryption are implemented with the XSalsa20 cipher
[13] with integrity and authenticity protection using the Poly1305-AES MAC [11].
We identified that Threema implements Curve25519 for all DHKEs, which is also described in [61].

6.1.2 Key Agreement

A client can either request the public key of a contact from the central Threema key distribution server or
scan it directly from the contact’s device. In either case, two users A, B derive a symmetric contact key
kA,B = ECDH(sk ltA , pk ltB ) = ECDH(sk ltB , pk ltA ) from the DHKE of the long term key shares. This key is used
for all direct and group messages between these two users as it can be seen in Figure 8.

6.2 Group Protocol

∗ ∗ ∗
In Threema, only the creator Ugr of a group is the administrator Ggr = {Ugr }. Threema limits the number
of group members to 50 per group. Each group is uniquely referenced by ID gr containing the administrator’s
user ID and a random bit vector, each of 64 bits.

6.2.1 Group Messages

All group messages contain the reference ID gr as an identification value in the end-to-end encrypted part.
The transmission is implemented the same way as for direct messages: one group message is sent to every
member as a message that is encrypted with the long term contact key kA,U ∀ U ∈ Ggr \ {A} between the
sender A and the respective group member (see Figure 8). These end-to-end encrypted messages are sent via
the encrypted session channel between the respective users and the server. The format of a message can be
seen in Figure 7 where ID m,U is a random message identifier for the respective receiver, tm is a timestamp
and nameA is the readable name of A. The figure disregards message type labels on the direction and the
content type of the message.

18
Figure 8: Schematic depiction of keys of A and ciphertexts from and to A that are used when sending and
receiving direct and group messages and modifying the groups in Threema.

Additionally to the group ID, the end-to-end encrypted part can contain:


 m, if SndM(gr, m)

G ,
gr if update message 1
m :=


 info gr , if update message 2
leave, if Leave(gr)


In contrast to direct messages between two users (outside of a group), content group messages are not end-
to-end acknowledged: The server acknowledges the sender’s messages and the receivers acknowledge the
receipt towards the server. The latter acknowledgments are only encrypted by the session channel and not
forwarded to the sender (i.e. the sender has no information on the receipt status).
Like WhatsApp, Threema provides the users the ability to explicitly refer to a previous message when
writing a new one. Thereby also the whole referenced message is attached to the new message (and then
encrypted together).

6.2.2 Group Management

The group management is split into two protocol flows: an update flow and a flow that is processed for a
user to leave. The update flow is used for the creation of a group, for adding and removing users, and for
changing group information like the title of a group. Note that in contrast to Signal, Threema allows the
removal of other members in a group.
∗
Group creation and update follow the same protocol consisting of two messages, sent from Ugr to all
∗
U ∈ Ggr \ {Ugr }: (1) a message containing the new set Ggr and (2) a message containing the updated info gr
of the group, such as the group title. The first message is sent to all users that were members until the
operation is started and to all users that become a member due to the operation. The second message is
only sent to users that will be members after the operation.
If a user leaves the group, she sends that information together with the group reference end-to-end
encrypted to all other members.
A group member can request the administrator to synchronize the group information. The administrator
then starts the group update protocol with the current group information.

6.2.3 Example Protocol Run

Analogically to Signal, Threema handles group messages similarly to direct messages: a group message is sent
as multiple direct messages. In contrast to Signal, a flag, which is readable by the Threema server, indicates
the type of the message (e.g., group content message). As depicted in Figure 6, all group messages and all
direct messages are encrypted and decrypted with the same key. There is no key derivation in Threema.

19
6.3 Security Evaluation and Observations
We practically carried out a replay attack on Threema with a proof-of-concept implementation. The attack
breaks No Duplication and Additive Closeness. We further observed that Threema does not achieve Perfect
Forward Secrecy, Future Secrecy, or Traceable Delivery.

6.3.1 Replaying Messages

Even though a random ID is assigned to every message, messages can be resent to a group easily and thereby
No Duplication is broken for the Threema group messaging protocol.
Preconditions. The attacker needs access to the channel somewhere between sender and receiver.
I Malicious Server. has control over the transmitted ciphertexts.

Description. The attacker A needs to record an end-to-end encrypted message

(A, B, name A , tm , IDm,B , EncA,B (ID gr , m))

once and can resend this message to sender A or receiver B later repeatedly:

(A, B, name A , t0m , IDm,B

0
, EncA,B (ID gr , m))

(B, A, name A , t0m , IDm,B

0
, EncA,B (ID gr , m))
Since Threema only protects the group ID and the actual content of a message on the end-to-end layer,
A can update the timestamp (and all other unprotected metadata) and replay the encrypted message. The
established encryption key is used for both directions between sender and receiver, thus, messages can be
resent to the receiver and to the sender.
Impact. The attack violates the following security goals:
I No Duplication. A can replay messages.

I Additive Closeness. This weakness also affects the Additive Closeness of a group because A can rewind
every group manipulation by resending previous group update messages. For example, A can rewind the
removal of a group member.

6.3.2 No Forward and Future Secrecy

In Threema, every message between two users is encrypted with the same key, derived from the DHKE of their
long term public keys. Consequently no security property can be reached when considering compromising
attackers.

6.3.3 No Traceable Delivery

The Threema application provides no information on the receipt status of sent group messages. Consequently
this property cannot be attacked.
Receivers actually acknowledge group messages only towards the server. As a result, the sender cannot
verify the message status such that delivery in Threema cannot be traced.

6.3.4 Ordering
Messages received by the application are ordered by the receiving time. The sending time is additionally not
protected on the end-to-end layer. Therefore the Malicious Server can reorder messages arbitrarily during
the transmission. By referencing previous messages, at least for this reference Causal Order is preserved.

20
6.3.5 Additional Information Leakage
When a user in Threema sends a message to a group of which she is not a member, this message is not
accepted by its members. In order to indicate this non-member status, the group administrator starts the
group update protocol and sends both the set of members and the title to this user in response. A user who
left the group or who was removed from the group can thereby keep informed about the group’s management
information. 12

7 Evaluation Summary

liv n
tu Sec ity

io

at ry
at
l

e
ia

cy

ic

at n
y
ar ent

re

ea ent

o
ec

n
D
d

sg ecr

io
h
Fo onfi

lic
ut

ss
S

bl
d

up

ne
A

re
C

re

se
C
rw

.
ac
E

lo
o

o
E2

Fu

Tr
M

C
Signal 6í Š 6í 6í
WhatsApp 7 Š Š Š
Threema 7 7 7 Š Š Š

Table 1: 7: Not implemented security goal;

6í : Not reached against Malicious User who can compromise victim;
Š: Not reached against Malicious Server ;
Gray symbols: not provided as side effect of another unreached security goal

Table 1 summarizes our evaluation results. The gray cells indicate, that a security goal is not reached
because another security goal is not provided as well. Since a compromising Malicious User can break the
Additive Closeness of Signal, Future Secrecy is implicitly violated as well. Signal is directly attackable
regarding Additive Closeness and No Creation. In contrast, breaking No Creation in WhatsApp results from
breaking Additive Closeness. Threema is vulnerable to No Duplication. This can consequentially be used for
breaking Additive Closeness by rewinding group management operations and breaking Additive Closeness
again breaks No Creation. Threema updated their application in response to our responsible disclosure.
Consequently No Duplication, No Creation, and Additive Closeness are not attackable anymore.
The descriptions of the attacks against the protocols regarding our security model always selects the
weakest successful attacker. Consequently a Compromising Malicious Server can break the same goals as a
Malicious User with compromising access to the victim’s secrets.

8 Lessons Learned
In this section we first briefly describe specific fixes for the analyzed protocols and then evaluate general
approaches for reaching the security properties efficiently.

8.1 Fixing the Protocols

8.1.1 Signal

Additive Closeness and No Creation. In Signal, Additive Closeness can be reached by implementing
a simple check when receiving a group message: if the sender is not part of the current group, the message
12 This weakness was also fixed in Threema version 3.14.

21
is dropped. This efficiently preserves No Creation and Additive Closeness. As a side effect, the group ID
can then be public knowledge. We discussed this proposal with Open WhisperSystems, but it turned out
that this verification is unfeasible due to their current implementation. Open WhisperSystems is currently
developing a new group management system with advanced administrative features so that they decided not
to apply our fix.
Traceable Delivery. Signal could reach Traceable Delivery by treating receipt messages like content
messages and thus end-to-end encrypt them13 . This would guarantee the authenticity of these messages.
We will discuss and compare this approach with the usage of the properties of stateful encryption (see
subsubsection 8.2.1).

8.1.2 WhatsApp

Additive Closeness. In order to ensure that only administrators of a group can manipulate the member
set, the authenticity of group manipulation messages needs to be protected. This can be achieved, for
example, by signing these messages with the administrator’s group signature key.
In order to maintain the member set at the server with regard to a malicious server, a counter for the
current modification step could be attached to every message and the signed manipulation notification could
include the whole member set instead of its changes only. Thereby, the current signed notification could be
distributed when a member loses their information of the group (e.g., due to a re-installation).
Traceable Delivery. The same countermeasure that is described for Signal applies to WhatsApp for
providing Traceable Delivery.

8.1.3 Threema

No Duplication. Since there is already a message ID appended to every message, this ID only needs
to be cryptographically bound to the message. This would prevent that one message is accepted by the
client multiple times. We proposed this fix to the developers of Threema. They appreciated our effort and
implemented a fix in Version 3.1414 .

8.2 General Outcomes

8.2.1 Reaching Traceable Delivery in General
The results of our analysis may imply that Traceable Delivery in instant messaging protocols is seldom
reached. Without going into detail, we also analyzed the respective direct messaging protocols regarding
Traceable Delivery. Signal and WhatsApp do not reach Traceable Delivery, but the direct messaging in
Threema reaches it by end-to-end encrypting the receipt acknowledgment to the sender and thereby crypto-
graphically ensuring the authenticity of these acknowledgments.
Using the approach of negative acknowledgments (NACKs) turns the responsibility of the Traceable
Delivery from the sender to the receiver [2, 25, 28, 36]. The receiver can therefore use the Signal key
exchange protocol since it is stateful. It provides a consecutive key stream such that Traceable Delivery can
be reached by detecting an omitted key of this stream. As part of this, the receiver can refer to the last
in-order delivered message within her normal content messages such that the initial sender can mark them
as delivered (which also reduces communication complexity). Once a key is omitted, the receiver knows that
a message was not delivered such that she can request the sender to resend this message.
13 Signing the message would be sufficient but the encryption is already part of the protocol and additionally protects the

confidentiality of the receipt messages.

14 https://threema.ch/en/versionhistory

22
8.2.2 Securely Managing a Group
In order to reach Additive Closeness and No Creation in groups, members of a group need to distinguish
between group members and external users.
We see two natural approaches of a secure group management:

(1) A consistent view on the member set for each of its members.
(2) A group secret that serves as a proof of membership.
Abstractly this means that either the receiver always checks her guest list or a sender always provides a
ticket. While Signal only implements the second mechanism, Threema mainly uses the first one. WhatsApp
somehow follows the guest list approach while the guest list is manipulable from outside.
Consistent View. For the effective group management, group information needs to be maintained locally
on every member’s device. Each user knows, who is part of the group, that means, who is allowed to
write a group message and from whom group messages should be accepted. In order to ensure a consistent
view on the member set, Traceable Delivery must be achieved because otherwise the server provider can
undetectably drop messages that aim to manipulate the member set and thereby cause an inconsistent view.
Even if the group information is centrally stored, it needs to be ensured, that (1) only members can modify
this information and (2) all members are informed about a modification.
Schiper and Toueg showed that the problem of membership in groups can be reduced to the more general
problem of maintaining a set of arbitrary elements and thereby decouple the group from the protocol [51].
Similarly we argue that a protocol, reaching consistency of all messages (content and group management),
can be treated as a protocol considering static groups. Nevertheless the consistent message delivery in groups
restricts the instant communication for messaging protocols.
Membership Proof. When solely using a group secret that protects Additive Closeness and No Creation
of the group, this secret needs to be calculated future secure, when the whole protocol reaches this property.
Otherwise, a revealed group secret can be used to become part of the group without the members’ permission.
The underlying problem is related to future secure group key exchange. A first group key exchange with
this property was recently proposed by Cohn-Gordon et al. [21].

8.2.3 Preserving Order

While FIFO Order can easily be established by enforcing the properties of stateful encryption, it inevitably
restricts the instant delivery of messages because if a later message is received earlier, it needs to be cached
until the all previous messages were delivered. According to our (weaker) definition, messages can be delivered
instantly, but then older messages, that were not received in the correct order, would need to be dropped. As
Marson and Poettering [40] provide a causal broadcast algorithm employing authenticated encryption with
associated data and vector clocks, Causal Order can also be achieved with standard cryptographic primitives
under the same tradeoff between reliability and instant delivery.
The analyzed applications already employ visual features to provide information on the order of mes-
sages in the user interface. However, as our descriptions of the shortcomings reveal, these features are not
appropriately protected towards the Malicious Server. Since the order of messages – especially the causal
context – is very important for the sense of their content, and instant delivery of messages is the inevitable
characteristic of instant messaging, it is up to the developers how far reliability is reached with respect to
order preservation.

9 Related Work
Related work to this paper is structured in (1) analyses of IM applications in general, specific analyses of
the analyzed protocols, as well as (2) theoretical concepts in multi user settings.

23
Analyses of IM Applications. Schrittwieser et al. [52] analyze IM applications regarding the initial
authentication and the account management and describe weaknesses accordingly. Unger et al. [62] system-
atize current secure instant messengers by proposing an evaluation security framework. Regarding group
communications, they conduct only a high level investigation on basic concepts and features of the protocols.
Analyses of Signal. The analysis of Signal started with Frosch et al. [29]. They analyze TextSecure v2,
the predecessor of the Signal key exchange protocol. As a result, they identify an Unknown Key-Share
(UKS) attack and propose fixes. Kobeissi et al. [34] describe the application of formal verification software
for analyzing a slightly modified version of the Signal protocol and other real world protocols. They derive
a proof from an automatic cryptographic verification tool but also model the UKS of Frosch et al. and
present attacks on the protocol that go beyond the model for the proof. Cohn-Gordon et al. [20] conduct a
formal analysis on the Signal key exchange protocol. Therefore, they develop a new multi-stage key exchange
security model, identify security properties in the Signal protocol, and prove it to be secure. Previous to
their analysis, they published a work on definitions and constructions for Future Secrecy [22]. Bellare et al.
[9] investigate ratcheting as a cryptographic primitive. Their work does not specifically focuses on a real
world protocol, but forms the basis of a definition and application for this primitive.
All these works concentrate on two party communications instead of multi-user setups. For this reason,
the security goals identified in this work differ significantly.
Analyses of WhatsApp. Schrittwieser et al. [52] analyzed WhatsApp among other IM applications
regarding the authentication and account management and found several vulnerabilities. Another application
specific analysis [5] focused on WhatsApp’s Android application. A recent newspaper article described that,
even though key verification is implemented in WhatsApp, its effectiveness can partially be circumvented
for usability reasons [37, 45]. In addition to these analyses, the WhatsApp protocol was implemented and
published as open source projects [30, 42].
Analyses of Threema. An initial analysis of the Threema protocol was conducted by Ahrens [3]. Based
on this Berger [10] implemented an open source desktop client on which we based our protocol analysis.
Independent of our work Schilling and Steinmetz presented a detailed description of the Threema message
format and another open source implementation [50].
Security in Multi User Settings.
Cohn-Gordon et al. [21] recently published a group key exchange protocol that enables the future secure
ratcheting of a group secret. This protocol is a hybrid of multiple two-party protocols for the instantiation
and a refreshable group key agreement. They also provide a proof for parts of their construction.
Bracha and Toueg introduced the notion of reliable broadcast in the asynchronous setting [14]. Since then
many works introduced and improved algorithms to solve the problem of validly and consistently delivering
messages in a multi user setting [16, 17, 18, 35] but also refined the notion and definition to provide realistic
attacker models [16].
Chockler et al. [19] give an overview on various models and results regarding group communication
systems (GCS) like [43, 63] and others. They systematize different notions and definitions regarding the
reliability and security of group communication in the literature.
Marson and Poettering [40] recently defined a security model that captures confidentiality and integrity
in a multi user setting, and provided provably secure constructions. Their work, however, does not cover
dynamic groups. Furthermore, as discussed in section 8, their model requires stronger notions of reliability
at costs of the instant message delivery.

10 Conclusion
Nowadays, Instant Messaging (IM) applications rely more and more on end-to-end protection. Although
the one-to-one communication of secure instant messaging applications has been in the focus of recent
analyses [20, 29, 34], the investigation of end-to-end protected group communications has gained only little
attention.

24
 We fill this gap by providing a security model and a methodology for analyzing group instant messaging
protocols. We demonstrate their applicability by conducting a systematical analysis of three major secure
group instant messengers: Signal, WhatsApp, and Threema.
While our investigation focuses on three major instant messaging applications, our methodology and the
underlying model is of generic purpose and can be applied to other secure group instant messaging protocols
as well. For example, it would be interesting to analyze the group chat implementations of other Signal-
based messaging protocols, such as Google’s Allo, Wire, and Facebook Messenger, or even non Signal-based
protocols similarly to our investigation of Threema.
For one-to-one communication the Signal key exchange protocol is practically used and cryptographically
proven secure. In contrast to this, for group communication no such protocol exists. A cryptographically
future secure group key exchange was recently published [21]. Still on the one hand, this protocol was
designed for a partially asynchronous setting and on the other hand, our work shows that the key exchange
is only a building block for a secure and reliable group messaging protocol. In fact, we demonstrate that
Future Secrecy should not only be restricted to the establishment of a common secret for encryption.
Consequently our work can be seen as a structural survey, a base point and an illustration of a target for
the design of secure and reliable group instant messaging protocols.
Acknowledgments. We thank Tibor Jager, Julian Loss, and the CCS 2017 reviewers for their helpful
comments and fruitful discussions.

References
[1] 2017. Communications Market Report. (2017). https://www.ofcom.org.uk/__data/assets/pdf_
file/0017/105074/cmr-2017-uk.pdf
[2] B. Adamson, C. Bormann, M. Handley, and J. Macker. 2008. Multicast Negative-Acknowledgment
(NACK) Building Blocks. RFC 5401. IETF. 1–42 pages. https://tools.ietf.org/html/rfc5401
[3] Jan Ahrens. 2014. Threema protocol analysis. (2014). http://blog.jan-ahrens.eu/files/threema-
protocol-analysis.pdf
[4] Martin R. Albrecht and Kenneth G. Paterson. 2016. Lucky Microseconds: A Timing Attack on Amazon’s
s2n Implementation of TLS. In Advances in Cryptology - EUROCRYPT 2016 - 35th Annual Interna-
tional Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May
8-12, 2016, Proceedings, Part I (Lecture Notes in Computer Science), Marc Fischlin and Jean-Sébastien
Coron (Eds.), Vol. 9665. Springer, 622–643. https://doi.org/10.1007/978-3-662-49890-3_24
[5] Cosimo Anglano. 2014. Forensic analysis of WhatsApp Messenger on Android smartphones. Digital
Investigation 11, 3 (2014), 201–213. https://doi.org/10.1016/j.diin.2014.04.003
[6] Nimrod Aviram, Sebastian Schinzel, Juraj Somorovsky, Nadia Heninger, Maik Dankel, Jens Steube,
Luke Valenta, David Adrian, J. Alex Halderman, Viktor Dukhovni, Emilia Käsper, Shaanan Cohney,
Susanne Engels, Christof Paar, and Yuval Shavitt. 2016. DROWN: Breaking TLS Using SSLv2. In 25th
USENIX Security Symposium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016., Thorsten
Holz and Stefan Savage (Eds.). USENIX Association, 689–706. https://www.usenix.org/conference/
usenixsecurity16/technical-sessions/presentation/aviram
[7] Mihir Bellare, Ran Canetti, and Hugo Krawczyk. 1996. Keying Hash Functions for Message Authenti-
cation. In Advances in Cryptology - CRYPTO ’96, 16th Annual International Cryptology Conference,
Santa Barbara, California, USA, August 18-22, 1996, Proceedings. 1–15. https://doi.org/10.1007/
3-540-68697-5_1
[8] Mihir Bellare, Anand Desai, E. Jokipii, and Phillip Rogaway. 1997. A Concrete Security Treatment of
Symmetric Encryption. In 38th Annual Symposium on Foundations of Computer Science, FOCS ’97,

25
 Miami Beach, Florida, USA, October 19-22, 1997. 394–403. https://doi.org/10.1109/SFCS.1997.
646128
[9] Mihir Bellare, Asha Camper Singh, Joseph Jaeger, Maya Nyayapati, and Igors Stepanovs. 2016. Ratch-
eted Encryption and Key Exchange: The Security of Messaging. IACR Cryptology ePrint Archive 2016
(2016), 1028. http://eprint.iacr.org/2016/1028
[10] Philipp Berger. 2016. Open Source Implementation of a Threema Desktop Client. (2016). https:
//github.com/blizzard4591/openMittsu Based on the descriptions of Jan Ahrens’ paper.
[11] Daniel J. Bernstein. 2005. The Poly1305-AES Message-Authentication Code. In Fast Software Encryp-
tion: 12th International Workshop, FSE 2005, Paris, France, February 21-23, 2005, Revised Selected
Papers. 32–49. https://doi.org/10.1007/11502760_3
[12] Daniel J. Bernstein. 2006. Curve25519: New Diffie-Hellman Speed Records. In Public Key Cryptography
- PKC 2006, 9th International Conference on Theory and Practice of Public-Key Cryptography, New
York, NY, USA, April 24-26, 2006, Proceedings. 207–228. https://doi.org/10.1007/11745853_14
[13] Daniel J. Bernstein. 2008. The Salsa20 Family of Stream Ciphers. In New Stream Cipher Designs - The
eSTREAM Finalists, Matthew J. B. Robshaw and Olivier Billet (Eds.). Lecture Notes in Computer
Science, Vol. 4986. Springer, 84–97. https://doi.org/10.1007/978-3-540-68351-3_8
[14] Gabriel Bracha and Sam Toueg. 1985. Asynchronous Consensus and Broadcast Protocols. J. ACM 32,
4 (1985), 824–840. https://doi.org/10.1145/4221.214134
[15] Business2Community. 2015. Are Instant Messaging Apps the Future of the (Mobile) Inter-
net? (Aug. 2015). http://www.business2community.com/mobile-apps/instant-messaging-apps-
future-mobile-internet-01313577
[16] Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup. 2001. Secure and Efficient Asyn-
chronous Broadcast Protocols. In Advances in Cryptology - CRYPTO 2001, 21st Annual International
Cryptology Conference, Santa Barbara, California, USA, August 19-23, 2001, Proceedings. 524–541.
https://doi.org/10.1007/3-540-44647-8_31
[17] Christian Cachin, Klaus Kursawe, and Victor Shoup. 2005. Random Oracles in Constantinople: Prac-
tical Asynchronous Byzantine Agreement Using Cryptography. J. Cryptology 18, 3 (2005), 219–246.
https://doi.org/10.1007/s00145-005-0318-0
[18] Ran Canetti and Tal Rabin. 1993. Fast asynchronous Byzantine agreement with optimal resilience. In
Proceedings of the Twenty-Fifth Annual ACM Symposium on Theory of Computing, May 16-18, 1993,
San Diego, CA, USA. 42–51. https://doi.org/10.1145/167088.167105
[19] Gregory V. Chockler, Idit Keidar, and Roman Vitenberg. 2001. Group communication specifications: a
comprehensive study. ACM Comput. Surv. 33, 4 (2001), 427–469. https://doi.org/10.1145/503112.
503113
[20] Katriel Cohn-Gordon, Cas Cremers, Benjamin Dowling, Luke Garratt, and Douglas Stebila. 2017. A
formal security analysis of the Signal messaging protocol. In Proc. IEEE European Symposium on
Security and Privacy (EuroS&P) 2017. IEEE. To appear.
[21] Katriel Cohn-Gordon, Cas Cremers, Luke Garratt, Jon Millican, and Kevin Milner. 2017. On Ends-to-
Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees. IACR Cryptology
ePrint Archive 2017 (2017), 666. http://eprint.iacr.org/2017/666
[22] Katriel Cohn-Gordon, Cas J. F. Cremers, and Luke Garratt. 2016. On Post-compromise Security. In
IEEE 29th Computer Security Foundations Symposium, CSF 2016, Lisbon, Portugal, June 27 - July 1,
2016. 164–178. https://doi.org/10.1109/CSF.2016.19

26
[23] Joan Daemen and Vincent Rijmen. 1998. The Block Cipher Rijndael. In Smart Card Research and
Applications, This International Conference, CARDIS ’98, Louvain-la-Neuve, Belgium, September 14-
16, 1998, Proceedings. 277–284. https://doi.org/10.1007/10721064_26
[24] Sergej Dechand, Dominik Schürmann, Karoline Busse, Yasemin Acar, Sascha Fahl, and Matthew Smith.
2016. An Empirical Study of Textual Key-Fingerprint Representations. In 25th USENIX Security Sym-
posium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016., Thorsten Holz and Stefan Savage
(Eds.). USENIX Association, 193–208. https://www.usenix.org/conference/usenixsecurity16/
technical-sessions/presentation/dechand
[25] Christophe Diot, Walid Dabbous, and Jon Crowcroft. 1997. Multipoint Communication: A Survey
of Protocols, Functions, and Mechanisms. IEEE Journal on Selected Areas in Communications 15, 3
(1997), 277–290. https://doi.org/10.1109/49.564128
[26] Sisi Duan, Lucas Nicely, and Haibin Zhang. 2016. Byzantine reliable broadcast in sparse networks. In
15th IEEE International Symposium on Network Computing and Applications, NCA 2016, Cambridge,
Boston, MA, USA, October 31 - November 2, 2016. 175–182. https://doi.org/10.1109/NCA.2016.
7778614

[27] eMarketer. 2015. Mobile Messaging to Reach 1.4 Billion Worldwide in 2015. (Nov. 2015). https:
//www.emarketer.com/Article/Mobile-Messaging-Reach-14-Billion-Worldwide-2015/1013215
[28] Sally Floyd, Van Jacobson, Ching-Gung Liu, Steven McCanne, and Lixia Zhang. 1997. A reliable
multicast framework for light-weight sessions and application level framing. IEEE/ACM Trans. Netw.
5, 6 (1997), 784–803. https://doi.org/10.1109/90.650139

[29] Tilman Frosch, Christian Mainka, Christoph Bader, Florian Bergsma, Jörg Schwenk, and Thorsten Holz.
2016. How Secure is TextSecure?. In IEEE European Symposium on Security and Privacy, EuroS&P
2016, Saarbrücken, Germany, March 21-24, 2016. 457–472. https://doi.org/10.1109/EuroSP.2016.
41

[30] Tarek Galal. 2016. Open Source Implementation of a WhatsApp Client. (2016). https://github.com/
tgalal/yowsup This code is not maintained anymore but some of its forks are still under development.
[31] Christina Garman, Matthew Green, Gabriel Kaptchuk, Ian Miers, and Michael Rushanan. 2016. Dancing
on the Lip of the Volcano: Chosen Ciphertext Attacks on Apple iMessage. In 25th USENIX Security
Symposium, USENIX Security 16, Austin, TX, USA, August 10-12, 2016. 655–672. https://www.
usenix.org/conference/usenixsecurity16/technical-sessions/presentation/garman
[32] Vassos Hadzilacos and Sam Toueg. 1993. Distributed Systems (2Nd Ed.). ACM Press/Addison-Wesley
Publishing Co., New York, NY, USA, Chapter Fault-tolerant Broadcasts and Related Problems, 97–145.
http://dl.acm.org/citation.cfm?id=302430.302435
[33] WhatsApp Inc. 2016. WhatsApp Encryption Overview. (2016). https://www.whatsapp.com/
security/WhatsApp-Security-Whitepaper.pdf Technical white paper.
[34] Nadim Kobeissi, Karthikeyan Bhargavan, and Bruno Blanchet. 2017. Automated Verification for Secure
Messaging Protocols and their Implementations: A Symbolic and Computational Approach. In IEEE
European Symposium on Security and Privacy (EuroS&P). Available at http://prosecco. gforge. inria.
fr/personal/bblanche/publications/KobeissiBhargavanBlanchetEuroSP17. pdf. To appear.

[35] Klaus Kursawe and Victor Shoup. 2005. Optimistic Asynchronous Atomic Broadcast. In Automata,
Languages and Programming, 32nd International Colloquium, ICALP 2005, Lisbon, Portugal, July 11-
15, 2005, Proceedings. 204–215. https://doi.org/10.1007/11523468_17

27
[36] Brian Neil Levine and J. J. Garcia-Luna-Aceves. 1998. A Comparison of Reliable Multicast Protocols.
Multimedia Syst. 6, 5 (1998), 334–348. http://link.springer.de/link/service/journals/00530/
bibs/8006005/80060334.htm
[37] Tobias Boelter Manisha Ganguly. 2017. WhatsApp vulnerability allows snooping on encrypted mes-
sages. The Guardian (2017). https://www.theguardian.com/technology/2017/jan/13/whatsapp-
backdoor-allows-snooping-on-encrypted-messages
[38] Moxie Marlinspike and Trevor Perrin. 2016. The Double Ratchet Algorithm. (11 2016). https:
//whispersystems.org/docs/specifications/doubleratchet/doubleratchet.pdf
[39] Moxie Marlinspike and Trevor Perrin. 2016. The X3DH Key Agreement Protocol. (11 2016). https:
//whispersystems.org/docs/specifications/x3dh/x3dh.pdf
[40] Giorgia Azzurra Marson and Bertram Poettering. 2017. With one it is easy, with many it gets com-
plicated: Understanding Channel Security for Groups. Cryptology ePrint Archive, Report 2017/786.
(2017). https://eprint.iacr.org/2017/786.
[41] Christopher Meyer, Juraj Somorovsky, Eugen Weiss, Jörg Schwenk, Sebastian Schinzel, and Erik Tews.
2014. Revisiting SSL/TLS Implementations: New Bleichenbacher Side Channels and Attacks. In 23rd
USENIX Security Symposium. 733–748. https://www.usenix.org/conference/usenixsecurity14/
technical-sessions/presentation/meyer
[42] mgp25. 2016. Open Source Implementation of a WhatsApp PHP API. (2016). https://github.com/
mgp25/Chat-API

[43] Louise E. Moser, P. M. Melliar-Smith, Deborah A. Agarwal, Ravi K. Budhia, and Colleen A. Lingley-
Papadopoulos. 1996. Totem: A Fault-Tolerant Multicast Group Communication System. Commun.
ACM 39, 4 (1996), 54–63. https://doi.org/10.1145/227210.227226
[44] Moxie Marlinspike. 2013. Advanced cryptographic ratcheting. (2013). https://whispersystems.org/
blog/advanced-ratcheting/
[45] Moxie Marlinspike. 2017. There is no WhatsApp ’backdoor’. (2017). https://whispersystems.org/
blog/there-is-no-whatsapp-backdoor/
[46] Open Whisper Systems. 2017. Facebook Messenger deploys Signal Protocol for end to end encryption.
(2017). https://whispersystems.org/blog/facebook-messenger/

[47] Open Whisper Systems. 2017. Open Whisper Systems partners with Google on end-to-end encryption
for Allo. (2017). https://whispersystems.org/blog/allo/
[48] Open Whisper Systems. 2017. Signal Website. (2017). https://signal.org/
[49] Trevor Perrin. 2016. The Noise Protocol Framework. (2016). http://noiseprotocol.org/noise.pdf

[50] Roland Schilling and Frieder Steinmetz. 2016. A look into the Mobile Messaging Black Box. (12 2016).
https://media.ccc.de/v/33c3-8062-a_look_into_the_mobile_messaging_black_box Talk at the
33c3 in Hamburg, Germany. Implementation: https://github.com/o3ma.
[51] André Schiper and Sam Toueg. 2006. From Set Membership to Group Membership: A Separation of
Concerns. IEEE Trans. Dependable Sec. Comput. 3, 1 (2006), 2–12. https://doi.org/10.1109/TDSC.
2006.13

28
[52] Sebastian Schrittwieser, Peter Frühwirt, Peter Kieseberg, Manuel Leithner, Martin Mulazzani, Markus
Huber, and Edgar R. Weippl. 2012. Guess Who’s Texting You? Evaluating the Security of Smartphone
Messaging Applications. In 19th Annual Network and Distributed System Security Symposium, NDSS
2012, San Diego, California, USA, February 5-8, 2012. http://www.internetsociety.org/guess-
whos-texting-you-evaluating-security-smartphone-messaging-applications
[53] Signal. 2017. Signal Private Messenger in Google Play. (2017). https://play.google.com/store/
apps/details?id=org.thoughtcrime.securesms
[54] Statista. 2017. Most popular messaging apps. (2017). https://www.statista.com/statistics/
258749/most-popular-global-mobile-messenger-apps/
[55] Open Whisper Systems. 2016. Message Format in the Signal Protocol. (11 2016). https://github.com/
WhisperSystems/libsignal-service-java/blob/4cedb5c31c11c1e8811b3bb7cd68d56ff7e0c03f/
protobuf/SignalService.proto Specified with Google Protocol Buffers.
[56] Open Whisper Systems. 2016. Source Code of Signal-Android. (11 2016). https://github.com/
WhisperSystems/Signal-Android/commit/ce812ed8ba49fc43db9de018c135be67b5b44f7d Android
Application Version 3.23.0.
[57] Open Whisper Systems. 2016. Source Code of Signal-Service Library. (11 2016). https://github.com/
WhisperSystems/libsignal-service-java/commit/460cd7559caa74bb6539c72865c71de660a69bac
Java Library Version 2.4.1.
[58] Open Whisper Systems. 2017. Signal Github Repository. (05 2017). https://github.com/
WhisperSystems/
[59] Threema. 2017. Threema in Google Play. (2017). https://play.google.com/store/apps/details?
id=ch.threema.app
[60] Threema. 2017. Threema Website. (2017). https://threema.ch/en
[61] Threema GmbH. 2016. Threema Cryptography Whitepaper. (2016). https://threema.ch/press-
files/2_documentation/cryptography_whitepaper.pdf
[62] Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fahl, Henning Perl, Ian Goldberg, and Matthew
Smith. 2015. SoK: Secure Messaging. In 2015 IEEE Symposium on Security and Privacy, SP 2015, San
Jose, CA, USA, May 17-21, 2015. 232–249. https://doi.org/10.1109/SP.2015.22
[63] Robbert van Renesse, Kenneth P. Birman, and Silvano Maffeis. 1996. Horus: A Flexible Group Com-
munication System. Commun. ACM 39, 4 (1996), 76–83. https://doi.org/10.1145/227210.227229
[64] WhatsApp. 2016. Why am I banned for using WhatsApp Plus and how do I get unbanned? (2016).
https://www.whatsapp.com/faq/en/general/105
[65] WhatsApp. 2017. WhatsApp Security. (2017). https://www.whatsapp.com/security/

A Signal Key Exchange Protocol and its Usage

Figure 9 describes the exact usage of keys for group communication in Signal and WhatsApp. The DR
algorithm is initialized by the root key (RK ) and is updated by Diffie Hellman key exchanges between the
sender and the receiver (DH ratcheting). The output of these updates is the input of the symmetric ratcheting
which only consists of a key derivation function. Half of the output is used for the consecutive ratcheting
(chain keys CK ) and the other half is used as encryption keys (message keys MK ). While Signal uses these
keys directly for all communication, WhatsApp generates a separate key stream for group communication.
This additional key stream is update symmetrically only.

29
Figure 9: Sender key stream from A to B and ciphertexts from A to the server when sending one direct
message to B and two group messages to a group G of which A and B are members in Signal and WhatsApp.

30