Aarhus University

Computer Science
Master's thesis

A practical cryptanalysis of the

Telegram messaging protocol

Author: Supervisor:
Jakob Bjerre Jakobsen Claudio Orlandi
(20102095)

September 2015

AU AARHUS
UNIVERSITY
DEPARTMENT OF COMPUTER SCIENCE
 Abstract
The number one rule for cryptography is never create your own crypto. In-
stant messaging application Telegram has disregarded this rule and decided
to create an original message encryption protocol. In this work we have done
a thorough cryptanalysis of the encryption protocol and its implementation.
We look at the underlying cryptographic primitives and how they are com-
bined to construct the protocol, and what vulnerabilities this has. We have
found that Telegram does not check integrity of the padding applied prior to
encryption, which lead us to come up with two novel attacks on Telegram.
The rst of these exploits the unchecked length of the padding, and the sec-
ond exploits the unchecked padding contents. Both of these attacks break
the basic notions of IND-CCA and INT-CTXT security, and are conrmed to
work in practice. Lastly, a brief analysis of the similar application TextSecure
is done, showing that by using well known primitives and a proper construc-
tion provable security is obtained. We conclude that Telegram should have
opted for a more standard approach.

ii
 Acknowledgements
First of all I would like to thank my former oce partner Morten Djerns
Bech who had the energy to have helpful discussions with me about my thesis,
even though the deadline for his own thesis was much closer than mine. I
would like to thank Frederik Bitsch Kirk for proofreading and spell checking
my entire work, truly his English skill surpasses mine. And nally I would
like give great thanks to my supervisor Claudio Orlandi for helping me realize
my idea for this project, and for his guidance and lengthy discussions with
me that led to interesting discoveries.

iii
Contents

1 Introduction 5
1.1 Chapter overview . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Preliminaries 9
2.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Symmetric-key cryptosystems . . . . . . . . . . . . . . . . . . 9
2.3 Security denitions . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Protocols 32
3.1 Device registration . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Key exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Message encryption . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Key Derivation Function . . . . . . . . . . . . . . . . . . . . . 43

4 Result of analysis 47
4.1 Random padding vulnerability . . . . . . . . . . . . . . . . . . 47
4.2 Replay and mirroring attacks in older versions . . . . . . . . . 51
4.3 Timing attacks on MTProto . . . . . . . . . . . . . . . . . . . 51

5 Experimental validation 53
5.1 Attack #1: padding length extension . . . . . . . . . . . . . . 53
5.2 Attack #2: padding plaintext collision . . . . . . . . . . . . . 55
5.3 Malicious server attacks . . . . . . . . . . . . . . . . . . . . . 57

6 Known attacks 59
6.1 Known attacks on primitives . . . . . . . . . . . . . . . . . . . 59
6.2 Known attacks on MTProto . . . . . . . . . . . . . . . . . . . 65

7 Proven crypto alternative 69

7.1 TextSecure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

iv
Chapter 1
Introduction

Telegram is an instant messaging service designed for mobile devices, that as

of May 2015 had 62 million monthly active users [23] and is used to deliver
1
ten milliard messages daily [29]. It oers two conversation modes, the rst
being the regular chat mode in which all messages can be read by the server
and will be stored, allowing for synchronization between devices and group
chats. The second mode, called secret chat, is an end-to-end encrypted chat
for only two parties. Messages are sent through the server, but cannot be
read by it and are claimed to not be stored at any time.
Instead of using proven cryptographic constructs, Telegram opted to create
its own original protocol known as MTProto. This is built on weaker primi-
tives, but in such a way that known attacks do not apply.
The ocial Telegram client application is open source, allowing for full au-
diting, but the server software is not. According to the Electronic Frontier
Foundation [9], Telegram was audited in February 2015 and the secret chat
mode achieved full marks for its security. This work will go in-depth with
the secret chat mode, analyzing potential weaknesses and propose attacks to
exploit these as well as proposing improvements.

Goals The goal of this work is to give a thorough analysis of the security
of the Telegram instant messaging application and its message encryption
protocol MTProto. We will look at the cryptographic primitives used, and
how the message encryption protocol is constructed from these. We will see
which notions of security this protocol provides, and which it does not. With
this knowledge we will propose attacks on the Telegram messaging protocol,
exploiting the found weaknesses. Finally, we will propose improvements to
the protocol that solve found issues and mitigate proposed attacks.

1 Or ten US billion.

5
 1.1. CHAPTER OVERVIEW

1.1 Chapter overview

1.1.1 Chapter 2: Preliminaries
In the preliminaries chapter we will give an overview of the cryptographic
primitives that Telegram is built upon. First we will introduce symmetric en-
cryption cryptosystems and more specically Advanced Encryption Standard
and Innite Garble Extension, the mode of operation employed by Telegram.
We will dene relevant security notions starting from Indistinguishability of
encryptions under Chosen-Plaintext Attack and leading up to Authenticated
Encryption. On the way we will cover Integrity of Plaintexts and Cipher-
texts, unforgeable Message Authentication Codes, and we will also dene
Blockwise-Adaptive Indistinguishability of encryptions.
We will also give an overview of hash functions and dene collision resis-
tance, and relate this to pre-image and 2nd pre-image resistance as well as
identical-prex collision resistance. Finally, we will briey introduce Secure
Hash Algorithm SHA1, and explain what it means for a hash function to be
cryptographically broken.

1.1.2 Chapter 3: Protocols

In the protocols chapter we will walk through the ow of the Telegram appli-
cation. We will rst cover how a new user registers a device to the Telegram
server, and how the two exchange an authorization key. Next we will explain
how two users exchange keys and initiate an end-to-end encrypted secret
chat. We will then explain how symmetric encryption keys are derived, and
how clients encrypt and decrypt messages using Telegram's own MTProto
scheme. Furthermore, we will cover how the message counter in Telegram
is constructed, and how Forward Secrecy is provided. Finally, we will see
how MTProto provides backwards compatibility in order for older clients to
remain compatible with clients on newer versions.
Throughout this chapter we will also outline some inconsistencies between
how Telegram explains their encryption scheme on their website and how it
is actually implemented, which will lead to some interesting exploits in the
next chapter.

1.1.3 Chapter 4: Results of analysis

In the results chapter we will outline vulnerabilities in MTProto, and con-
struct attacks that exploit these in order to break security properties of MT-
Proto. We will show how the padding scheme employed leads to two attacks

6
 1.1. CHAPTER OVERVIEW

that break both Integrity of Ciphertexts and Indistinguishability of encryp-

tions under Chosen-Ciphertext Attack. The rst attack exploits the fact
that padding length is never checked, the second exploiting the fact that the
padding has no integrity.
We will also describe how a malicious server could take advantage of older,
still supported versions of MTProto to freely inject messages into end-to-end
encrypted conversations.
Finally, we will look at how MTProto could be vulnerable to timing attacks
because of how message content is checked upon decryption, but such an
attack has not been implemented for validation.

1.1.4 Chapter 5: Experimental validation

In the experimental validation chapter we will implement and verify the ef-
fectiveness of the attacks as described in the results chapter. We will briey
explain the test setup, and for each attack we will show how it is imple-
mented, how the test was run, and what the outcome was.
We conrm that the padding extension attack has probability 1 of succeed-
ing in breaking IND-CCA security, whereas the padding plaintext collision
32
attack succeeds with non-negligible probability 2 .
We also conrm that by using an older version of MTProto that relies on
trusting the server for message counters of end-to-end encrypted chats, a
malicious server can freely inject messages.
Finally, for each of the attacks we will show how to patch the vulnerability
and mitigate the attack, and see how these patches will aect client compat-
ibility.

1.1.5 Chapter 6: Known attacks

In the known attacks chapter we will cover attacks that are known to aect
the cryptographic primitives of MTProto, and see if these also apply to MT-
Proto itself. Specically we look at blockwise-adaptive IND-CPA for Innite
Garble Extension and the cost of nding collisions for SHA1, and how this
aects the security of MTProto.
We will also describe attacks constructed specically for MTProto, including
a former malicious server attack that would let the server learn two users'
shared secret, even though this has been patched out. The other two attacks
are third party man-in-the-middle attacks, both of which will grant the at-
tacker full access to all messages. We will see if these attacks are feasible to
carry out.

7
 1.1. CHAPTER OVERVIEW

1.1.6 Chapter 7: Proven crypto alternative

In the proven crypto alternative chapter we will look at another instant mes-
saging application that does have proven Authenticated Encryption. Specif-
ically we will look at how TextSecure operates, which primitives it uses and
how these are combined to guarantee condentiality, integrity and authentic-
ity. We will relate this to Telegram and see what Telegram can take from this
standard approach and use to improve upon its own homegrown approach.

1.1.7 Contributions
The contributions of this work are two novel vulnerabilities that we found in
the protocol MTProto, proving it insecure under basic notions.

These ndings were communicated to the Telegram team on the 3rd of

September 2015, and we have yet to get a response.

8
Chapter 2
Preliminaries

2.1 Notation
Throughout this work we will use consistent notation. We write for assign-
ment. '=' is used for conditional checks. Variable names are written in italic.

Encryption under key K is written as EncK and similarly decryption is DecK .

We will refer to full plaintext messages with an uppercase M, or Mb for

a bit b {0, 1} in cases where one of two messages is chosen. Similarly, a
full ciphertext is referred to as C . |M | refers to the length of message M.

For individual blocks of a message, mbi is the i'th block of message Mb ,

and ci is the ciphertext of the i'th block.

The string concatenation operator is denoted as ||, and XOR is .

2.2 Symmetric-key cryptosystems

Symmetric- or private-key cryptosystems are designed to provide conden-
tiality, keeping the contents of a data block secret. These are generally com-
putationally secure, meaning that given enough time and computing power
an adversary could recover the plaintext, but in practice this task is nearly
impossible to carry out. These systems are dened as follows, from Katz et
al. [13]:

9
 2.2. SYMMETRIC-KEY CRYPTOSYSTEMS

2.2.1 Def. private-key encryption scheme

A private-key encryption scheme is a tuple of probabilistic polynomial-time
algorithms (Gen, Enc, Dec) such that:

1. The key-generation algorithm Gen takes as input the security param-

n n
eter 1 and outputs a key k ; we write this as k Gen(1 ) (thus
emphasizing the fact that Gen is a randomized algorithm). We will
n
assume without loss of generality that any key k output by Gen(1 )
satises |k| n.
2. The encryption algorithm Enc takes as input a key k and a plaintext

message m {0, 1} and outputs a ciphertext c. Since Enc may be
randomized, we write this as c Enck (m).
3. The decryption algorithm Dec takes as input key k and a ciphertext c
and outputs a message m. We assume that Dec is deterministic, and
so write this as m Deck (c).
n
It is required that for every n, every k output by Gen(1 ), and every m
{0, 1} , it holds that Deck (Enck (m)) = m.

2.2.2 Advanced Encryption Standard (AES)

AES is the successor of the Data Encryption Standard (DES) from 1977
which was eventually too easy to break with a bruteforce attack because of
its 56-bit keys. It has been the standard since its adoption in 2001, and to
this date no computationally feasible key recovery attack has been published.

AES is a symmetric-key block cipher with block size 128 bit and keys ranging
from 128 to 256 bits. The internal components of AES are beyond the scope
of this work, and we will treat it as a black box for encryption.

2.2.3 Innite Garble Extension (IGE)

Innite Garble Extension is a mode of operation for block ciphers in symmetric-
key encryption. IGE blocks are chained as follows:

ci1 fK (mi ci1 ) mi1

fK being the block cipher encryption function using key K.

Typically, a mode of operation for block ciphers needs a block length ini-
tialization vector, which we will later see is the case for CBC and CTR

10
 2.2. SYMMETRIC-KEY CRYPTOSYSTEMS

mode. But as we see in Savard [18], IGE needs both an initial plaintext
block m0 and ciphertext block c0 . The original specication says the initial
ciphertext block is derived using a second random key K 0 : c0 = fK0 (m0 ),
but the OpenSSL implementation allows for it to be an arbitrary block given
as a parameter.

Figure 2.1: Diagram of IGE mode of operation for encryption.

Figure 2.2: Diagram of IGE mode of operation for decryption.

Writing out the operations for encrypting each block we get the following, as
visualized in gure 2.1:

c1 m0 EncK (m1 c0 )
c2 m1 EncK (m2 m0 EncK (m1 c0 ))
c3 m2 EncK (m3 m1 EncK (m2 m0 EncK (m1 c0 )))
ci mi1 EncK (mi mi2 EncK (mi1 . . . m0 EncK (m1 c0 ) . . . ))

11
 2.2. SYMMETRIC-KEY CRYPTOSYSTEMS

Writing out the operations for decrypting each block we get the following, as
visualized in gure 2.2:

m1 c0 DecK (c1 m0 )
m2 c1 DecK (c2 c0 DecK (c1 m0 ))
m3 c2 DecK (c3 c1 DecK (c2 c0 DecK (c1 m0 )))
mi ci1 DecK (ci ci2 DecK (ci1 . . . c0 DecK (c1 m0 ) . . . ))

An article on the implementation of IGE in OpenSSL [14] states that the

mode of operation IGE has the property that errors are propagated forward
indenitely.

Figure 2.3: Non-malleability of IGE causing every block after the modication to become
garbled.

