1
00:00:00,000 --> 00:00:03,600
Alright everybody, let's kick this off. Thank you for being here at Crypto and Privacy Village.

2
00:00:03,780 --> 00:00:08,820
We have a fantastic talk right now. It is security analysis of the Telegram instant

3
00:00:08,820 --> 00:00:16,140
messenger app by Tomáš Sušanka all the way from the Czech Republic. So let's give it up for

4
00:00:16,140 --> 00:00:29,140
Tomáš. Okay. Hi everyone. So yeah, my name is Tom and I will tell you something about Telegram

5
00:00:29,140 --> 00:00:36,320
in the few other minutes. First of all, let me introduce myself. I'm not really sure if the

6
00:00:36,320 --> 00:00:41,640
audience care who's presenting, but I always wanted to have a slide about me. So here you go.

7
00:00:42,660 --> 00:00:50,200
So I've recently graduated from the Czech Technical University in Prague. I've studied computer

8
00:00:50,200 --> 00:00:57,920
security and cryptography. And I'm based in Prague, Czech Republic. However, I'm doing now

9
00:00:57,920 --> 00:00:59,120
internship at Klaus.

10
00:00:59,140 --> 00:01:07,180
Cloudflare in London, UK. I would like to stress out that the results I'm presenting

11
00:01:07,180 --> 00:01:13,040
today are as part of my university studies. They are not connected to Cloudflare in any

12
00:01:13,040 --> 00:01:17,620
way. However, Cloudflare supported me in coming here. So I just would like to thank

13
00:01:17,620 --> 00:01:23,420
them for that. However, yet again, this is as part of my university studies. That's why

14
00:01:23,420 --> 00:01:25,480
the slides are ugly.

15
00:01:27,780 --> 00:01:33,440
So after a short introduction, I will tell you something about Telegram. I will tell

16
00:01:33,440 --> 00:01:39,800
you something about the Android app because that's what I've mostly focused on. And then

17
00:01:39,800 --> 00:01:44,000
we'll dive into the empty product, which is the Telegram's own cryptographic protocol.

18
00:01:44,620 --> 00:01:50,860
And then we will have a look into the actual analysis results. Yeah, I have actually two

19
00:01:50,860 --> 00:01:52,560
findings to share with you today.

20
00:01:57,780 --> 00:02:04,840
So, as mentioned, first of all, let's introduce Telegram. So Telegram was launched in August

21
00:02:04,840 --> 00:02:13,680
2013. So that's almost four years now. They have around 100 million active users, which

22
00:02:13,680 --> 00:02:18,880
a lot with a large user base in Iran, about 20 million, even though those numbers are

23
00:02:18,880 --> 00:02:25,460
from 2016. So might be higher as of today. And Telegram claims to be five, six, seven,

24
00:02:25,460 --> 00:02:25,860
ten times larger than the average user base in Iran. It's about 17,000 users. And it's

25
00:02:25,860 --> 00:02:27,660
make the latest version of their apps that could be even faster, better alternative

26
00:02:27,660 --> 00:02:34,820
to, safer alternative to other solutions, such as WhatsApp, Signal, and other. And Telegram

27
00:02:34,820 --> 00:02:40,060
has support for various clients. They are supporting pretty much everything. So that goes

28
00:02:40,060 --> 00:02:53,160
Android, IOs, even Windows Phone, desktop, web. Pretty much everything. As I've mentioned, Telegram decided not to use any known cryptographic solutions,

29
00:02:53,160 --> 00:02:57,640
but they decided to craft their own new homebrewing protocol

30
00:02:57,640 --> 00:02:59,680
which is called MT-Proto.

31
00:03:01,100 --> 00:03:04,020
I will introduce the MT-Proto just in a second

32
00:03:04,020 --> 00:03:07,180
but let me first introduce the Android app.

33
00:03:07,720 --> 00:03:10,440
So the Android app is fully open sourced

34
00:03:10,440 --> 00:03:12,640
as all the other clients are.

35
00:03:13,100 --> 00:03:14,980
Only the clients are open sourced

36
00:03:14,980 --> 00:03:17,180
so that means Android iOS and all the others

37
00:03:17,180 --> 00:03:19,960
however the server side is not open sourced.

38
00:03:21,260 --> 00:03:24,540
We focused on the version 3.13