Figure 2.3 shows that ipping one bit in one ciphertext block would cause
the decrypted block to garble as well as all the following blocks. It is also
possible to use bi-directional IGE, garbling the entire plaintext output. This
can be used to provide plaintext integrity, guaranteeing the contents of a
message has not been tampered with, by appending a block of all 0's at the
end and checking this upon decryption.

Cipher Block Chaining (CBC) and malleability A more common

mode of operation like IGE that does not have this garbling property, and
as shown in gure 2.4, ipping one bit in a ciphertext block will only cause
the corresponding plaintext block to garble as well as ipping the bit in the
same position of the following plaintext block. This makes CBC malleable,

12
 2.2. SYMMETRIC-KEY CRYPTOSYSTEMS

an often undesirable property as it can be exploited to break plaintext in-

tegrity.

Figure 2.4: Malleability of CBC mode allow modifying one plaintext output block, at
the cost of garbling the one before it.

This is bad if evil Eve knows Alice is sending Bob the message "Hi Bob,
please transfer $100 to Eve", Eve could capture the encrypted ciphertext
and modify the block before the one containing the value, so that the de-
crypted message becomes "[garbled] transfer $999 to Eve".

We have seen malleability exploited in the BEAST attack on SSL/TLS, as

described by Paterson [15]. Here we saw that the padding of length n bytes
consisted of n copies of the byte n1, and this padding structure was checked
before the message integrity was checked from the MAC. This little dier-
ence in timing and the malleability of CBC mode lead to a Padding Oracle
Attack, allowing an adversary to recover the full plaintext one byte at a time.

2.2.4 Counter mode (CTR)

The counter mode of operation is dierent from IGE and CBC that we saw
above in that it does not do any block chaining. What it does instead is
to extend the key into an arbitrarily long key stream and XOR this with
the plaintext. Generating this key stream is done by rst choosing a random
nonce of one block length. This nonce is encrypted under the encryption key,
which gives the rst block of the key stream. The stream is then XOR'd with
the plaintext, outputting one ciphertext block. For every following plaintext
block, the counter is incremented corresponding to the position of the block
in the plaintext message, and the same process is used.
The decryption scenario is identical except the plaintext is switched with

13
 2.3. SECURITY DEFINITIONS

Figure 2.5: Encryption using counter mode.

the ciphertext. It's easy to see that like CBC, CTR mode is malleable but
with no blocks being garbled in the process. The lack of block chaining also
makes counter mode trivially parallelizable, leading to higher performance
on multi-core systems.
Rather than adding padding to the plaintext, the key stream generated with
CTR mode can simply be truncated to match the plaintext length.

2.3 Security denitions

In this section we will dene the notions of security that a cryptosystem
should ideally provide, and hold it against MTProto in later chapters.

2.3.1 Introduction to oracles

To help explain the security denitions we will use oracle games. These are
hypothetical scenarios where a probabilistic polynomial-time adversary A is
challenged by an oracle O to output an answer that meets certain criteria.
Generally speaking, A must output a satisfying answer with non-negligible
probability for a security parameter n.

Left-Or-Right oracles In the case of LOR-oracles, O chooses a bit b at

random, and A has to be able to output if it is 1 or 0 with probability of
winning non-negligibly higher than that of guessing at random, based on
security parameter n.

14
 2.3. SECURITY DEFINITIONS

2.3.2 Denition: IND-CPA security

Indistinguishability of encryptions under chosen-plaintext attack is a basic
notion of security for cryptosystems. It describes the inability of distinguish-
ing encrypted plaintext, thereby providing condentiality, which in some
cases will be a sucient security notion. We use a LOR-oracle game for this
denition, and the idea is that A has to be able to distinguish which plain-
text of his choice that O has encrypted. From Katz et al. [13]:
For a symmetric key encryption system (Gen, Enc, Dec) with security
parameter n:
n
1. A key K is generated by running Gen(1 ).

2. The adversary A is given input 1n and oracle access to EncK (), and
outputs a pair of messages M0 , M1 of the same length l.

3. A random bit b {0, 1} is chosen, and then a ciphertext C

EncK (Mb ) is computed and given to A. We call C the challenge ci-
phertext.

4. The adversary A continues to have oracle access to EncK (), and out-
0
puts a bit b .

5. The output of the experiment is dened to be 1 if b 0 = b, and 0 other-

wise.

We say the symmetric encryption scheme has indistinguishable encryp-

tions under chosen-plaintext attack if for all probabilistic polynomial time
adversaries A there exists a negligible function negl() such that

1
P r[Experiment outputs 1] + negl(n)
2
eg. probability of winning is only negligibly better than guessing at random.

This denition assumes the cryptosystem is probabilistic, as it would be

trivial to win in a deterministic setting by sending M0 to the oracle a second
time and seeing if the returned Ci = C which implies b = 0, otherwise b = 1.

IND-CPA is a strong notion in that it makes no assumption about the plain-

text, unlike weaker notions such as Known-Plaintext Attack in which the
adversary does not get to choose the messages for the challenge ciphertexts,
but it can break under certain circumstances. Take for instance an adversary
that is given access to each individual ciphertext block as they are computed,

15
 2.3. SECURITY DEFINITIONS

A O
1n n
C K Gen(1 )

 Mi
B
Ci
C

M0 , M1
Ci EncK (Mi )

M0 , M1 {0, 1}l B b {0, 1}

C
C C EncK (Mb )

 Mi
B
Ci
C
Ci EncK (Mi )

b0
B if b = b0 then
Output 1
else
Output 0

Figure 2.6: LOR-oracle IND-CPA game.

16
 2.3. SECURITY DEFINITIONS

before inputting the next plaintext block. We will see that this can be bro-
ken even if the underlying cryptosystem has IND-CPA, which is why we will
dene blockwise-adaptive IND-CPA, or IND-BACPA.

2.3.3 Denition: general IND-BACPA

Indistinguishability of encryptions under blockwise-adaptive chosen-plaintext
attack. From Bard [4]:

The name blockwise-adaptive alludes to the capability of the attacker

to view the results of inserting one or more blocks of choice into a plaintext
message before deciding on the next block, thus permitting the attacker to
adapt the attack based upon those observations.

It may not be intuitive that this scenario can exist in practice, but it is
the case for some online services where the server will encrypt each block
as soon as it's uploaded, such as SSH. The denition is described by the
following LOR-oracle game:
For a symmetric key encryption system (Gen, Enc, Dec) with security
parameter n:
n
1. A key K is generated by running Gen(1 ). A random bit b {0, 1} is
chosen.

2. The adversary A is given input1n and oracle access to EncK (), and
sends a pair of message blocks m01 , m11 of xed length.

3. A ciphertext block c1 EncK (mb1 ) is computed and given to A.

4. After observing c1 , A now sends the next pair of plaintext blocks
m02 , m12 and receives c2 . After sending polynomially many block pairs,
A outputs a bit b0 .
5. The output of the experiment is dened to be 1 if b0 = b, and 0 other-
wise.

We say the symmetric encryption scheme has indistinguishable encryp-

tions under blockwise-adaptive chosen-plaintext attack if for all probabilistic
polynomial time adversaries A there exists a negligible function negl() such
that
1
P r[Experiment outputs 1] + negl(n)
2
This is the notion of general IND-BACPA security, but another variant of
it exists called primitive IND-BACPA. The only dierence here is that the

17
 2.3. SECURITY DEFINITIONS

A O
1n
C K Gen(1 )
n

b {0, 1}
m0i , m1i {0, 1}l

 m0i , m1i
B
ci
C ci EncK (mbi )

b0
B if b = b0 then
Output 1
else
Output 0

Figure 2.7: LOR-oracle IND-BACPA game.

adversary is only allowed to output plaintext blocks m0i 6= m1i once, and for
any other query it must hold that m0i = m1i . We will use this denition in
section 6.1.1 where we will show that IGE does not have indistinguishable
encryptions under the primitive BACPA notion.

This gives us a strong denition for encryption oracles, but we have not
considered that the adversary might also have access to a decryption oracle.

Take for example the encryption function EncK (M ) = FK (r) M where

|M | = n, r is a random nonce and FK is a pseudo-random function. An
adversary now sends M0 0n , M1 1n . The oracle will now choose
b {0, 1} and return C FK (r) Mb . This system is CPA secure but not
CCA secure. The oracle will not decrypt the challenge ciphertext C, but if
the adversary was to ip the rst bit of C,
the oracle will gladly decrypt it.
n1 n1
Now the returned plaintext message will be either 10 or 01 , making it
easy to see if b is 1 or 0.

This is why it is generally not considered sucient for a cryptosystem to

have IND-CPA security, and stronger notions are required. Which leads us
to chosen-ciphertext security.

18
 2.3. SECURITY DEFINITIONS

2.3.4 Denition: IND-CCA

Indistinguishability of encryptions under chosen-ciphertext attack takes into
account that the adversary could have access to decryption as well as encryp-
tion. This results in a stronger notion than IND-CPA, and it is described as
a LOR-oracle game by Katz et al. [13]:
For a symmetric key encryption system (Gen, Enc, Dec) with security
parameter n:
n
1. A key K is generated by running Gen(1 ).

2. The adversary A is given input 1n and oracle access to EncK () and

DecK (). The decryption oracle either outputs a plaintext or an invalid
message symbol . A outputs a pair of messages M0 , M1 of the same
length.

3. A random bit b {0, 1} is chosen, and then a ciphertext C

EncK (Mb ) is computed and given to A. We call C the challenge ci-
phertext.

4. The adversary A continues to have oracle access to EncK () and DecK (),
but is not allowed to query the latter on the challenge ciphertext itself.
0
Eventually, A outputs a bit b .

5. The output of the experiment is dened to be 1 if b0 = b, and 0 other-

wise.

We say the symmetric encryption scheme has indistinguishable encryp-

tions under chosen-ciphertext attack if for all probabilistic polynomial time
adversaries A there exists a negligible function negl() such that

1
P r[Experiment outputs 1] + negl(n)
2
Again we assume to be probabilistic and not deterministic for the same
reason as with IND-CPA, that encrypting the same message twice outputs
dierent ciphertexts.
The decryption oracle returns if the plaintext message does not have the
correct structure, correct headers etc, in other words does not look like it
had been encrypted by the oracle. This distinction will be useful for proving
IND-CCA later on.

IND-CCA is a reasonably strong notion about condentiality, keeping the

contents of a ciphertext secret, but we will now look at the property of in-
tegrity, ensuring that messages cannot be tampered with by an adversary

19
 2.3. SECURITY DEFINITIONS

A O
1n n
C K Gen(1 )


Mi Ci EncK (Mi )
B
Ci
C
Ci 6= C
B Mi DecK (Ci )
Mi
C

M0 , M1 {0, 1}l M0 , M1 b {0, 1}

B
C
C C EncK (Mb )


Mi Ci EncK (Mi )
B
Ci
C
Ci 6= C
B Mi DecK (Ci )
Mi
C

b0
B if b = b0 then
Output 1
else
Output 0

Figure 2.8: LOR-oracle IND-CCA game.

20
 2.3. SECURITY DEFINITIONS

and still be accepted by their receiver. This property will also be useful for
proving IND-CCA.

2.3.5 Denition: INT-PTXT

INT-PTXT is integrity of plaintexts. That is, the adversary's inability to
forge a ciphertext that decrypts to a valid plaintext that has not been en-
crypted by the oracle before. By valid we mean that a plaintext message has
the correct structure, correct headers etc, in other words a message that looks
like it had been encrypted by the oracle. A LOR-oracle is not applicable in
this setting as the adversary has to come up with his own answer rather than
choose from predened answers, so we use a regular oracle game.
For a symmetric key encryption system (Gen, Enc, Dec) with security
parameter n:
n
1. A key K is generated by running Gen(1 ).

2. The adversary A is given input 1n and oracle access to EncK ().

3. Querying EncK () with message M, the oracle returns C EncK (M ).

4. Eventually, A outputs a ciphertext C 0.

0
5. The output of the experiment is dened to be 1 if C decrypts to a
0
valid message M 6= that is distinct from all messages M queried to
the encryption oracle.

We say the symmetric encryption scheme has plaintext integrity if for all
probabilistic polynomial-time adversaries A there exists a negligible function
negl() such that

P r[Experiment outputs 1] negl(n)

1
Unlike IND-CPA and IND-CCA we are not interested in a
2
+ negl(n) prob-
ability here because, as we mentioned earlier, this is not a LOR-oracle setting.

This notion is important because if a cryptosystem does not have INT-PTXT

an adversary could inject a message of his own creation. However, it does
not take into account that the adversary could create ciphertexts that are
dierent from any seen before, but actually decrypt to a known plaintext,
which could be exploited for replay attacks. This is why we have the notion
of INT-CTXT.

21
 2.3. SECURITY DEFINITIONS

A O
1n n
C K Gen(1 )

 M
B
C
C C EncK (M )

C0
B M 0 DecK (C 0 )
if M 0 6= M 0 / M then
Output 1
else
Output 0

Figure 2.9: Oracle INT-PTXT game.

2.3.6 Denition: INT-CTXT

We have just looked at INT-PTXT which requires the decrypted plaintext
to be dierent from any sent to the oracle. The dierence with integrity
of ciphertexts is that in this setting we require the forged ciphertext to be
dierent from any output by the oracle. This is a stronger security notion
than INT-PTXT as the forged ciphertext is allowed to decrypt to a known
plaintext, and otherwise the two notions are identical.
For a symmetric key encryption system (Gen, Enc, Dec) with security
parameter n:
n
1. A key K is generated by running Gen(1 ).

2. The adversary A is given input 1n and oracle access to EncK ().

3. Querying EncK () with message M, the oracle returns C EncK (M ).

4. Eventually, A outputs a ciphertext C 0.
0
5. The output of the experiment is dened to be 1 if C decrypts to a valid
0 0
message M 6= , and C is distinct from all ciphertexts C returned by
the encryption oracle.

We say the symmetric encryption scheme has ciphertext integrity if for all
probabilistic polynomial time adversaries A there exists a negligible function
negl() such that

P r[Experiment outputs 1] negl(n)

22
 2.3. SECURITY DEFINITIONS

A O
1n n
C K Gen(1 )

 M
B
C
C C EncK (M )

C0
B M 0 DecK (C 0 )
if M 0 6= C 0 / C then
Output 1
else
Output 0

Figure 2.10: oracle INT-CTXT game.

The reason we are interested in having INT-CTXT is that it is a strictly

stronger notion than INT-PTXT, which we will show in the following claim:

Claim 1: INT-CTXT is a strictly stronger notion than INT-PTXT, e.g.

INT-CTXT INT-PTXT

Intuition Let's assume INT-PTXT. Then there exists a probabilistic

polynomial-time adversary that can forge a ciphertext that will decrypt
to a plaintext never queried to the oracle. As decryption is deterministic,
this implies the forged ciphertext is also dierent from all ciphertexts out-
put by the oracle, which further implies INT-CTXT. And by negation,
INT-CTXT INT-PTXT.

Furthermore, INT-CTXT can be used to prove IND-CCA. Together with

IND-CPA it is proven to have IND-CCA.

Claim 2: From Paterson [15] we have that IND-CPA and INT-CTXT im-
plies IND-CCA,

IND-CPA + INT-CTXT IND-CCA

23
 2.3. SECURITY DEFINITIONS

Intuition Assume Game 0 is the IND-CCA LOR-oracle game. Assume

Game 1 is the same as Game 0 except decryption queries to the oracle will
always return invalid message.
We see that the IND-CPA LOR-oracle game can perfectly simulate Game 1
because always returning invalid is equivalent to not having decryption ac-
cess at all.
And if the cryptosystem has INT-CTXT then Game 1 is equal to Game 0
because if the adversary is unable to choose a new ciphertext that decrypts to
a valid message, then the decryption oracle will not help him learn anything
more than the messages he already sent to the encryption oracle.
And so we have that IND-CPA + INT-CTXT IND-CCA.
Note that this does not hold if the decryption oracle can return more than
one error message.

So now we have established a strong notion for condentiality as well as

shown it can be provided by combining IND-CPA and INT-CTXT. In prac-
tice this is typically provided by using a message authentication code (MAC).
This is a tag t derived from a message M using the function t MacK (M )
with a shared secret key K. This tag is sent along with the message, and the
receiving user can then use a verication function VrfyK (t, M ) which outputs
1 if the tag is valid for the message and 0 if not. Or formally:

2.3.7 Denition: Message Authentication Code

We have from Katz et al. [13]: a message authentication code (or MAC) is a
tuple of probabilistic polynomial-time algorithms (Gen,Mac,Vrfy) such that:

1. The key generation algorithm Gen takes as input the security parameter
1n and outputs a key K with |K| b.

2. The tag-generation algorithm Mac takes as input a key K and a mes-

sage M {0, 1} , and outputs a tag t. Since this algorithm may be
randomized, we write this as t MacK (M ).

3. The verication algorithm Vrfy takes as input a key K, M,

a message
and a tag t. It outputs a bit b, with b=1 meaning valid and b=0
meaning invalid. We assume without loss of generality that Vrfy is
deterministic, and so write this as b VrfyK (M, t).
n
It is required that for every n, every key K output by Gen(1 ), and every

M {0, 1} , it holds that VrfyK (M, MacK (M )) = 1.

24
 2.3. SECURITY DEFINITIONS

Naturally we require these MACs to be secure. By secure we mean that

a probabilistic polynomial-time adversary could not forge a valid tag with-
out knowing K. This is formalized in an oracle game:
Consider the following experiment for a message authentication code
(Gen,Mac,Vrfy), an adversary A, and a value n for the security parameter:

n
1. A random key K is generated by running Gen(1 ).

2. The adversary A is given input 1n and oracle access to MacK (). The
adversary eventually outputs a pair (M, t). Let T denote the set of all
MAC tags output by the oracle.

3. The output of the experiment is dened to be 1 if and only if (1)

VrfyK (M, t) =1 and (2) t / T .

2.3.8 Denition: SUF-MAC

We say the message authentication code is strongly unforgeable under
an adaptive chosen-message attack, or just secure, if for all probabilistic
polynomial time adversaries A there exists a negligible function negl() such
that
P r[Experiment outputs 1] negl(n)
As we have seen, using a secure MAC to provide data integrity with an IND-
CPA secure encryption scheme can provide the strong condentiality notion
IND-CCA, but we would like to have a single notion that guarantees both
condentiality and integrity, which leads us to Authenticated Encryption.

Note that there also exists the notion of (weakly) unforgeable MACs for
which the tag output by A is only required to match a message not queried
to the oracle, but we will not cover it in this work as Bellare's article [5]
shows that it will not help us guarantee Authenticated Encryption.

2.3.9 Authenticated Encryption

While IND-CCA is a strong notion for guaranteeing condentiality, we would
like to cover both condentiality and data integrity under a single deni-
tion. This is known as Authenticated Encryption (AE), which is commonly
achieved by combining secure encryption with a strongly unforgeable message
authentication code. We have from Bellare's article [5] that AE is obtained
by having both IND-CPA and INT-CTXT, e.g.:

AE IND-CPA + INT-CTXT

25
 2.3. SECURITY DEFINITIONS

It is tempting to think that any combination of secure encryption and mes-

sage authentication will work, but as we will see the combination of even the
best tools have turned out to yield an insecure result. We will consider three
common approaches where K1 is an encryption key, MacK () is a message
authentication tag function outputting a tag t, and K2 is a secondary Mac
key:

Encrypt-and-authenticate: A message authentication tag is com-

puted from the message and the message is encrypted separately.

C EncK1 (M ) and t MacK2 (M )

The message receiver decrypts C to get M and then veries t on M.

Authenticate-then-encrypt: A message authentication tag is com-

puted from the message, and the two are encrypted together.

t MacK2 (M ) and C EncK1 (M ||t)

The receiver decrypts C to get M and t, and then veries t on M.

Encrypt-then-authenticate: The message is encrypted, and a mes-

sage authentication tag is computed from the ciphertext.

C EncK1 (M ) and t MacK2 (C)

The receiver veries t on C and if valid decrypts C to get M.

We will consider these insecure if even a single counterexample exists where

the construction is insecure assuming the encryption scheme is IND-CPA and
the MAC is a strongly unforgeable message authentication code.

Encrypt-and-authenticate From Katz et al. [13], let us note that an

authentication code can be secure without having any condentiality, and
thus may leak the entire plaintext message. This is easy to see. Con-
sider a secure MAC scheme = (Gen,Mac,Vrfy). Then the following is
0
also secure MacK (M ) = (M, MacK (M )). This clearly leaks the entire plain-
text and breaks condentiality. Therefore, we do not consider encrypt-and-
authenticate to be secure, even if there exists combinations for which it can
be secure.

26
 2.3. SECURITY DEFINITIONS

Authenticate-then-encrypt There also exists a counterexample for this

construction, as seen in Katz et al. [13]. Consider the following encryption
scheme:

The function Transform(M ) takes as input a bit string M of arbitrary

length. Any 0 in M is transformed into 00, and any 1 is arbitrarily
transformed into 01 or 10.
1
The inverse function, Transform , maps 00 back to 0 and 01 or 10 to 1.
1
If 11 is encountered, the result is . To clarify, Transform (0110) = 11
1
and Transform (0111) = .

The encryption function for this scheme is dened as EncK (M ) =

0 0
EncK (Transform(M )), where EncK is AES in CTR mode, which is
0
IND-CPA secure. The important point is that EncK generated a pseu-
dorandom key stream which it XORs with the plaintext.
Similarly, the decryption function is dened as DecK (C) = Transform1 (Dec0K (C)).

Now consider the following chosen-ciphertext attack:

An adversary receives a challenge ciphertext