39
00:03:24,540 --> 00:03:27,660
which was as up to date in October 2016

40
00:03:29,120 --> 00:03:31,480
and let me make a small note in here

41
00:03:31,480 --> 00:03:33,820
on the picture you can see that

42
00:03:33,820 --> 00:03:36,120
even though Telegram is open sourced

43
00:03:36,120 --> 00:03:38,680
it's not really the open source maybe we are used to.

44
00:03:39,180 --> 00:03:42,040
They pretty much just dump the whole code

45
00:03:42,040 --> 00:03:45,180
like once or twice or three times a year on GitHub

46
00:03:45,180 --> 00:03:47,860
so it's not really a structured commit.

47
00:03:48,320 --> 00:03:49,840
That goes for the Android.

48
00:03:49,960 --> 00:03:52,460
It may be better for the other clients.

49
00:03:52,700 --> 00:03:54,620
So as you can see on the picture

50
00:03:55,180 --> 00:03:57,620
this is actually a really continuous commit

51
00:03:57,620 --> 00:03:59,380
so they had a commit in October

52
00:03:59,920 --> 00:04:02,040
and then another one in March 2017

53
00:04:02,640 --> 00:04:04,720
which was really convenient for us

54
00:04:04,720 --> 00:04:06,740
because we started the analysis in October

55
00:04:06,740 --> 00:04:08,280
and we finished in February

56
00:04:08,280 --> 00:04:11,700
so we could say for the whole time that we are up to date.

57
00:04:16,340 --> 00:04:18,700
Okay, so now we're getting to have a look

58
00:04:18,700 --> 00:04:19,800
into the MT-Proto.

59
00:04:19,960 --> 00:04:22,620
So we have Alice and Bob

60
00:04:22,620 --> 00:04:24,140
and first of all what they do

61
00:04:24,140 --> 00:04:27,420
they negotiate a common master key.

62
00:04:27,540 --> 00:04:29,360
We will label it as AUF key.

63
00:04:30,180 --> 00:04:33,720
This negotiation is done using Diffie-Hellman

64
00:04:33,720 --> 00:04:36,700
so there is nothing really that spectacular

65
00:04:36,700 --> 00:04:37,960
or extraordinary.

66
00:04:38,340 --> 00:04:40,860
It's regular Diffie-Hellman as you know

67
00:04:41,330 --> 00:04:43,240
and after this key is negotiated

68
00:04:43,870 --> 00:04:47,400
each both of their sides make a fingerprint of this key

69
00:04:47,400 --> 00:04:49,940
which is I will describe how is that used in just a second.

70
00:04:49,940 --> 00:04:53,200
But, so both of those sides make AUF key ID

71
00:04:53,200 --> 00:04:55,340
which is a fingerprint of the master key.

72
00:04:59,080 --> 00:05:03,020
So now this is the whole picture of the MT-Proto protocol.

73
00:05:04,320 --> 00:05:06,960
So on the top we have a payload.

74
00:05:07,200 --> 00:05:08,800
This payload is the actual message

75
00:05:08,800 --> 00:05:10,040
contains the actual message

76
00:05:10,040 --> 00:05:11,540
so it can be high

77
00:05:12,020 --> 00:05:16,380
and it contains some other service messages

78
00:05:16,380 --> 00:05:19,100
such as message ID and so on and so on.

79
00:05:20,180 --> 00:05:23,700
So Alice has a payload, she as well has AUF key

80
00:05:23,700 --> 00:05:29,660
and let's have a look how it's done in MT-Proto.

81
00:05:29,880 --> 00:05:33,420
So the payload is first hashed via SHA-1

82
00:05:35,540 --> 00:05:38,200
and that yields message key.

83
00:05:39,320 --> 00:05:42,120
This message key is later used for the integrity check.

84
00:05:42,440 --> 00:05:46,300
The message key and the AUF key, the master secret

85
00:05:46,300 --> 00:05:49,820
then serves as an input into the key derivation

86
00:05:49,820 --> 00:05:52,700
function, this key derivation function makes a number

87
00:05:52,700 --> 00:05:56,760
of truncations, hashes and so on

88
00:05:56,760 --> 00:05:59,720
and it outputs two values

89
00:05:59,720 --> 00:06:03,300
the AS key and the AS initialization vector.