C = Enc0K1 (Transform(M ||MacK2 (M ))

Now the adversary simply ips the rst two bits of the second block (note
that the rst block of counter mode is the nonce). He queries the decryption
0
oracle with this new C , which is dierent from C . We now observe that if
0
the rst bit of the plaintext M was 1, then the decryption of C will be valid
as the transformed message was ipped from 01 to 10 or vice versa. And
since the underlying message is unchanged, the MAC will also verify without
issue.
If the rst bit of M was 0 however, the oracle will return because the
transformed message was ipped from 00 to the illegal 11. This means the
adversary has now learned the rst bit of the plaintext, and he can repeat
this to uncover the full plaintext one bit at a time.
And so we see that this construction can be insecure in some cases, and we
will therefore consider it insecure.

Encrypt-then-authenticate For this construction we cannot come up

with a counterexample to break it, but we can give an intuitive proof that
this is in fact secure for all combinations.
It is clear that this construction has ciphertext integrity since the secure
MAC is computed from the ciphertext, which also means the MAC will not
leak any information about the plaintext. And we have assumed that the

27
 2.4. HASH FUNCTIONS

encryption scheme is IND-CPA secure, so we have INT-CTXT and IND-

CPA. As we saw in Bellare's article [5], this guarantees AE. This is why
encrypt-then-authenticate is the generally recommended construction.

2.4 Hash functions

A hash function is a function that takes input of arbitrary, or sometimes
xed, bit length and compresses it into a xed length output, a digest. A
common use for hash functions is integrity checking, verifying that a large
bit string has not been tampered with or corrupted, by computing its digest
and comparing this to one computed while the string was untouched. This
way we do not have to compare everything bit-by-bit, which is an ecient
way of validating large les after transfer, or to ensure a message received
was not tampered with.

2.4.1 Denition: Hash function

From Katz et al. [13]: a hash function is a pair of probabilistic polynomial
time algorithms (Gen,H) satisfying the following:

Gen is a probabilistic algorithm which takes as input a security param-

n n
eter 1 and outputs a key s. We assume that 1 is implicit in s.

There exists a polynomial l such that H takes as input a key s and a

s l(n)
string x {0, 1} and outputs a string H (x) {0, 1} (where n is
the value of the security parameter implicit in s).
0
If Hs is dened only for inputs x {0, 1}l (n) and l0 (n) > l(n), then we say
that (Gen, H) is a xed-length hash function for inputs of length l0 (n).

In the xed length case we require that l0 > l so that the hash function
compresses the input.

For cryptographic hash functions we want certain properties. First o, a

cryptographic hash function should be one-way, that is given a digest it is
extremely dicult to nd an input that hashes to this output. Secondly, it
should be extremely unlikely that two inputs have the same digest. This is
also known as collision resistance, which we will formally dene.

28
 2.4. HASH FUNCTIONS

2.4.2 Denition: Collision resistance

The strongest security notion for hash functions is collision resistance. This
is the setting where an adversary A must nd any two bit strings that have
identical digests, with no parameters xed beforehand. From Katz et al. [13]:

For a hash function =(Gen, H), an adversary A, and a security parameter

n:
n
1. A key s is generated by running Gen(1 ).

2. The adversary A is given s and outputs x, x0 . (If is a xed length hash

0 0 l0 (n)
function for inputs of length l (n) then we require x, x {0, 1} .)

0
3. The output of the experiment is dened to be 1 if and only if x 6= x
s s 0
and H (x) = H (x ). In such a case we say that A has found a collision.

We say the hash function is collision resistant if for all probabilistic polynomial-
time adversaries A there exists a negligible function negl() such that

P r[Experiment outputs 1] negl(n)

Cryptographic hash functions are generally compared against this notion as

it is the strongest, and having the property of collision resistance implies
resistance in all other settings.

2.4.3 Weaker notions of security for hash functions

Collision resistance is the strongest security denition for hash functions.
Strong in the sense that the hash function is assumed to be resistant even
when the adversary has the most freedom to nd a collision, but in some cases
a weaker notion will suce. Here we will consider three levels of security:

1. Collision resistance: This is the strongest notion as described above.

No parameters are xed, and the adversary has full freedom to nd any
two inputs that have identical digests.

2. Second pre-image resistance: A hash function is second pre-image

resistant if given s x it is infeasible for a probabilistic polynomial-
and
0 s 0 s
time adversary to nd x 6= x such that H (x ) = H (x). The adversary
is more restricted in that the one hash function input is xed before-
hand, and if one can nd a collision in this case it is easy to see that
collision resistance is also broken.

29
 2.4. HASH FUNCTIONS

3. Pre-image resistance: A hash function is pre-image resistant if given

s
s and y H (x) (but not x itself ) for a randomly chosen x, it is in-
0
feasible for a probabilistic polynomial-time adversary to nd a value x
s 0
such that H (x ) = y . This is equivalent to reversing the hash function,
and so we say that a cryptographic hash function should be one-way.

We will also consider a fourth, dierent notion, namely identical-prex colli-

sion resistance:

Identical-prex resistance: A hash function is identical-prex resis-

tant if given s and prex p it is infeasible for a probabilistic polynomial-
time adversary to nd x, x0 such that x 6= x0 and Hs (p||x0 ) = Hs (p||x).
The important point about identical-prex resistance is that if you can break
this then you have also broken collision resistance, e.g.:

Identical-prex resistance Collision resistance

It is however not comparable to pre-image or second pre-image, and thus not

stronger or weaker than either. The relationship between these four notions
is shown in gure 2.11, in which a circle represents the domain of instances
that are secure under a certain notion. These weaker notions will come in
handy in the attack in section 6.2.3.

Figure 2.11: Relationship between hash function resistance notions.

2.4.4 Breaking hash functions

Finding a hash collision can always be brute-forced in 2n/2 evaluations, n
being the number of bits output, because of the birthday paradox. A hash

30
 2.4. HASH FUNCTIONS

function is said to be cryptographically broken if there exists an attack that

n/2
can nd a collision with expected evaluations less than 2 .

2.4.5 Secure Hash Algorithm 1 (SHA1)

SHA1 is an aging cryptographic hash function rst published in 1993, taking
input of arbitrary length and outputting 160 bit pseudo-randomness. There
80
exists an identical-prex collision attack better than 2 operations as de-
scribed in section 6.1.2, rendering SHA1 cryptographically broken. Using
SHA1 today is considered bad practice for this reason.

31
Chapter 3
Protocols

In this chapter we will take a close look at the protocols and algorithms used
in Telegram, and more specically in their MTProto encryption scheme. We
will look at how a client is rst registered with the server, how it establishes
a secure, end-to-end encrypted connection to another peer and how the in-
ternals such as the key derivation function are constructed.
This analysis is based on the ocial Telegram client source code for version
2.7.0, downloaded in mid April 2015 from github [22].

3.1 Device registration

Upon rst installing the Telegram messaging application on a new device
the user will be prompted to enter his/her phone number. This is used for
authentication of the user for future logins as opposed to a username/email
and password. After entering the phone number, the user will receive a ve
digit code by SMS in order to verify the number. Upon entering this code in
the Telegram application, it will start the device authorization protocol.

This protocol goes as follows for a client C registering with server S:

1. C sends a request to S with a random bit-string nonce.

2. S responds with another random bit-string server_nonce, a composite

number n, and the ngerprint of a public RSA key.

3. C decomposes n into primes p and q such that p < q, which will serve
as proof of work. C has a list of public keys stored locally, and selects
the key serverpk that matches the received ngerprint.

32
 3.1. DEVICE REGISTRATION

4. C chooses another random bit-string new_nonce, that unlike nonce

and server_nonce C creates a payload
will not be sent in plaintext.
of the three nonces and the numbers n, p and q . This payload, along
with a digest of it, is encrypted using RSA under serverpk and sent to
S.

5. S responds with Die-Hellman parameters g, p, ga encrypted with AES-

256 in IGE mode, using temporary AES key and AES IV derived from
server_nonce and new_nonce.

6. C now chooses private value b and computes gb g b mod p and auth_key

(ga )b mod p. gb is sent to the server encrypted with AES-256 in IGE
mode using the temporary key and IV.

The random bit strings nonce and server_nonce are both 128-bit chosen at
random by the client and server respectively. The number new_nonce is a
256-bit bit string chosen at random by the client.
n is a composite 64-bit integer, which is the product of two odd primes p and
q , and the public RSA key ngerprint is the 64 least signicant bits of the
SHA1 digest of the server's public key.
The RSA encryption is performed using default Java RSA from javax.crypto.Cipher,
which uses the standard PKCS #1 approach. In this approach the padding
is pseudorandom data according to the Internet Engineering Task Force [8].

In order to decrypt the server response and obtain the DH parameters, the
client must derive the 256-bit AES key and IV, as shown in gure 3.1. The de-
crypted response contains nonce, server_nonce, the DH parameters g, p, ga
and a server timestamp used for synchronization. It also contains a 160-bit
SHA1 digest of contents. The response is padded with randomness which is
discarded with no checking apart from the length, which must be 0-15 bytes.

The client checks that the response contents match the digest that was
p1
sent with it, p must be a safe prime, meaning q = is prime, and
2
22047 < p < 22048 . g is equal to 2, 3, 4, 5, 6 or 7 and it must hold that
g generates a cyclic subgroup of prime order p1 2
, and that 1 < ga < p 1,
and if any of these checks fail, the protocol is aborted.

The private value b is a randomly generated 2048-bit bit string. The re-
quest that is sent to the server contains nonce, server_nonce and gb , as well
as a 160-bit SHA1 digest of these. The request is padded with randomness
prior to encryption, and encrypted using the temporary AES key and IV.
b
The client also computes the shared long-term key auth_key ga mod p.

33
 3.2. KEY EXCHANGE

Figure 3.1: Deriving temporary AES IGE key and IV during registration.

Upon receiving gb , the server does the same and sends response ok or failure
if nonce, server_nonce or any DH parameters are wrong.

Client and server now have a shared secret key which is used only for client-
server communication and regular (not end-to-end encrypted) chats, and the
client device is now registered and authorized. The Telegram application will
upload the client's phone contacts to the server in order to check if any of
them have already registered, and if so it automatically adds them as Tele-
gram contacts.

If the user tries to sign in from a new, unauthorized device, a new veri-
cation code will be sent. At rst through the Telegram application on an
authorized device, or through SMS if the former fails, and the above protocol
repeats.

3.2 Key exchange

In this section we will take a look at how two users initiate an end-to-end
encrypted secret chat.

According to Telegrams's website [24], a standard Die-Hellman (DH) key

exchange is performed in order to have the users agree on a shared master
secret, which later will be used for key derivation.

34
 3.2. KEY EXCHANGE

Two users A and B want to initiate a secret chat:

1. User A contacts the server in order to get the DH parameters, a prime

p and a generator g. A also receives a salt to help his client generate a
random secret value a.

2. A now computes public DH value ga g a mod p, and sends this to a

second user B.

3. B now receives this chat request and accepts on only one of his autho-
rized devices. He contacts the server to get the latest DH parameters
and generates his secret value b.

4. B computes public value gb g b mod p and sends it to A.

5. Both users now compute the shared secret auth_key gab mod p =
gba mod p, and the exchange is complete.

The clients are to verify that the DH parameters returned by the server sat-
p1
isfy the following: p must be a safe prime, meaning q = is prime, and
2
2047 2048
2 < p < 2 . g is equal to 2, 3, 4, 5, 6 or 7 and it must hold that
g generates a cyclic subgroup of prime order p1
2
. Also note that the DH
parameters obtained from the server are xed, but can be updated between
application versions.

Secret values a, b are generated the following way:

a = rclient rserver

Where rclient is 2048 random bits generated by the client, and rserver is 2048
random bits generated by the server. The reason for this is to help clients
1
with weak/awed random number generators .

Clients should verify that 1 < ga , gb < p 1, and it is also recommended

204864
to check that 2 < ga , gb < p 2204864 . The probability of this is
19 2
roughly 2 , or one in ten trillion which we consider outside of the realm
of possibility, and something must have gone wrong if it happens. If ga or gb
is less than 2048 bits long, they are padded with zeros.

Die-Hellman key exchange is based on the discrete logarithm problem, and

ensures that no passive eavesdropper could have learned auth_key . It is

1 Which was the case for Android back in August 2013 [1].
2 Or ten US quintillion.

35
 3.2. KEY EXCHANGE

however susceptible to an active man-in-the-middle attack as basic Die-

Hellman has no authenticity. We will look more into this in section 6.2.2.
What Telegram does to guarantee authenticity is to give each user a visual-
ization, a so called ngerprint, of auth_key and have them compare these.

The ngerprint of the shared secret key is the 128 least signicant bits of
SHA1(auth_key). This is visualized within the Telegram application as an
8x8 grid, each cell having one of four colors, as seen in gure 3.2. Users

Figure 3.2: 128-bit key ngerprint visualization within Telegram for android.

are intended to meet in person and compare these, ensuring there are no
dierences. In this case, the chat session has not been compromised by a
man-in-the-middle. But meeting in person often defeats the purpose of the
chat, to communicate from afar, and is much more cumbersome than say,
checking the users public key as with public key cryptography. This leads
most users to simply take a screenshot of the key ngerprint and send this
in the newly instantiated, unauthenticated chat. The man-in-the-middle has
a key ngerprint for each user, and it is very easy for him to fool them by
replacing the screenshot with one of his own. But assuming the users fol-

36
 3.3. MESSAGE ENCRYPTION

low the protocol, their chat session can be considered authenticated and safe
from third parties.

3.3 Message encryption

Message encryption is where Telegram gets interesting. It uses its own en-
cryption scheme, MTProto, which is intended to be computationally fast on
mobile devices, and with no compromise on security. This is accomplished
by using older primitives from back when computers were not as powerful,
and combining them in such a way that known attacks do not apply.

First let us look at the contents of a message, which we will refer to as

the payload:

Figure 3.3: Contents of the payload to encrypt.

Keywords of payload contents of gure 3.3:

Length: a 32 bit integer specifying the length of the payload (not

counting padding or the length itself ).

Header: each payload contains three xed headers related to the ver-
sion of the protocol and the last one specifying the type of attached
media, which we will always assume to be the media_empty header.

Random_bits: 120 random bits generated by the sending client, and

8 bits used to specify the length of random_bits in bytes. Used as a
message salt.

Layer: 32-bit integer specifying the version of the protocol.

seq_in: 32-bit counter for messages sent to the initiator of the chat.

37
 3.3. MESSAGE ENCRYPTION

seq_out: 32-bit counter for messages sent from the initiator of the
chat.

Random_id: 64-bit random number that is also sent in plaintext,

generated by the sending client.

ttl: time to live, a 32-bit integer specifying the number of seconds

the receiving user is allowed to see the message before it is deleted (a
feature we will not cover in this work).

Message: the message input by the user, of variable length.

Padding: Not actually in the payload, padding is added just before

encryption.

As of version 2.7.0 of April 2015, these are the contents of a message sent in
secret chats. Prior to being sent in a secret chat, this payload is encrypted
using MTProto as seen in gure 3.4.

Figure 3.4: Flow of MTProto encryption scheme.

Keywords of MTProto encryption in gure 3.4

38
 3.3. MESSAGE ENCRYPTION

auth_key: 2048-bit master secret, as exchanged in section 3.2. Only

the 1024 most signicant bits are used for key derivation.

Payload: the message construction as seen in gure 3.3.

msg_key: truncated 128 least signicant bits of the SHA1 hash of the
content to be encrypted. Used for integrity check.

Padding: 0-96 random bits generated by the sending client, added to

ensure every AES block has size 128 bit.

AES key and IV: the 256 bit key and 256 bit IV required by AES in
IGE mode. Derived using the KDF which we will see in section 3.4.

auth_key_id: 64 lower-order bits of the SHA1 of the shared auth_key.

In case of an auth_key_id collision, the shared key is regenerated.

As shown in gure 3.4, the integrity check msg _key is computed from every-
thing but the padding. We will see later on that this diers from Telegram's
own description in gure 4.1 where padding is included in msg _key and fur-
thermore is said to be 0-15 bytes (0-120 bit).

The code snippet in gure 3.5 is from sending messages in secret chats. It
hashes the payload and truncates it to nd the message key, and afterwards
adds padding.
In section 4.1.2 we'll see why the padding is in fact only 0-96 bits, and not
0-120 bits as claimed.

3.3.1 Message sequence numbers

A replay attack is an attack where an adversary records a sent message and
sends it to the recipient again at a later time. This injects the message into
the conversation without the original sender's knowledge. This is easily mit-
igated by including a message counter in every message, keeping track of the
order messages appear in.

Similarly, a mirroring attack is when the adversary records a message sent by

a user and sends it right back to him. If no precaution is taken, the message
will be injected and the user will think the other client had sent a message
identical to the one he just sent. Things get slightly trickier in this case, as
using just a message counter might get fooled. The user cannot know for
certain if the other client happened to send an identical message at the exact
same time, in which case the message counters would be the same.

39
 3.3. MESSAGE ENCRYPTION

708 byte [] messageKeyFull = Utilities . computeSHA1 (

toEncrypt . buffer ) ;
709 byte [] messageKey = new byte [16];
710 System . arraycopy ( messageKeyFull , messageKeyFull .
length - 16 , messageKey , 0 , 16) ;
711
712 MessageKeyData keyData = Utilities .
generateMessageKeyData ( chat . auth_key , messageKey ,
false ) ;
713
714 len = toEncrypt . length () ;
715 int extraLen = len % 16 != 0 ? 16 - len % 16 : 0;
716 ByteBufferDesc dataForEncryption = BuffersStorage .
getInstance () . getFreeBuffer ( len + extraLen ) ;
717 toEncrypt . position (0) ;
718 dataForEncryption . writeRaw ( toEncrypt ) ;
719 if ( extraLen != 0) {
720 byte [] b = new byte [ extraLen ];
721 Utilities . random . nextBytes ( b ) ;
722 dataForEncryption . writeRaw ( b ) ;
723 }

Figure 3.5: Padding added after deriving message key in implementation, as seen in
SecretChatHelper.java from the ocial repository.

This is why MTProto uses two message counters as described on Telegram's

website [28], one for incoming and one for outgoing messages (from the per-
spective of the initiator of the chat), and one bit of each is used to indicate
which user had sent a given message. Assume we have two users A and B,
A being the initiator of the chat.

Each secret chat contains two counters, seq_out and seq_in.

These are initialized to (0,0).

Both are incremented by 1 after each sent message.

They are transformed as follows:

2 seq _no + x

where x is determined by the following rule:

seq _in seq _out
message sent by A 0 1
message sent by B 1 0

40
 3.3. MESSAGE ENCRYPTION

Both clients maintain the raw (untransformed) counters, and the two trans-
formed counters are included in every sent message.

Now if an adversary tries to do a replay attack, the message receiver will

see that he already received a message with the same sequence number, and
discard the replay message.
If the adversary attempts a mirroring attack on user A for example, A will
see that the message is outgoing and not meant for him, and discard the
message.

3.3.2 Message decryption

Message decryption in MTProto looks very similar to the encryption process,
as shown in gure 3.6.

Figure 3.6: Flow of MTProto decryption scheme.

Not shown is that rst the received auth_key _id matches the one associ-
ated with the secret chat on the client. If not, the message is discarded. We
will go more in-depth with how parameters are checked upon decryption in
algorithm 1.

41
 3.3. MESSAGE ENCRYPTION

The pseudocode in algorithm 1 takes as input auth_key _id0 , msg _key 0 ,

encrypted_data. It uses methods SHA1(input) and readBits(input, skip, length)
where skip is the number of bits to skip and length the number of bits to
read from input. We will cover the KDF method in section 3.4.
At line 11 payload is reduced in length, this is done to remove the padding
before msg _key is computed.
We see that if at any time a check fails, the received message is discarded
entirely with no error message returned.

Algorithm 1 MTProto decryption algorithm

Input: auth_key _id0 , msg _key 0 , encrypted_data

1: auth_key _id computeAuthKeyID(auth_key);

2: if auth_key_id0 6= auth_key_id then
3: discard;
4: end if
5: AESkey, AESiv KDF(auth_key, msg _key 0 );
6: payload AES-IGE_Decrypt(encrypted_data, AESkey, AESiv);
7: length readLength(payload);
8: if length out of bounds then
9: discard;
10: end if
11: payload removePadding(payload);
12: msg _key computeMsgKey(payload);
13: if msg_key0 6= msg_key then
14: discard;
15: end if
16: seq _in, seq _out readMessageCounters(payload);
17: if seq_in, seq_out 6= local seq_in, seq_out then
18: discard;
19: end if
20: return payload;

3.3.3 Authenticity of encrypted messages

It is clear that MTProto provides condentiality by using AES encryption,
and plaintext integrity comes from the msg _key . Additionally, IGE mode
provides ciphertext integrity by garbling the message if the ciphertext is tam-
pered with. What is not as clear is how MTProto provides authenticity.

42
 3.4. KEY DERIVATION FUNCTION

MTProto clearly does not use the encrypt-then-authenticate construction

which we discussed in section 2.3.9, in fact it does not use a MAC at all.
Instead, authenticity is veried by the receiver of a message by checking that
the received msg_key matches the digest of the decrypted message. If this
check passes, then the encryption and decryption keys must have been de-
rived from the same shared secret, and thus it must have been encrypted and
sent by the second user in a secret chat, who is authenticated by comparing
the auth_key ngerprints.

3.4 Key Derivation Function

In this section we will look at how MTProto computes the encryption keys
used for AES-IGE.

MTProto uses AES in IGE mode with 256 bit keys. IGE requires an ini-
tialization vector twice the size of one AES block, 256 bit. A new key and
IV pair is generated for every message, and these are derived from the secret
auth_key and the message itself. This is to ensure only the other holder of
the auth_key can decrypt the message, and that the key will only decrypt
the one message.

The way the key and IV is derived is by the use of multiple SHA1 hashes
[27]. Presumably because a single SHA1 hash only outputs 160 of the 512
bits needed. Using a newer hash function such as SHA-512 would be ideal
here, but MTProto has chosen to stick with SHA1.

As shown in gure 3.7, four SHA1 hashes are performed, each taking as
input 256 bit of the auth_key and the 128 bit msg _key (which we recall
is the truncated SHA1 digest of the message). In total, the 1024 most sig-
nicant bits of the auth_key are used. Also note that the position of the
msg _key in the hash input is shifted each time, presumably to make the
outputs more "random" even though there is no evidence of this being true.
The AES key and IV are then formed by taking substrings of each of the
four SHA1 outputs and concatenating them to form two 256 bit strings. It
is unclear why they are combined the way they are, and not just using 64 bit
of each output per string.

The key derivation function is described more precisely in pseudo-code al-

gorithm 3.8, using readBits(input, skip, length) where skip is the number of
bits to skip and length the number of bits to read from input.

43
 3.4. KEY DERIVATION FUNCTION

Figure 3.7: SHA1 based key derivation function used in MTProto.

1 sha1_a <- SHA1 ( msg_key || readBits ( auth_key ,0 ,256) )

2 sha1_b <- SHA1 ( readBits ( auth_key ,256 ,128) || msg_key ||
readBits ( auth_key ,384 ,128) )
3 sha1_c <- SHA1 ( readBits ( auth_key ,512 ,256) || msg_key )
4 sha1_d <- SHA1 ( msg_key + readBits ( auth_key ,768 ,256) )
5 AES_key <- readBits ( sha1_a ,0 ,64) || readBits ( sha1_b ,64 ,96)
|| readBits ( sha1_c ,32 ,96)
6 AES_IV <- readBits ( sha1_a ,64 ,96) || readBits ( sha1_b ,0 ,64)
|| readBits ( sha1_c ,128 ,32) || readBits ( sha1_d ,0 ,64)

Figure 3.8: MTProto Key Derivation Function on input (auth_key,msg_key)

3.4.1 Forward Secrecy

Forward secrecy of a system is the property ensuring that a session key de-
rived from a set of long-term keys will not be compromised if one of the
long-term keys is compromised. Compromise of a single long-term key will
only allow access to messages protected by that one key.

In MTProto [25] this corresponds to the AES keys being derived from the

44
 3.4. KEY DERIVATION FUNCTION

auth_key which is xed for a secret chat. If the auth_key is compromised,

an adversary would gain access to every message sent. This is why version
20 of MTProto introduced a counter key _use_count keeping track of the
number of times an auth_key is used to derive an AES key for encryption
or decryption. If this counter reaches 100 or the secret key has been in use
for more than one week, a new auth_key will be exchanged and the old one
destroyed.

This new key exchange reuses the DH parameters that were received from
the server during the initial key exchange, and no server randomness is added
when generating new secret values a and b. One user will compute his public
value ga and send this to user B through the already established chat. B will
respond with his new public value gb , and both users compute and update the
auth_key for the existing session, the same way that it was done in section
3.2. All older messages will remain decrypted and readable on both clients.
The auth_key ngerprint used for clients to authenticate each other will not
be changed.

This means that if an adversary gets hold of an old auth_key he will be

able to derive AES keys and read 100 encrypted messages, but he will not
be able to construct the next key from the public DH values.

3.4.2 Backwards compatibility

MTProto has received several updates over the years, and as a result there is
no guarantee that all clients are on the latest version. To ensure clients can
communicate across dierent versions, known as layers, the updated layers
are made backwards compatible with the older ones.

The ocial Telegram client does a layer version negotiation as soon as the
secret chat key exchange is completed. The auth_key is stored in an en-
cryptedChat object along with a layer initialized to 0. The initiator of the
chat A sends his layer in an encrypted message to B, and B responds with
his layer version. Both clients store the lower of the two layers in the en-
cryptedChat object in order to conform with the older version.

The current latest layer is version 23. Forward secrecy was introduced in
layer 20, but apart from that no major changes have happened since layer
17. In layer 16 and down to 8 (the version that introduced secret chats),
message sequence numbers were handled very dierently. Rather than being
included in each encrypted message, they were stored and maintained on the

45
 3.4. KEY DERIVATION FUNCTION

proprietary server, and the message payload looked as shown in gure 3.9.

Figure 3.9: Contents of the payload to encrypt for versions below 17.

This meant that an encrypted messages did not contain any indication of the
message's sequence number nor which of the two users had sent it, and the
clients would have to trust the server to take care of this.

The messages themselves did not contain any mechanism to stop an unau-
thorized third party from sning sent messages and performing replay or
mirroring attacks as discussed in section 3.3.1, which is mitigated by further
encrypting the messages under the client-server authorization key from 3.1.

46
Chapter 4
Result of analysis

In the previous chapter we analyzed how MTProto is constructed and how

it works. In this chapter we will outline weaknesses discovered and propose
attacks that exploit them.

4.1 Random padding vulnerability

Under device registration and message encryption we observed that random
padding is applied prior to AES-IGE encryption. This is not exploitable pro-
vided the padding has integrity and authenticity, which the diagram in gure
4.1 from Telegram's website [27] claims is the case. However as we saw in
gure 3.4, the padding is not added until after the msg _key has been com-
puted, and as a result the padding does not have integrity nor authenticity.
This means the ciphertext block containing the padding could be modied
undetected with non-negligible probability. Using this knowledge, we will
present two attacks breaking IND-CCA and INT-CTXT, and by extension
AE, focusing on the message encryption for MTProto.

4.1.1 IND-CCA attack #1: padding length extension

The following attack on MTProto exploits the fact that the length of the
padding is never checked, and allows an adversary A to win the IND-CCA
security game by adding extra blocks of padding to a ciphertext. The attack
is visualized in gure 4.2.

1. A outputs messages M0 , M1 , M0 6= M1 of the same length.

2. O chooses b {0, 1} at random and outputs challenge ciphertext C

Enck (Mb ).

47
 4.1. RANDOM PADDING VULNERABILITY

Figure 4.1: Flow of MTProto encryption scheme, from Telegram.org.

3. A now appends a 128 bit block of randomness cr to C, asks O to

0
decrypt C C||cr 6= C .

4. O decrypts C0 and reads the payload length from it. Anything that
comes after this length, e.g. the padding, is discarded, both the real
0
padding and the extra block. O outputs M Deck (C||cr ) = Mb .

5. A outputs 1 if M 0 = M1 or 0 if M 0 = M0 .
This attack works for any number of extra blocks (at least 1), and the ad-
versary wins with probability 1. This proves that MTProto does not have
indistinguishability of encryptions under chosen-ciphertext attack. The same
attack can be used to win the INT-CTXT game, just substitute the two mes-
sages M0 , M1 with a single message M and the challenge ciphertext C will
be the encryption of M. Again, the ciphertext C 0 is dierent from C , so it

48
 4.1. RANDOM PADDING VULNERABILITY

Figure 4.2: Modifying the ciphertext by extending the padding will not be detected upon
decryption.

will be decrypted to a valid plaintext with probability 1.

We had from 2.3.9 that

AE IND-CPA + INT-CTXT

and as we have shown that INT-CTXT is broken, that means AE is also

broken.

Extending the message works ne, but it is in fact also possible to break
IND-CCA and INT-CTXT without changing the length, with non-negligible
probability.

4.1.2 IND-CCA attack #2: padding plaintext collision

The padding is never authenticated, so modifying (and garbling) the last
16-byte (128-bit) block has a non-negligible probability of having a collision
in the plaintext bits, disregarding the padding. Consider the following:

1. A sends a message M, the length of M in bytes being equal 1 mod 16.

2. MTProto will hash M into msg _key SHA1(M ) (truncated to 128

bits), which provides integrity for the plaintext.

49
 4.1. RANDOM PADDING VULNERABILITY

3. Prior to encryption, 15 random bytes of padding r are added to the

message, and the payload is encrypted

C Enck (M ||r)

4. A now modies the last 16 byte block of the ciphertext to get C 0 6= C .

5. A outputs C 0.

Upon decryption M 0 || padding Deck (C 0 ), the last block will be garbled

due to the non-malleability of IGE. However, since the 15 padding bytes are
not part ofmsg _key , only the rst byte has to match the original message
0
when msg _key SHA1(M ) is computed and checked against the received
msg _key . This means we have a 28 = 256
0 1
probability that the last byte
0
of M will be the same as that of M , and the modied ciphertext will be
accepted without detection.

This would be the best case scenario for the attack. However, when the
message String in Java is serialized, the result is a multiple of 4 bytes with
any unused bytes made 0. Take for example the string 'Test'. The rst byte
is the string length, 4. Next are the four bytes corresponding to each charac-
ter, followed by a message header from MTProto. We expect these to come
in succession, but we actually get a three 0 byte padding before the header.

1 Expected : 04 54 65 73 74 4 A 5 C 9 F 08
2 Reality : 04 54 65 73 74 00 00 00 4 A 5 C 9 F 08
As we see in gure 3.3, all data in the payload is a multiple of 4 bytes, there-
fore the total message encrypted is a multiple of 4 bytes, and as such it's
impossible to have a message length equal 1 mod 16 bytes. Instead, the best
case is to have a length equal 4 mod 16, with 12 bytes of padding instead of
8
15, and so the probability of nding a plaintext collision is reduced from 2
32 1
to 2 = 4294967296 , which is much less feasible.

The attack can be used to get the oracle to decrypt the challenge cipher-
text in the IND-CCA security game and will also decrypt to a valid plaintext
32
in the INT-CTXT game. As 2 is still non-negligible in the security pa-
rameter, we again conclude that MTProto does not have indistinguishability
of ciphertexts nor ciphertext integrity, and by extension not authenticated
encryption.

These attacks would both be impossible if the implementation followed gure

4.1 and included the padding in msg _key .

50
 4.2. REPLAY AND MIRRORING ATTACKS IN OLDER VERSIONS

4.2 Replay and mirroring attacks in older ver-

sions
As we saw in section 3.4.2, in the still supported versions 16 and down the
clients had to trust the server to maintain message sequence numbers as the
messages themselves contained no such mechanism. But this means a mali-
cious server is given full control of the ow of messages. The server, although
incapable of reading message contents, can choose to withhold, replay, reorder
or mirror messages at will. If the server was to somehow learn the contents
of older messages, it could freely inject them at any time and impersonate
either or both users. This vulnerability would be less signicant if there was
forward secrecy as the server would have at most 100 valid messages to inject
at a time, but recall that forward secrecy was not introduced until version 20.

Do note however that the version negotiation is done after the key exchange
has taken place, and as such the server isn't able to actively lower the ne-
gotiated version. One of the clients will have to actually be at version 16 or
older for the chat to be vulnerable.

4.3 Timing attacks on MTProto

A timing attack is an attack based on the time between sending a message
and receiving an error response. If a system checks several parameters se-
quentially and responds as soon as one check fails, it is then possible to gure
out how many checks have passed based on the timing. Telegram is intended
for use on mobile devices and one might argue that weak signal will inuence
timing by an order of magnitude more than CPU cycles, but disregarding
this we will look into the implementation of MTProto and see if it would be
susceptible to a timing attack.

Looking through the source code for Telegram's decryption implementation

reveals that upon receiving a message, the following checks are performed in
order:

1. Received auth_key_id is compared to the one stored locally.

2. After decryption the message length in bytes is checked to be larger

than 0 and smaller than the number of received bytes.

3. The msg_key is computed and compared to the one sent in plaintext.

51
 4.3. TIMING ATTACKS ON MTPROTO

4. The sequence numbers are checked against the local counter.

The decryption process immediately aborts if any check fails, which led us to
believe that a timing attack might be possible. This was put to the test by
sending a message in a secret chat, but with the encrypted payload replaced
with random bits.

The result is that when any check fails, the message is simply not accepted
by the receiver and is forever marked as unread in the sending client, and the
sender does not get any notication about failure. As such, it is infeasible to
perform a remote timing attack on MTProto. However, if an attacker had
gotten a user to install a malicious application on their device, this could
gather information about when Telegram is running. But this is a whole
dierent topic, and we will not go into further detail with it.

52
Chapter 5
Experimental validation

In this chapter we will implement and verify the attacks proposed in chap-
ter 4. In order to verify these an MTProto simulator has been built, which
functions as a fake server between two users. This is built by extracting the
core functionality of the encrypt and decrypt methods from the Telegram for
Android source code, stripping them of all actual network connectivity, into
a simple Java program. Two fake users A and B are generated with random
user IDs, and a secret chat is set up with a randomly generated authorization
key, as opposed to running the Die-Hellman key exchange.
User A can then be instructed to encrypt a message, outputting the cipher-
text to the fake server. The fake server can apply any of the proposed attacks
before forwarding the modied ciphertext to user B. B will then use the de-
crypt method to verify that the message passes all checks and would have
been accepted in an ocial client, or reject if the message is corrupt.

5.1 Attack #1: padding length extension

The attack from 4.1.1 has been implemented, and it works as follows. A
method addPadding() is given two arguments: the encrypted message object
containing the ciphertext and an integer specifying the number of blocks of
padding to be appended.

A new byte array of size equal to the original ciphertext plus the extra blocks
is created, and the ciphertext is copied into it. Next an array of random bytes
is created and copied into the new array. The source code for this can be
seen in gure 5.1.

Experiments have been run appending 1 to 20 blocks of extra padding, and in

53
 5.1. ATTACK #1: PADDING LENGTH EXTENSION

1 public static ByteBufferDesc addPadding ( TLRPC .

TL_messages_sendEncrypted encrypted , int numBlocks ) {
2 if ( numBlocks > 0) {
3 int fakePaddingSize = 16 * numBlocks ;
4 int length = encrypted . data . limit () ;
5 byte [] encryptedMessageExtended = new byte [ length +
fakePaddingSize ];
6 encrypted . data . position (0) ;
7 System . arraycopy ( encrypted . data . readData ( length ) , 0 ,
encryptedMessageExtended , 0 , length ) ;
8 byte [] fakePadding = new byte [ fakePaddingSize ];
9 Utilities . random . nextBytes ( fakePadding ) ;
10 System . arraycopy ( fakePadding , 0 ,
encryptedMessageExtended , length , fakePadding . length
);
11 return new ByteBufferDesc ( encryptedMessageExtended ) ;
12 }
13 else return encrypted . data ;
14 }

Figure 5.1: Code snippet for padding length extension attack

every case the modied ciphertext has been decrypted and accepted without
errors. This conrms the eectiveness of the attack, and if used as proposed
in section 4.1.1 this breaks IND-CCA security.

Short-term countermeasure This attack could be mitigated by simply

checking the length of the padding upon decryption. The following code
snippet is from the MTProto decryption implementation, where is is a byte
array holding auth_key _id, msg _key and the encrypted payload, as output
in 3.4. The payload is decrypted, and the payload length is read from the
plaintext.

1319 int len = is . readInt32 () ;

1320 if ( len < 0 || len > is . limit () - 28) {
1321 return null ;
1322 }

is.limit - 28 is the length of the payload contents with padding and len is
the length without padding. The padding should never be longer than 15
bytes, and so what we need to do is add is.limit() - 28 > len + 15.
This mitigates the padding length extension attack and as it is only a con-
ditional check, it has no impact on the encryption and decryption methods.

54
 5.2. ATTACK #2: PADDING PLAINTEXT COLLISION

1 int len = is . readInt32 () ;

2 if ( len < 0 || len > is . limit () - 28 || is . limit () - 28
> len + 15) {
3 return null ;
4 }

This means it has no impact on client compatibility, and an updated client

would have no trouble communicating with one that does not have this patch.

5.2 Attack #2: padding plaintext collision

The implementation of 4.1.2 goes as follows. The ciphertext is copied into a
new byte array, except for the last 16 byte block. Now 16 random bytes are
generated and copied in their place.

1 public static ByteBufferDesc changeLastBlock ( TLRPC .

TL_messages_sendEncrypted encrypted ) {
2 byte [] data = new byte [ encrypted . data . limit () ];
3 encrypted . data . position (0) ;
4 System . arraycopy ( encrypted . data . readData ( encrypted . data .
limit () ) , 0 , data , 0 , encrypted . data . limit () - 16) ;
5 byte [] fakeData = new byte [16];
6 Utilities . random . nextBytes ( fakeData ) ;
7 System . arraycopy ( fakeData , 0 , data , encrypted . data . limit ()
- 16 , fakeData . length ) ;
8
9 return new ByteBufferDesc ( data ) ;
10 }

Figure 5.2: Code snippet for padding plaintext collision attack

1 232 1
With a probability of success, there's a probability of failure. To
232 232
have a probability of .5 of nding a collision, one would have to do x attempts,
for x x
232 1 232 1
 
1 = 0.5 1 0.5 =
232 232

x = log 232 1 (0.5)

232

=2.977 109

One instance of the attack nished in 1.592 109 attempts, taking 5.8 hours
without any parallelization on a Intel Xeon E5-2680 v2 @ 2.80GHz. Compar-

55
 5.2. ATTACK #2: PADDING PLAINTEXT COLLISION

ing plaintexts, the last block of the original message and the found collision
were

1 Original : 4 A5C9F08 D4F33C82 657924 AE 4 B403ECB

2 Found : 4 A5C9F08 6255 B92D 62 F6AC8B 318374 B0
For every pair of hexadecimal characters representing one byte, we see that
the rst four bytes are indeed identical, whereas the padding bytes are dif-
ferent.

Other tests have nished in 1.606 109 to 7.109 109 attempts. This prob-
abilistic approach is trivially parallelizable as all attempts are fully indepen-
dent, but we will not implement optimizations in this work.

Short-term countermeasure In order to mitigate this vulnerability, we

need to verify integrity of the padding. This is easily accomplished by includ-
ing the padding in the msg _key , which serves as integrity for the message
already, and which would make secret chat message encryption function as
described in gure 4.1 from Telegram's website. All the way back in gure 3.5
we saw how the msg _key is computed before padding is added, and simply
rearranging these code chunks will give the following:

1 len = toEncrypt . length () ;

2 int extraLen = len % 16 != 0 ? 16 - len % 16 : 0;
3 ByteBufferDesc dataForEncryption = BuffersStorage .
getInstance () . getFreeBuffer ( len + extraLen ) ;
4 toEncrypt . position (0) ;
5 dataForEncryption . writeRaw ( toEncrypt ) ;
6 if ( extraLen != 0) {
7 byte [] b = new byte [ extraLen ];
8 Utilities . random . nextBytes ( b ) ;
9 dataForEncryption . writeRaw ( b ) ;
10 }
11
12 byte [] messageKeyFull = Utilities . computeSHA1 (
dataForEncryption . buffer ) ;
13 byte [] messageKey = new byte [16];
14 System . arraycopy ( messageKeyFull , messageKeyFull .
length - 16 , messageKey , 0 , 16) ;
15
16 MessageKeyData keyData = Utilities .
generateMessageKeyData ( chat . auth_key , messageKey ,
false ) ;

Now the padding is part of the msg _key , and thus has integrity. We will

56
 5.3. MALICIOUS SERVER ATTACKS

also have to modify the decryption implementation to include the padding

when checking integrity, where the current implementation is the following
code snippet:

1323 byte [] messageKeyFull = Utilities . computeSHA1 ( is . buffer

, 24 , Math . min ( len + 4 + 24 , is . buffer . limit () ) ) ;
1324 if (! Utilities . arraysEquals ( messageKey , 0 ,
messageKeyFull , messageKeyFull . length - 16) ) {
1325 return null ;
1326 }

What has to be done here, is replacing Math.min(len + 4 + 24, is.buer.limit())

with just is.buer.limit().
1 byte [] messageKeyFull = Utilities . computeSHA1 ( is . buffer
, 24 , is . buffer . limit () ) ;
2 if (! Utilities . arraysEquals ( messageKey , 0 ,
messageKeyFull , messageKeyFull . length - 16) ) {
3 return null ;
4 }

Now we check the integrity of the padding, and the padding block plaintext
128
collision attack now has probability 2 of succeeding, which is negligibly
low in the length of an AES block.

Checking integrity of the padding also happens to mitigate the padding

length extension attack, however this security patch will render updated
clients incompatible with unupdated ones, as messages sent between them
will always fail the integrity check.

5.3 Malicious server attacks

The attack described in section 4.2 was tested on the local test setup in the
following experiments:

Two users A and B communicate through the malicious server S . A's layer
is set to 16. The experiments are all based on S discarding or storing and
later forwarding messages, and the concepts of the four attacks are shown in
gure 5.3. Carrying out these attacks in our local test setup, we found that
in all cases the clients will accept messages and the attacks are successful.

57
 5.3. MALICIOUS SERVER ATTACKS

A S B
Replay
C EncK (M ) C
B
C
B M DecK (C)
C
B M DecK (C)

Mirroring
C EncK (M ) C
B
M DecK (C) C
C

Withholding

C1 EncK (M1 ) C 1
B
C2 EncK (M2 ) C 2
B
C2
B M2 DecK (C2 )

Reordering

C1 EncK (M1 ) C1
B
C2 EncK (M2 ) C2 C2 M2 DecK (C2 )
B B
C1 M1 DecK (C1 )
B

Figure 5.3: The naive MitM attack.

Short-term countermeasure The way to mitigate these attacks is of

course to take away control from the server, and let the clients themselves
handle message counters independently. This is exactly what was done in
version 17, and so what needs to be done is to remove backwards compati-
bility for versions 16 and older.

58
Chapter 6
Known attacks

In this chapter we will outline known attacks on the primitives MTProto

is built upon, as well as attacks on MTProto itself. Looking at SHA1, we
will go in-depth with how much it would cost to ne a collision on today's
hardware, and the attacks on MTProto are all man-in-the-middle attacks,
one of which has been patched out.

6.1 Known attacks on primitives

6.1.1 IGE is not BACPA secure
Bard [4] states that IGE encryption mode is CPA secure, but it is proven to
be blockwise-adaptive chosen-plaintext attack (BACPA, 2.3.3) insecure, for
both the general and primitive notion.

Recall that in IGE encryption, a plaintext block is XOR'd with the previous
ciphertext block prior to running the encryption function.

ci1 fK (mi ci1 ) mi1

To win the BACPA security game, the adversary needs to nd a collision
between two blocks before they enter the encryption function, after they are
XOR'd with the precious ciphertexts. This way, the output ciphertext blocks
will be the same, just XOR'ed with a plaintext block that the adversary
already knows. Creating a collision is trivially accomplished due to the way
IGE mode does XOR before and after encryption. All the adversary has to
do is send two random message blocks to get their encryption, and then he
can compute a third block that will encrypt to the same as the second block,
causing a collision. This attack is also shown in gure 6.1.

59
 6.1. KNOWN ATTACKS ON PRIMITIVES

n
1. A key K is generated by running Gen(1 ) and 1n is given to O and A.
O chooses two initial blocks m0 , c0 at random.

2. A chooses and outputs two identical message blocks m01 , m11 .

3. O computes and returns

c1 m0 EncK (mb1 c0 )

4. A chooses and outputs two identical message blocks m02 , m12 .

5. O computes and returns

c2 mb1 EncK (mb2 c1 )

6. A now computes
m03 m02 c1 c2
and chooses m13 6= m03 .

7. O computes and returns

c3 mb2 EncK (mb3 c2 )

8. A now checks if
?
m01 m02 c3 = c2
If this is true then A knows b = 0, else b=1 and A has thus won the
game.

This attack wins the BACPA oracle game with probability 1. The reason for
the way m03 is chosen is that if b = 0, then:

c3 =m02 EncK ((m02 c1 

c2 ) 
c2 )
=m02 EncK (m02 c1 )

And in this case we can turn c3 back into c2 :

m01 m02 c3 =m01 

m02 
 m EncK (m02 c1 )
02
=m01 EncK (m02 c1 )
=c2

If the result of the above is not c2 then we can say for sure that b = 1.

60
 6.1. KNOWN ATTACKS ON PRIMITIVES

A O
1n n
C K Gen(1 )
m01 {0, 1}128
m11 m01 m01 , m11 b {0, 1}
B
m0 , c0 {0, 1}128
c1 c1 m0 EncK (mb1 c0 )
C
m02 {0, 1}128
m12 m02 m02 , m12
B
c2 mb1 EncK (mb2 c1 )
c2
C
m03 m02 c1 c2
m13 {0, 1}128 , m13 6= m03 m03 , m13
B
c3 mb2 EncK (mb3 c2 )
c3
C
if c2 = m01 m02 c3 then
b0 = 1
else
0
b =0
b0
B

Figure 6.1: LOR-oracle IND-BACPA attack.

61
 6.1. KNOWN ATTACKS ON PRIMITIVES

This means systems using IGE do not even have indistinguishable of encryp-
tions under (blockwise-adaptive) chosen-plaintext attack, one of the weaker
notions, and as only a single query was made for which m1i 6= m0i it holds
for both the general and primitive notion. But as Telegram points out [26],
it does not apply to MTProto. This is because the AES key and IV are
dependent on the message content, which has to be xed prior to encryption.
Any blockwise-adaptive attack is impossible because one cannot change a
single block without changing the encryption key.

6.1.2 Security of SHA1

SHA1 is used in Telegram because it is less computationally intensive than
most hash functions, even though better alternatives exist such as the more
secure SHA2 and SHA3, or even BLAKE [3] which was one of the nal candi-
dates for SHA3 and performs faster than SHA1. SHA1 is cryptographically
61
broken as a 2 identical-prex collision attack has been published by Stevens
[21] in 2012, but how costly is it actually to break?

In 2012, Jesse Walker from Intel did a back-of-the-envelope prediction of the

future cost of nding SHA1 hash collisions, as posted on Bruce Schneier's
blog [19].

60 1
The short analysis, based on Stevens' 2 attack , assumes the cost of nding
74 14
a collision is 2 cycles as each SHA1 operation requires 2 cycles.

Jesse estimates that a modern server with 4 processors, each with 8 cores, is
61
able to carry out 2 cycles per year. Taking Moore's law into account, that
63 65
number should have increased to 2 by this year 2015, 2 by 2018, and so on.

In 2012 it would have cost $2.77 million to carry out this attack on an Ama-
zon rental server. Assuming the rental price is xed as the server hardware
gets upgraded, one could nd a collision for $700k in 2015, $173k by 2018,
and $43k by 2021. These lower costs are within reach of organized criminals
and university research projects.

Looking at Amazon's oerings shows that these estimates are not entirely
accurate. Jesse most likely looked at what is called the m1.small [2] which
indeed costs $0.04 per hour or $350 per year. This only oers a single core
and not four 8-core CPUs. Since then Amazon has upgraded to the newer

1 Appears to be a typo in the analysis, Stevens' paper [21] reads 261 .

62
 6.1. KNOWN ATTACKS ON PRIMITIVES

Intel Sandy Bridge architecture and the price remains comparable, but it
is not clear how big the performance gain is and hard to conrm the 2015
prediction.

It is more interesting to look at how the introduction to cryptocurrencies

have changed the price of computing hashes, take for example Bitcoin which
is based on computing SHA256 hashes. Looking at statistics for Bitcoin min-
17
ing [7], we see that currently about 410 hashes are performed every second
59
by the community. This is roughly 2 hashes per second, which means that
if they all focused their computational power on nding one SHA1 collision
this could be done in about 4 seconds.

If we look at the price of specialized hardware for solving SHA256 hashes

[31], we nd that the AntMiner S5 has the highest hash rate per power con-
12
sumed at 1.15 10 hashes per second at 590 W, and costing only $370.
12 40
As 1.15 10 2 it needs to run for
261
= 221 seconds
240
or roughly 24 days to nd a collision. The cost of running it for 24 days is

590 24 24
= 339.84 kWh
1000
which at $0.12 per kWh [20] comes out to about $40 per collision (plus $370
for the hardware).

Bear in mind this is for computing SHA256 hashes, not SHA1, but as SHA1
is less computationally intensive it would presumably be cheaper to build
specialized hardware for computing it. This is shockingly cheap and could
be aorded by anyone, and we might as well assume that a SHA1 collision
could be trivially found. And let us have a look at the consequences if this
was the case.

6.1.3 SHA1 collision consequences for Telegram

In MTProto, SHA1 is used for computing the auth_key_id ngerprint, the
msg_key, and for the auth_key visualization. It is also used in the key deriva-
tion function, but as neither the input nor output ever leaves the client's
device there is no way of nding a collision here.

63
 6.1. KNOWN ATTACKS ON PRIMITIVES

Finding an input that hashes to the auth_key_id is made signicantly

easier due to the fact that it is truncated from 160-bit to 64-bit. How-
ever, this requires a pre-image attack which is harder than a hash col-
lision and Stevens' attack is not applicable here. Furthermore, nding
this pre-image will not give the adversary any advantage unless it hap-
pens to match the 1024 bit of the secret auth_key used for key deriva-
tion.

Assuming SHA1 hashes are uniformly distributed, if the adversary tried

1024 102464
all 2 inputs he would nd 2 collisions with no way of telling
which is the right one, unless he knows a plaintext and its encryption.
This is an astronomical number of values to search through and is not
feasible to carry out in practice.

Finding a collision M0 for the truncated 128-bit msg_key of a given

encrypted message M could potentially allow an attacker to forge a
message. However, recall that the msg_key is the digest of the plain-
text. This means that the adversary, when given the hash function
and a ciphertext C , would have to be able to output a ciphertext C 0 of
which the decryption is a pre-image such that

SHA1(DecK (C)) = SHA1(DecK (C 0 ))

Telegram's FAQ [26] argues that this mitigates known attacks.

Finding a collision for the 128 bit shared secret visualization itself will
not yield anything as the attacker is not in control of the SHA1 input.
Instead, the collision has to come from the secret values chosen during
the key exchange, and as such no known collision attack will help the
adversary here. Succeeding with this however leads to a perfect man-
in-the-middle attack, as we will describe in 6.2.3.

And so we see that there is no case where nding a regular SHA1 hash colli-
sion or pre-image can fool the protocol, either the found collision will contain
too little information to be of use, or SHA1 is used in combination with an-
other method that mitigates known attacks.

However, the way SHA1 is combined with decryption is insecure. We have

already proven this with the attacks from sections 4.1.1 and 4.1.2, which
0
exactly manage to nd a collision C for ciphertext C such that

SHA1(DecK (C)) = SHA1(DecK (C 0 ))

In attempt to mitigate known theoretical attacks, the protocol has been made
vulnerable to new attacks that trivially nd collisions.

64
 6.2. KNOWN ATTACKS ON MTPROTO

6.2 Known attacks on MTProto

Several attacks on MTProto have been proposed already, primarily with the
intention of taking over a secret chat and being able to read all messages.
The simplest approach to this is by performing a man-in-the-middle attack,
that is establishing two secret chats with one unsuspecting user in each.

6.2.1 Malicious server MitM attack

An earlier version of MTProto used a modied version of the Die-Hellman
key exchange in which an extra nonce was supplied by the server during the
nal key derivation step

key (pow(gb , a) mod p) nonce

From a post on Russian blog habrahabr.ru [32], we saw that a malicious
server could perform a man-in-the-middle attack and send out two dierent
nonces so that the nal keys end up identical, as seen in gure 6.2.

A S B
g, p g, p
C B
gA g a mod p g
A
B
gS gS g s mod p gS
C B
Bnonce {0, 1}2048 Bnonce gB g b mod p
B
gSB gSb mod p
gSB gBs mod p gB gAB gSB Bnonce
C
gAB gSB Bnonce
gAS gAs mod p
gAS gSa mod p Anonce Anonce gAS gAB
C
gAB gAS Anonce

Figure 6.2: Malicious server MitM attack.

In the last step we see A compute the shared secret as gAB gAS Anonce ,
and from the way Anonce is chosen this is equivalent to

gAB  
gAS  gAB
gAS
The attack is only possible under the assumption that users will send their
public DH value to the server before it gives them the nonce. This way the

65
 6.2. KNOWN ATTACKS ON MTPROTO

server can trivially obtain the shared secret for a session, and gain access
to all sent messages. This is a very serious aw that Telegram claims to
have introduced by mistake, and although it has since been removed from
the protocol it has sparked suspicion that the authors of Telegram may have
intentionally backdoored the protocol to always have a way of accessing end-
to-end encrypted chats.

6.2.2 Naive third party MitM attack

A working man-in-the-middle attack has been demonstrated by Vico [30],
as shown in gure 6.3, carried out on an unocial Linux terminal client. It
assumes the user would use a malicious client which sends all communication
through a middle man, who ends up having full access to all messages.

A E B
ga g a mod p ga ge g e mod p ge
B B
gb g b mod p
ge gb
C C
KAE gae mod p
KAE gea mod p KEB gbe mod p KEB geb mod p

Figure 6.3: The naive MitM attack.

The attack will be detected if the users compare key ngerprints like the one
seen in gure 3.2. This can be accomplished by the malicious client used by
A receiving the key ngerprint of KEB from the middle man, and displaying
this instead of the one computed from KAE . But in this case the malicious
client might as well just forward all the decrypted messages to the middle
man, and bypass security altogether.
This attack is mitigated by users not using a client from an untrusted source,
and verifying key ngerprints as intended.

6.2.3 Undetected third party MitM attack

A second man-in-the-middle attack is outlined by Rizzo et al. [17]. Rather
than assuming that users will not compare key ngerprints, their attack
searches for ngerprint collisions such that the attack will be completely un-
detected, and shows how to manipulate the situation to have just a square-
root of the complexity for collision nding.

66
 6.2. KNOWN ATTACKS ON MTPROTO

The naive undetected approach is shown in gure 6.4. When user A ini-
tiates a secret chat with user B, and this request ga is forwarded through a
third userE , the best E can do is to send his own request ge1 to B . When B
responds with gb , B and E have agreed on a key KEB . E now has to come
up with a reply ge2 to A for which the key KAE will have the same ngerprint
128 127
as KEB . This requires 2 operations, or 2 to have a 50% probability of
nding a collision.

A E B
a
ga g mod p ga ge1 g e1
mod p ge1
B B
gb g b mod p
ge2 ge2 g e2 mod p gb
C C

KAE gea2 mod p KAE gae2 mod p KEB geb1 mod p

KEB gbe1 mod p

Figure 6.4: The naive undetected MitM attack.

The article assumes the adversary is capable of having A and B both ini-
tiate a secret chat at the same time, by means of social engineering. The
signicance of this is that now E hasn't committed to the value e1 yet, and
can freely choose both e1 and e2 , as shown in gure 6.5. This allows for
the adversary to do a birthday attack, reducing the complexity of nding an

auth_key collision to its square-root, 2128 = 264 . This needs to be done for
both e1 and e2 , and in total the cost of the attack is 264 +264 = 265 operations
to have a 50% probability of nding a collision.

We can also think of this as increasing the required security from the weaker
second pre-image resistance notion to the stronger collision resistance no-
tion, as described in section 2.4.3.

One might argue that this attack is ineective if the adversary lacks com-
puting power, as the two users will have to wait for him to nd the collision
before they can begin the conversation. Using the AntMiner S5 as we looked
at previously, this would take months. But if say the whole Bitcoin min-
ing community collaborated, this attack could be carried out mere seconds,
ignoring the cost of the Die-Hellman computations.

67
 6.2. KNOWN ATTACKS ON MTPROTO

A E B
a
ga g mod p ga gb b
gb g mod p
B C
ge1 g e1 mod p
ge1 ge2 g e2 mod p ge2
C B

KAE gea1 mod p KAE gae1 mod p KEB geb2 mod p

KEB gbe2 mod p

Figure 6.5: Having the freedom to choose e1 , e2 simultaneously, only the square root of
the number of operations is required.

68
Chapter 7
Proven crypto alternative

In this chapter we will look at another secure instant messaging application

known as TextSecure, and see which primitives it uses and how it provides
condentiality, integrity, and authenticity. We will see how this compares to
Telegram, and if Telegram could learn anything from TextSecure.

7.1 TextSecure
TextSecure (or Signal as the iOS avor is named) is a secure messaging
application for Android that uses state-of-the-art methods and makes no
compromise in security over performance. Its developer WhisperSystems is
even endorsed by Edward Snowden [10]! We will give a brief introduction to
the primitives it uses:

Curve25519 TextSecure uses Curve25519, which is an elliptic curve, for

Die-Hellman key exchange [6]. A user generates a random 256-bit secret
key and given this, Curve25519 outputs a matching 256-bit public key. Given
the secret key of one user and the public key of another Curve25519 outputs
a 256-bit secret shared by the two users. We will refer to this last step of the
elliptic curve Die-Hellman key exchange as DH().

HMAC-SHA256 HMAC is a mac function that has the form

HMAC(M ) H((K opad) || H((K ipad) || M ))

where H is any hash function with input block size n, K is a secret key padded
with zeroes to get length n, opad is a string of the byte 0x36 repeated to get
length n and ipad is the byte 0x5C repeated to get length n.

69
 7.1. TEXTSECURE

In this case the hash function used is SHA256, a variant of the successor
to SHA1. This has input block size 512 bits and output size 256 bits, and
unlike SHA1 it is not cryptographically broken. The construction is shown
in gure 7.1, the output being hash sum 2.

Figure 7.1: HMAC-SHA256 construction.

HKDF HKDF is an HMAC based key derivation function which outputs

secure keys of arbitrary length. We will treat it as a black box and not go
into more detail in this work, a thorough description can be found at the
Internet Engineering Task Force page [11].
In TextSecure the hash function used in HKDF is SHA256 and the output
size is 512 bits.

Axolotl Ratchet [16] is a Die-Hellman Ratchet, that is a DH based

protocol for generating new master keys and providing forward secrecy, which
can be done for every message sent and thus providing it on a per-message
basis. In the Axolotl Ratchet protocol used in TextSecure, each user must
maintain the following keys:

ephemeralKey: one time key included in every message, used to derive

the next rootKey.

70
 7.1. TEXTSECURE

rootKey: the shared secret master key, used together with an ephemeral
key from each user to derive new shared rootKey and chainKey.

chainKey: key used to derive one or more messageKeys.

messageKey: key used to derive encrypt/decrypt and MAC keys.

TextSecure only generates one messageKey per chainKey, and provides per-
message forward secrecy.

7.1.1 Registration
A new user registers his phone number and a username to the TextSecure
server. Along with this he generates a DH identity key pair and one or more
(ephemeral) prekey pairs using Curve25519. He sends the public half of the
identity and the prekeys to the server.

7.1.2 Key exchange

In the following section we will use the notation Aid1 for user A's public half
of his identity key, or Aid0 for the secret half. Similarly, Apk1 will refer to the
public half of one of user A's prekeys (ephemeral keys).

When one user wants to start messaging another, they perform a key ex-
change. User A wants to talk to user B . A is already registered to the server
and asks the server for B 's identity and one of his public prekeys.
The server sends A the public identity key of B , Bid1 , and one of his public
prekeys Bpk1 . A now generates a new ephemeral key pair (Apk0 , Apk1 ), and
from these keys he can compute the shared secrets rootKey and chainKey
using a triple DH:

3DH DH(Aid0 , Bpk1 ) || DH(Apk0 , Bid1 ) || DH(Apk0 , Bpk1 )

rootKey, chainKey HKDF(3DH)

Where HKDF is the key derivation function we introduced earlier, which in
this case is set to output 512 bits. The rootKey is set to the rst 256 bits of
the output, the chainKey is set to the next 256 bit.

Having computed this, A sends a message to B containing Aid1 , Apk1 , an

identier of the prekey he used from B, and nally a message of the form
described in section 7.1.4. B is now able to compute the same rootKey and
chainKey using his private identity key, the corresponding private prekey

71
 7.1. TEXTSECURE

and the values received from A.

Furthermore, both the users now have the public identity key of one an-
other and these are used to authenticate each other through an out-of-band
channel that is hard to impersonate such as a phone call, or even better in
person.

7.1.3 Key derivation

First a messageKey is derived by computing HMAC-SHA256 on input byte
0x01 and keyed with chainKey :

messageKey HMAC-SHA256(chainKey, 0x01)

messageKey is then used as input to HKDF to derive a 256-bit encryptionKey

and 256-bit macKey :

encryptionKey, macKey HKDF (messageKey, 0x0)

Whenever a message containing an ephemeral key is received, a new rootKey

and chainKey is generated as part of the Axolotl Ratchet protocol. This is
done by computing a shared secret HMAC key using the received ephemeral
key and one of the user's own, and running HKDF on the existing rootKey
as input. This outputs a new rootKey, chainKey pair.

7.1.4 Message encryption

Message payloads in TextSecure have the form:

prekey: an ephemeral public key half used to derive the next shared
rootKey .

counter: 32-bit counter increasing for every message sent under the
same ephemeralKey.

previousCounter: max value of counter sent under the sender's last

ephemeralKey.

ciphertext: message encrypted with key derived from Axolotl Ratchet,

using AES256-CTR with the high 32 bits of the nonce equal to the
counter included in the payload.

This payload is then wrapped in the following construction:

72
 7.2. CONCLUSION

version: 8 bits, high 4 bits represent current message version, low 4

bits represent client max known protocol version.

message payload: the payload that we saw above.

mac: HMAC-SHA256 of the above elds using MAC key derived from
Axolotl Ratchet, and truncated to 64 bits.

As we see, TextSecure uses the symmetric-key encryption scheme AES with

256-bit keys, just like Telegram. However, it uses AES in counter mode
which does not have the BACPA insecurity like IGE, as it is not chained.
This encryption provides condentiality and IND-CPA security.

We also see that TextSecure uses a proper message authentication code,

HMAC-SHA256. This MAC scheme is strongly unforgeable, and as it is
computed from the ciphertext it provides integrity of ciphertexts.
And so we have that TextSecure provides both IND-CPA and INT-CTXT,
and this combined means it has authenticated encryption.

7.1.5 Why is this better?

TextSecure is based on strong primitives that have withstood cryptanalysis
from the crypto community for years, and these are combined in a way that
provenly provides authenticated encryption.
Telegram on the other hand has crafted its own encryption scheme and de-
ployed it in an unproven state, and prior to any scrutiny from other cryp-
tographers. We have seen this done time and time again, and rarely with
good results. Take for example the smart grid meters that were shown to use
terrible crypto back in April this year [12].

Furthermore, the DH Ratchet is a very nice way of providing forward se-

crecy on a per-message basis with little overhead, which is an improvement
over Telegram's one key per 100 messages approach.

7.2 Conclusion
In this work we have shown that Telegram, with its use of aging primitives,
does not manage to provide data integrity of ciphertexts nor authenticated
encryption, and is vulnerable to chosen-ciphertext attacks. The attempt to
mitigate known attacks has introduced new vulnerabilities, and we suggest

73
 7.2. CONCLUSION

that the Telegram team updates its protocol to use strong, modern primi-
tives. For message authentication codes it should use a good HMAC, use a
proper key derivation function, and update the key exchange to use elliptic
curve Die-Hellman based on Curve25519. Telegram has a great emphasis
on computational performance of its protocol, which is why CTR with its
parallelization seems to be the logical choice of encryption mode. We suggest
using CTR instead of IGE mode, as IGE oers no benets over CTR.
Overall, we can conclude yet again that homegrown cryptography is a bad
approach.

74
Bibliography

[1] Android Security Engineer Alex Klyubin. Some SecureRan-

dom Thoughts.http://android-developers.blogspot.dk/2013/08/
some-securerandom-thoughts.html, 2013. [Online; accessed 28-
August-2015]. (page 35)

[2] Amazon. EC2: Previous Generation Instances. http://aws.amazon.

com/ec2/previous-generation/, 2014. [Online; accessed 28-August-
2015]. (page 62)

[3] Jean-Philippe Aumasson. BLAKE2  fast secure hashing. https:

//blake2.net/, 2012. [Online; accessed 28-August-2015]. (page 62)

[4] Gregory V Bard. Modes of encryption secure against blockwise-adaptive

chosen-plaintext attack. IACR Cryptology ePrint Archive, 2006:271,
2006. (page 17, 59)

[5] Mihir Bellare and Chanathip Namprempre. Authenticated encryp-

tion: Relations among notions and analysis of the generic composition
paradigm. In Advances in CryptologyASIACRYPT 2000, pages 531
545. Springer, 2000. (page 25, 28)

[6] D. J. Bernstein. A state-of-the-art Die-Hellman function. http://cr.

yp.to/ecdh.html. [Online; accessed 3-September-2015]. (page 69)

[7] Blockchain. Bitcoin currency statistics. https://blockchain.info/

stats, 2015. [Online; accessed 28-August-2015]. (page 63)

https://
[8] Internet Engineering Task Force. PKCS #1: RSA Encryption.
tools.ietf.org/html/rfc2313, 1998. [Online; accessed 10-September-
2015]. (page 33)

[9] Electronic Frontier Foundation. Secure Messaging Scoreboard. https:

//www.eff.org/secure-messaging-scorecard, 2015. [Online; ac-
cessed 1-September-2015]. (page 5)