90
00:06:03,720 --> 00:06:10,780
This key and IV is then used for the actual IS encryption.

91
00:06:11,420 --> 00:06:16,260
So the payload is padded and then it's encrypted.

92
00:06:16,940 --> 00:06:19,500
Interestingly, Telegram used

93
00:06:19,820 --> 00:06:22,420
IGE block cipher mode.

94
00:06:22,900 --> 00:06:25,980
We will have a look into that just in a second.

95
00:06:26,580 --> 00:06:30,060
And then the actual data that are sent are

96
00:06:30,060 --> 00:06:31,880
you can see them at the bottom.

97
00:06:32,040 --> 00:06:34,100
That is the actually encrypted data

98
00:06:34,680 --> 00:06:36,480
before that is the message key

99
00:06:36,480 --> 00:06:37,760
which is used for the integrity

100
00:06:37,760 --> 00:06:41,480
and before that the fingerprint of the master key.

101
00:06:46,420 --> 00:06:48,240
So as I've mentioned the

102
00:06:49,820 --> 00:06:50,500
block cipher mode.

103
00:06:50,680 --> 00:06:52,420
So the block cipher mode is IGE.

104
00:06:52,660 --> 00:06:53,740
Actually I would like to know

105
00:06:53,740 --> 00:06:55,760
who of you have heard about that?

106
00:06:56,100 --> 00:06:57,180
About IGE.

107
00:06:57,400 --> 00:06:59,140
Okay, so few, four, five, six.

108
00:06:59,280 --> 00:07:00,960
Okay, who of you have heard about that

109
00:07:00,960 --> 00:07:03,060
not with the context about Telegram?

110
00:07:04,020 --> 00:07:05,080
One, okay.

111
00:07:05,240 --> 00:07:07,000
Yeah, so it was around eight

112
00:07:07,000 --> 00:07:08,660
and now then it was one.

113
00:07:08,820 --> 00:07:12,160
So that like gives the picture.

114
00:07:12,500 --> 00:07:14,140
Anyway, it's similar to CBC.

115
00:07:14,760 --> 00:07:16,700
It just has two initialization vectors.

116
00:07:16,700 --> 00:07:19,800
I wasn't unable to find

117
00:07:19,800 --> 00:07:21,900
any other applications

118
00:07:21,900 --> 00:07:23,200
that would actually use this.

119
00:07:23,360 --> 00:07:25,280
It is implemented in OpenSSL

120
00:07:25,280 --> 00:07:26,580
but as far as I know

121
00:07:26,580 --> 00:07:29,100
it's only Telegram uses that.

122
00:07:33,300 --> 00:07:35,940
Okay, so this was the first part.

123
00:07:36,840 --> 00:07:39,260
Now we will have a look at the actually

124
00:07:39,260 --> 00:07:40,780
analysis findings.

125
00:07:41,120 --> 00:07:42,720
The findings from our analysis.

126
00:07:43,080 --> 00:07:46,100
So yet again we started in October 2016.

127
00:07:46,320 --> 00:07:46,680
And this is the first part.

128
00:07:46,700 --> 00:07:48,800
And we finished about January 2017.

129
00:07:49,340 --> 00:07:50,560
And we have two findings

130
00:07:50,560 --> 00:07:52,240
that I would like to share with you.

131
00:07:53,040 --> 00:07:54,380
The first one is

132
00:07:54,380 --> 00:07:56,380
the undocumented obfuscation method.

133
00:07:56,920 --> 00:07:58,600
So when we started the analysis

134
00:07:58,600 --> 00:08:01,520
I've basically, I had an Android app

135
00:08:01,520 --> 00:08:02,540
on my testing phone.

136
00:08:02,680 --> 00:08:03,540
I've installed Telegram.

137
00:08:03,680 --> 00:08:04,920
I started to send some messages.

138
00:08:05,500 --> 00:08:07,300
And what I was expecting is

139
00:08:07,300 --> 00:08:08,600
was to see the output

140
00:08:08,600 --> 00:08:11,680
that I just described like one minute ago.

141
00:08:11,900 --> 00:08:14,580
So that means I've extracted my master key.

142
00:08:14,700 --> 00:08:15,940
I've extracted the fingerprint

143
00:08:15,940 --> 00:08:17,780
of the master key from my testing phone.

144
00:08:18,000 --> 00:08:20,380
And I just were sniffing the network

145
00:08:20,380 --> 00:08:22,320
and I was expecting to see this fingerprint.

146
00:08:23,720 --> 00:08:25,520
However, that was not the case.

147
00:08:27,240 --> 00:08:29,720
I was expecting to see this kind of structure.

148
00:08:29,920 --> 00:08:31,300
That means the fingerprint

149
00:08:31,300 --> 00:08:32,860
then some kind of message key

150
00:08:32,860 --> 00:08:33,960
then the encrypted data.

151
00:08:34,180 --> 00:08:36,280
But I was unable to find my own

152
00:08:36,280 --> 00:08:37,680
fingerprint of the key.

153
00:08:39,700 --> 00:08:42,080
We basically at the first we just

154
00:08:42,660 --> 00:08:44,340
we observed random data.

155
00:08:44,340 --> 00:08:46,340
So we were thinking that

156
00:08:46,340 --> 00:08:47,280
okay, maybe it's encrypted.

157
00:08:47,620 --> 00:08:51,100
So after another month or so of pain

158
00:08:51,100 --> 00:08:53,380
we actually found out that

159
00:08:53,380 --> 00:08:55,920
the whole empty product output

160
00:08:55,920 --> 00:08:57,740
is encrypted again.

161
00:08:58,460 --> 00:09:00,060
So they take the whole

162
00:09:00,060 --> 00:09:01,540
whole empty product output

163
00:09:02,340 --> 00:09:04,380
so that's this thing, the whole thing

164
00:09:04,380 --> 00:09:06,220
and they encrypt it again

165
00:09:06,220 --> 00:09:08,160
using AS encounter mode.

166
00:09:09,180 --> 00:09:11,140
They create the temporary key

167
00:09:11,140 --> 00:09:12,940
they create the temporary key

168
00:09:12,940 --> 00:09:14,580
and initialization vector

169
00:09:14,580 --> 00:09:16,540
and they put those values

170
00:09:16,540 --> 00:09:18,920
in front of the actually encrypted data.

171
00:09:19,340 --> 00:09:22,200
So this doesn't have to do really anything

172
00:09:22,200 --> 00:09:22,720
in security.

173
00:09:22,920 --> 00:09:24,020
It's just my log security

174
00:09:24,020 --> 00:09:25,520
through obscurity kind of thing.

175
00:09:25,740 --> 00:09:27,140
But this is what they're actually

176
00:09:27,140 --> 00:09:28,760
what the Android app is actually sending.

177
00:09:28,920 --> 00:09:31,680
Okay, so temporary key, temporary IV

178
00:09:31,680 --> 00:09:34,360
and then the actually encrypted data

179
00:09:34,360 --> 00:09:36,000
of the encrypted data because

180
00:09:36,000 --> 00:09:37,480
you know, it's the empty product output.

181
00:09:39,720 --> 00:09:41,200
So that was the first finding.

182
00:09:41,200 --> 00:09:45,180
And after that we as well wanted to have a look

183
00:09:45,180 --> 00:09:46,260
slightly into the code

184
00:09:46,920 --> 00:09:48,860
which is written in Java

185
00:09:49,560 --> 00:09:51,960
but has a significant part of logic in C.

186
00:09:54,100 --> 00:09:57,340
And one of the things that we look into today

187
00:09:57,340 --> 00:09:59,420
was how it deals with replay attack.

188
00:09:59,780 --> 00:10:02,520
So let me briefly say what replay attack is.

189
00:10:02,740 --> 00:10:05,680
So that's basically a very simple attack

190
00:10:05,680 --> 00:10:07,240
when you take some old

191
00:10:07,240 --> 00:10:08,920
when you take some valid data

192
00:10:08,920 --> 00:10:10,660
and you send them again

193
00:10:11,200 --> 00:10:11,760
at a later time.

194
00:10:13,440 --> 00:10:16,460
So the attacker does not actually know the content

195
00:10:16,940 --> 00:10:19,720
but it just takes a valid message

196
00:10:19,720 --> 00:10:20,580
sends it again

197
00:10:20,580 --> 00:10:22,420
and let's see how the message deals with that.

198
00:10:27,040 --> 00:10:29,140
So now on the slide you can see

199
00:10:30,300 --> 00:10:31,940
how Telegram deals with that.