75
 BIBLIOGRAPHY

[10] Max Eddy from PCMag.com. Snowden to SXSW:

Here's How To Keep The NSA Out Of Your
Stu. http://securitywatch.pcmag.com/security/
321511-snowden-to-sxsw-here-s-how-to-keep-the-nsa-out-of-your-stuff,
2014. [Online; accessed 11-September-2015]. (page 69)

[11] Internet Engineering Task Force (IETF). HMAC-based Extract-and-

Expand Key Derivation Function (HKDF). http://tools.ietf.org/
html/rfc5869, 2010. [Online; accessed 7-September-2015]. (page 70)

[12] Philipp Jovanovic and Samuel Neves. Dumb crypto in smart grids: Prac-
tical cryptanalysis of the open smart grid protocol. Cryptology ePrint
Archive, Report 2015/428, 2015. http://eprint.iacr.org/. (page 73)

[13] J. Katz and Y. Lindell. Introduction to Modern Cryptography: Princi-

ples and Protocols. Chapman & Hall/CRC Cryptography and Network
Security Series. Taylor & Francis, 2007. ISBN 9781584885511. URL
https://books.google.dk/books?id=TTtVKHdOcDoC. (page 9, 15, 19,
24, 26, 27, 28, 29)

[14] Ben Laurie. Openssl's implementation of innite garble extension. 2006.