200
00:10:32,140 --> 00:10:35,560
So they basically check if a message ID is processed

201
00:10:36,200 --> 00:10:37,900
and if it is not processed

202
00:10:37,900 --> 00:10:39,560
it processes the message.

203
00:10:41,200 --> 00:10:44,400
What is more important is the function that is below

204
00:10:45,200 --> 00:10:47,540
which is add processed message ID

205
00:10:48,200 --> 00:10:50,100
and what this function does

206
00:10:50,100 --> 00:10:55,000
that the app has an internal array

207
00:10:55,000 --> 00:10:58,300
of message IDs that it already processed.

208
00:10:58,780 --> 00:11:04,200
However, this array had the size of 300 items

209
00:11:04,200 --> 00:11:05,780
and that was it.

210
00:11:05,960 --> 00:11:08,220
So what the Android app was doing

211
00:11:08,220 --> 00:11:11,180
that when it exceeded the 300 messages

212
00:11:11,200 --> 00:11:13,460
which happens quite fast

213
00:11:14,200 --> 00:11:16,520
they actually erased the first 100

214
00:11:17,080 --> 00:11:18,220
and that's it.

215
00:11:21,140 --> 00:11:23,220
So we came up with the scenario

216
00:11:23,220 --> 00:11:24,840
where we would capture a message

217
00:11:24,840 --> 00:11:27,460
then we would wait for another 300 messages

218
00:11:27,960 --> 00:11:30,060
and then we would replace the next message

219
00:11:30,060 --> 00:11:33,420
let's say the 301st or later one

220
00:11:34,020 --> 00:11:35,320
with the previously saved.

221
00:11:35,900 --> 00:11:39,480
And so yet again we just took

222
00:11:39,480 --> 00:11:42,440
we just took a later message

223
00:11:45,560 --> 00:11:47,060
and I'm sorry

224
00:11:47,060 --> 00:11:48,640
we've captured the message

225
00:11:48,640 --> 00:11:49,840
then we waited for a while

226
00:11:49,840 --> 00:11:52,780
till the other 300 messages are sent

227
00:11:53,280 --> 00:11:55,480
and then we replaced it.

228
00:11:57,660 --> 00:12:00,300
We actually checked how Telegram

229
00:12:00,300 --> 00:12:02,860
because Telegram has like a security guidelines

230
00:12:03,280 --> 00:12:05,240
which pretty much specify

231
00:12:05,240 --> 00:12:06,460
how you should

232
00:12:06,460 --> 00:12:09,320
if you decide to develop your own Telegram

233
00:12:09,480 --> 00:12:09,640
client.

234
00:12:09,920 --> 00:12:12,100
So this security guidelines tell you

235
00:12:12,100 --> 00:12:14,860
the security guidelines tell you

236
00:12:14,860 --> 00:12:16,680
what you have to take care of

237
00:12:16,680 --> 00:12:18,640
where you should be careful and so on.

238
00:12:18,780 --> 00:12:19,720
And one of the things

239
00:12:19,720 --> 00:12:21,560
the guideline actually states is

240
00:12:21,560 --> 00:12:24,480
that if a message comes in with a message ID

241
00:12:24,480 --> 00:12:25,660
which is lower

242
00:12:25,660 --> 00:12:28,640
which is lower than all

243
00:12:28,640 --> 00:12:30,500
or equal to any of the stored values

244
00:12:30,500 --> 00:12:32,280
that message is to be discarded.

245
00:12:32,700 --> 00:12:35,920
So this is actually what the Android app was not doing.

246
00:12:36,100 --> 00:12:37,380
The Android app was only looking

247
00:12:37,380 --> 00:12:39,020
if the message ID is in the array.

248
00:12:39,480 --> 00:12:41,620
And if the message ID was not in the array

249
00:12:43,840 --> 00:12:46,080
if the message ID was not in the array

250
00:12:46,080 --> 00:12:49,080
it simply let it go through.

251
00:12:49,280 --> 00:12:50,800
However it should not be doing that.

252
00:12:50,840 --> 00:12:52,800
It should check as well with the lower value.

253
00:12:57,300 --> 00:12:59,500
So let me now say a few words

254
00:12:59,500 --> 00:13:03,280
about the Telegrams

255
00:13:03,280 --> 00:13:04,120
how Telegram responded