(page 12)

[15] Kenny Paterson. Introduction: secure channels, generic composition, ba-

sic attacks. lecture from bar-ilan university, 2014. URL http://crypto.
biu.ac.il/4th-biu-winter-school. (page 13, 23)

[16] Trevor Perrin and Moxie Marlinspike. Axolotl Ratchet. https:

//github.com/trevp/axolotl/wiki, 2013. [Online; accessed 7-
September-2015]. (page 70)

[17] Juliano Rizzo and Alexander Jung-Loddenkemper. A 264 Attack On

Telegram, And Why A Super Villain Doesn't Need It To Read Your
Telegram Chats. http://bit.ly/1wQspqc, 2015. [Online; accessed 28-
August-2015]. (page 66)

[18] John J. G. Savard. A Cryptographic Compendium. http://friedo.

szm.com/krypto/JS/co0409.htm, 2000. [Online; accessed 28-August-
2015]. (page 11)

[19] Bruce Schneier. When Will We See Collisions for SHA-

1? https://www.schneier.com/blog/archives/2012/10/when_
will_we_se.html, 2012. [Online; accessed 28-August-2015]. (page 62)

76
 BIBLIOGRAPHY

[20] Statistica. Average retail electricity prices in the U.S. from

1990 to http://www.statista.com/statistics/183700/
2014.
us-average-retail-electricity-price-since-1990/, 2015. [On-
line; accessed 28-August-2015]. (page 63)