256
00:13:04,120 --> 00:13:06,040
because we contacted them about

257
00:13:06,640 --> 00:13:08,800
in around December 2016.

258
00:13:09,880 --> 00:13:13,000
And they didn't really say much

259
00:13:13,000 --> 00:13:14,640
about the obfuscation method.

260
00:13:14,940 --> 00:13:16,980
They just basically said

261
00:13:16,980 --> 00:13:18,900
that it has to do something with

262
00:13:19,740 --> 00:13:21,720
attempts of banning their services

263
00:13:21,720 --> 00:13:22,860
in certain countries

264
00:13:23,260 --> 00:13:25,280
and that it's not related to data security

265
00:13:25,280 --> 00:13:26,080
and they didn't really

266
00:13:26,080 --> 00:13:27,780
they pretty much sent out one sentence

267
00:13:27,780 --> 00:13:28,440
and that was it.

268
00:13:29,800 --> 00:13:31,600
However about the replay attack

269
00:13:31,600 --> 00:13:33,760
they took that pretty seriously.

270
00:13:36,400 --> 00:13:38,500
They claimed and we verified

271
00:13:38,500 --> 00:13:41,320
that you could not actually use

272
00:13:41,320 --> 00:13:43,560
this replay attack for your actual messages

273
00:13:43,560 --> 00:13:46,960
because there are some later checks

274
00:13:46,960 --> 00:13:49,080
so it was not possible to do that.

275
00:13:49,240 --> 00:13:51,680
However it affects some service messages

276
00:13:51,680 --> 00:13:55,140
for example when somebody is texting you

277
00:13:55,140 --> 00:13:56,620
and you see that the person is typing

278
00:13:56,620 --> 00:13:58,160
so for this kind of messages

279
00:13:58,160 --> 00:13:59,000
it could be used.

280
00:14:00,600 --> 00:14:02,200
Also Telegram promised

281
00:14:02,200 --> 00:14:03,640
that they're going to fix it

282
00:14:03,640 --> 00:14:04,560
in the next release.

283
00:14:07,260 --> 00:14:08,480
So Telegram promised

284
00:14:08,500 --> 00:14:12,340
that they're going to fix it

285
00:14:12,340 --> 00:14:13,620
in version 3.16

286
00:14:14,180 --> 00:14:16,860
which was out in January 2017.

287
00:14:18,520 --> 00:14:20,760
However as I mentioned earlier

288
00:14:20,760 --> 00:14:23,360
we were not able to actually verify that

289
00:14:23,360 --> 00:14:24,640
because at that time

290
00:14:24,640 --> 00:14:26,600
because the code was published

291
00:14:26,600 --> 00:14:30,880
at the end of March 2017.

292
00:14:31,300 --> 00:14:33,800
So we were not able to verify it

293
00:14:33,800 --> 00:14:35,360
for another two or three months.

294
00:14:35,520 --> 00:14:36,100
However

295
00:14:37,060 --> 00:14:37,740
now

296
00:14:38,500 --> 00:14:40,380
finally at the end of March

297
00:14:40,380 --> 00:14:41,440
they released the code

298
00:14:41,440 --> 00:14:42,260
so we can have a look.

299
00:14:42,740 --> 00:14:43,520
So yeah,

300
00:14:43,580 --> 00:14:45,020
the fix was really simple.

301
00:14:45,160 --> 00:14:46,660
They just added another value.

302
00:14:47,720 --> 00:14:50,420
They pretty much put another variable

303
00:14:50,420 --> 00:14:51,900
which is min processed message ID

304
00:14:51,900 --> 00:14:52,940
which is the minimum value

305
00:14:52,940 --> 00:14:58,880
of the lowest processed message ID.

306
00:14:59,180 --> 00:15:01,240
And then they check

307
00:15:02,540 --> 00:15:05,700
if that value that is now incoming

308
00:15:05,700 --> 00:15:07,580
if the message ID that is now incoming

309
00:15:07,580 --> 00:15:08,400
is lower.

310
00:15:08,500 --> 00:15:09,420
Then that stored value

311
00:15:09,420 --> 00:15:11,260
and if it is

312
00:15:11,260 --> 00:15:13,520
that message is already processed

313
00:15:14,340 --> 00:15:15,460
and it's discarded.

314
00:15:18,520 --> 00:15:20,340
Yeah, so we're coming to the end.

315
00:15:20,700 --> 00:15:21,920
I would like to say

316
00:15:21,920 --> 00:15:24,520
a few more words about the disclosure

317
00:15:24,520 --> 00:15:26,080
and the communication with Telegram.

318
00:15:26,300 --> 00:15:29,080
So I was somewhat criticizing

319
00:15:29,080 --> 00:15:31,200
a little bit Telegram time to time.

320
00:15:31,480 --> 00:15:33,880
I would like to say one positive thing

321
00:15:33,880 --> 00:15:35,220
that was the communication

322
00:15:35,220 --> 00:15:36,700
with the Telegram team

323
00:15:36,700 --> 00:15:38,780
was pretty professional.

324
00:15:39,300 --> 00:15:41,060
They took our remarks

325
00:15:41,580 --> 00:15:42,080
that well,

326
00:15:42,180 --> 00:15:43,960
they took the reply attack quite seriously.

327
00:15:44,160 --> 00:15:45,120
They didn't really talk about

328
00:15:45,120 --> 00:15:46,200
the obfuscation method.

329
00:15:46,480 --> 00:15:48,660
But about the attack

330
00:15:48,660 --> 00:15:49,940
they really took it seriously.

331
00:15:50,600 --> 00:15:53,220
They were answering in a reasonable timeframe

332
00:15:53,220 --> 00:15:53,940
and so on.

333
00:15:53,980 --> 00:15:54,800
They fixed it.

334
00:15:54,940 --> 00:15:58,480
So just to end on a little bit more positive note.

335
00:15:58,740 --> 00:16:00,100
And yeah,

336
00:16:00,900 --> 00:16:02,300
during the analysis

337
00:16:02,300 --> 00:16:05,280
we have written like two small tools.

338
00:16:05,280 --> 00:16:08,880
One of them is a C program

339
00:16:08,880 --> 00:16:10,420
which do obfuscate the traffic.

340
00:16:10,620 --> 00:16:11,360
So you can actually

341
00:16:11,360 --> 00:16:12,540
you can see the actual

342
00:16:13,160 --> 00:16:15,100
you can see the actual empty product

343
00:16:15,100 --> 00:16:17,120
but not just the whole obfuscation thing.

344
00:16:17,420 --> 00:16:19,940
And another thing is just a simple extractor

345
00:16:19,940 --> 00:16:21,460
that will extract the keys

346
00:16:21,460 --> 00:16:22,700
from your phone.

347
00:16:23,980 --> 00:16:25,480
Which is like helpful

348
00:16:25,480 --> 00:16:26,920
for another analysis and stuff.

349
00:16:28,120 --> 00:16:29,840
Yeah, you can as well find

350
00:16:29,840 --> 00:16:31,780
some more things on my blog

351
00:16:31,780 --> 00:16:32,880
if you would be interested

352
00:16:32,880 --> 00:16:34,420
in seeing more details.

353
00:16:35,980 --> 00:16:38,080
Yeah, and with that bombshell

354
00:16:38,080 --> 00:16:39,120
that's all, thank you.

355
00:16:48,020 --> 00:16:50,320
So I guess if there are some questions.

356
00:16:52,800 --> 00:16:54,420
So I repeat the question.

357
00:16:54,420 --> 00:16:56,500
What was wrong with the obfuscation part?

358
00:17:05,280 --> 00:17:06,100
I expected from Telegram

359
00:17:06,100 --> 00:17:08,500
some answer or some comment about it.

360
00:17:08,900 --> 00:17:10,960
Maybe they just use obfuscation.

361
00:17:11,520 --> 00:17:13,060
Yeah, yeah, like fair enough.

362
00:17:13,380 --> 00:17:13,480
Yeah.

363
00:17:24,020 --> 00:17:24,960
Yeah, one more.

364
00:17:25,220 --> 00:17:27,680
So you were talking about how

365
00:17:27,680 --> 00:17:29,360
they have this custom protocol

366
00:17:30,160 --> 00:17:30,440
that's

367
00:17:30,440 --> 00:17:30,700
.

368
00:17:36,960 --> 00:17:39,040
So there's been a lot of commentary

369
00:17:39,040 --> 00:17:40,600
about how they have this custom protocol

370
00:17:40,600 --> 00:17:42,860
that is just basically weird, right?