[21] Marc Stevens. New collision attacks on sha-1 based on optimal joint
local-collision analysis. In Advances in CryptologyEUROCRYPT 2013,
pages 245261. Springer, 2013. (page 62)

[22] Telegram team. Telegram Android source code. https://github.com/

DrKLO/Telegram, 2015. [Online; accessed 14-September-2015]. (page 32)
[23] TechCrunch. Telegram Says It's Hit 62M MAUs And Messag-
ing Activity Has Doubled. http://techcrunch.com/2015/05/13/
telegram-says-its-hit-62-maus-and-messaging-activity-has-doubled/,
2015. [Online; accessed 1-September-2015]. (page 5)

[24] Telegram. Secret chats, end-to-end encryption. https://core.

telegram.org/api/end-to-end, 2013. [Online; accessed 28-August-
2015]. (page 34)

[25] Telegram. Perfect Forward Secrecy. https://core.telegram.

org/api/end-to-end/pfs, 2013. [Online; accessed 28-August-2015].
(page 44)

[26] Telegram. FAQ for the Technically Inclined. https://core.telegram.

org/techfaq, 2013. [Online; accessed 28-August-2015]. (page 62, 64)

[27] Telegram. Mobile Protocol: Detailed Description. https://core.

telegram.org/mtproto/description, 2013. [Online; accessed 28-
August-2015]. (page 43, 47)

[28] Telegram. Sequence numbers in Secret Chats. https://core.

telegram.org/api/end-to-end/seq_no, 2013. [Online; accessed 28-
August-2015]. (page 40)

[29] Telegram. 10 Billion Telegrams Delivered Daily. https://telegram.

org/blog/10-billion, 2015. [Online; accessed 1-September-2015].
(page 5)

[30] Jesus Diaz Vico. Telegram: bypassing the authentication protocol. 2014.
(page 66)

77
 BIBLIOGRAPHY

[31] Bitcoin wiki. Mining hardware comparison. https://en.bitcoin.

it/wiki/Mining_hardware_comparison, 2015. [Online; accessed 28-
August-2015]. (page 63)

[32] User x7mz. Is Telegram secure? (in Russian). http://habrahabr.ru/

post/206900/, 2013. [Online; accessed 2-September-2015]. (page 65)

78