371
00:17:43,000 --> 00:17:44,660
It's non-standard and they just

372
00:17:44,660 --> 00:17:46,080
they haven't offered a lot of rationale

373
00:17:46,080 --> 00:17:47,400
for why they do things this way.

374
00:17:49,020 --> 00:17:51,100
After you've kind of spent some time with it

375
00:17:51,100 --> 00:17:53,340
what's your feeling about that?

376
00:17:54,340 --> 00:17:56,340
You know, is the weirdness of it

377
00:17:56,340 --> 00:17:59,240
hiding, you know, some other problems

378
00:17:59,240 --> 00:18:00,420
we haven't noticed yet, maybe?

379
00:18:00,520 --> 00:18:00,680
Yeah, I mean, I think

380
00:18:01,220 --> 00:18:01,660
Yeah.

381
00:18:04,180 --> 00:18:06,160
So I guess there are like two things.

382
00:18:06,260 --> 00:18:09,160
So one of them, like if I recommend using Telegram

383
00:18:09,160 --> 00:18:10,600
like over Signal and others

384
00:18:10,600 --> 00:18:11,900
so that answer is no.

385
00:18:12,080 --> 00:18:13,500
Like just use Signal.

386
00:18:14,180 --> 00:18:16,220
And the other thing about the protocol

387
00:18:16,220 --> 00:18:19,080
I think that's the whole problem with Telegram

388
00:18:19,080 --> 00:18:21,000
that we cannot really point to some

389
00:18:21,000 --> 00:18:23,580
like, you know, really specifics and say

390
00:18:23,580 --> 00:18:26,000
this is how we will crack it, you know,

391
00:18:26,000 --> 00:18:27,060
or this is how you will hack it.

392
00:18:27,140 --> 00:18:28,740
But like the overall like

393
00:18:29,220 --> 00:18:30,660
as you mentioned, like the overall

394
00:18:30,680 --> 00:18:32,880
like idea is that the protocol

395
00:18:32,880 --> 00:18:34,340
is just weird.

396
00:18:34,520 --> 00:18:36,440
But unfortunately, you know,

397
00:18:36,460 --> 00:18:38,480
I think you would actually have to spend

398
00:18:38,480 --> 00:18:40,580
like a year of your life to maybe

399
00:18:40,580 --> 00:18:42,860
be like, you know, able to say

400
00:18:43,360 --> 00:18:44,240
this is like

401
00:18:44,240 --> 00:18:46,580
particularly where we can like hack it.

402
00:18:46,680 --> 00:18:47,460
Actually hack it.

403
00:18:49,040 --> 00:18:50,080
I hope I

404
00:18:50,080 --> 00:18:52,460
answered that question at least a little bit.

405
00:18:56,660 --> 00:18:58,620
How big is that messenger ID

406
00:18:58,620 --> 00:18:59,940
here with like how many bits?

407
00:19:00,680 --> 00:19:00,760
...

408
00:19:04,420 --> 00:19:05,280
We've checked that.

409
00:19:05,520 --> 00:19:08,180
That should be okay, even if it overflows

410
00:19:08,180 --> 00:19:10,040
and I think it was 2 byte.

411
00:19:10,860 --> 00:19:12,640
Yeah. I'm not completely sure

412
00:19:12,640 --> 00:19:14,160
I can check later but I think it was 2 byte.

413
00:19:15,460 --> 00:19:16,940
There was one more question?

414
00:19:17,680 --> 00:19:18,100
...

415
00:19:22,480 --> 00:19:24,540
Yeah. So it's my surname.eu.

416
00:19:25,440 --> 00:19:25,860
...

417
00:19:47,300 --> 00:19:59,460
Yeah, the Telegram app has a, has a, has internally stored RSA, RSA public keys and the, the server

418
00:20:01,100 --> 00:20:08,200
then sends them, sorry, no, like the Diffie-Hellman parameters, they are like encrypted from the

419
00:20:08,200 --> 00:20:14,700
server, so the server then later sends them. I'm not exactly sure now how it, how it is, but we

420
00:20:14,700 --> 00:20:24,860
were looking into that and it was authenticated. Like, okay, so I guess that's it. Thank you for

421
00:20:24,860 --> 00:20:25,240
your attention.

422
00:20:31,300 --> 00:20:31,700
Thank you.