1
00:00:00,000 --> 00:00:13,139
<i>33C3 preroll music</i>

2
00:00:13,139 --> 00:00:17,510
Herald: Good morning everyone, thanks for
showing up in such great numbers, that's

3
00:00:17,510 --> 00:00:23,630
always a good thing
for such an early session.

4
00:00:23,630 --> 00:00:28,690
First of all I would like to ask you
a question, I mean... or

5
00:00:28,690 --> 00:00:33,590
let's start like that: Last night I had

6
00:00:33,590 --> 00:00:38,680
a weird encounter with a locked door

7
00:00:38,680 --> 00:00:45,629
out of the fate that we endured during
this week we were out of our apartment

8
00:00:45,629 --> 00:00:51,330
and the hotel owner let us stay in their
office, but the guy who stayed there

9
00:00:51,330 --> 00:00:57,290
put the dead lock on so we tried to reach
him. Hmmm, how do you reach them?

10
00:00:57,290 --> 00:01:03,350
We thought about maybe he has some
messaging, maybe he has some mobile number,

11
00:01:03,350 --> 00:01:08,880
no landline, landline, they have landline.
It turned out that the guy

12
00:01:08,880 --> 00:01:13,870
was not at the landline, out, exit, and

13
00:01:13,870 --> 00:01:17,860
so we looked around in the bar.
So this wouldn't have happened

14
00:01:17,860 --> 00:01:23,870
if he had mobile messaging, so,
to dive into that, if we could

15
00:01:23,870 --> 00:01:29,369
just text him: "Hey, we are at the hotel,
please open the door" we would have had

16
00:01:29,369 --> 00:01:34,659
one hour more sleep tonight.
So let's dive in

17
00:01:34,659 --> 00:01:41,339
with, yeah, the talk of today.

18
00:01:41,339 --> 00:01:45,580
So this morning session starts with
our speakers Roland Schilling

19
00:01:45,580 --> 00:01:48,880
and Frieder Steinmetz.

20
00:01:48,880 --> 00:01:55,580
<i>applause</i>

21
00:01:55,580 --> 00:02:00,170
And they will be talking about...
they will at first give you a gentle

22
00:02:00,170 --> 00:02:06,240
introduction into Mobile Messaging. I have
nine messaging apps on my phone, no, ten!

23
00:02:06,240 --> 00:02:10,990
The organizers forced me to
install another messaging app.

24
00:02:10,990 --> 00:02:15,080
And after that [they] give you a quick
analysis, or not so quick, I don't know,

25
00:02:15,080 --> 00:02:18,390
a deep analysis of the Threema protocol.

26
00:02:18,390 --> 00:02:22,000
So let's give another round of
applause for our speakers!

27
00:02:22,000 --> 00:02:28,730
<i>applause</i>

28
00:02:28,730 --> 00:02:33,780
Thank you, Thilo. I am Roland,
this is Frieder, and

29
00:02:33,780 --> 00:02:37,840
as, well, as Thilo already introduced
us we are going to talk about

30
00:02:37,840 --> 00:02:43,260
secure messaging. More specifically we are
trying to give a very broad introduction

31
00:02:43,260 --> 00:02:48,170
into the topic because we want to make the
field that is somewhat complex available

32
00:02:48,170 --> 00:02:53,580
to a more broad audience, so as
to leave our expert bubble

33
00:02:53,580 --> 00:02:58,390
and get the knowledge of technology
that people use every day

34
00:02:58,390 --> 00:03:03,500
to these people who are using it.
To do that we have to start

35
00:03:03,500 --> 00:03:08,720
at a very low level which might mean for
the security and crypto nerds in the room

36
00:03:08,720 --> 00:03:14,550
that you will see a lot of things that you
already know. But bear with us, please,

37
00:03:14,550 --> 00:03:20,090
since we are specifically trying, at least
with the first part of the talk, to convey

38
00:03:20,090 --> 00:03:24,790
a few of these mechanisms
that drive encrypted messaging

39
00:03:24,790 --> 00:03:29,910
to people who are new to the field.
So what we are going

40
00:03:29,910 --> 00:03:35,250
to try today is basically three
things: We are... we will try to

41
00:03:35,250 --> 00:03:40,410
outline privacy expectations when we
communicate. We are going to do that

42
00:03:40,410 --> 00:03:46,110
by sketching a communication scenario
to you guys and identifying

43
00:03:46,110 --> 00:03:49,960
what we can derive from that in
expectations. We are going to find

44
00:03:49,960 --> 00:03:54,470
an analogy, or look at an analogy that
helps us map these expectations to mobile

45
00:03:54,470 --> 00:03:59,470
messaging. And then we are going to look
at specific solutions, technical solutions

46
00:03:59,470 --> 00:04:06,760
that make it possible to make mobile
messaging as secure, and give us the same

47
00:04:06,760 --> 00:04:12,470
privacy guarantees that a one-to-one talk
would, before, in the second part of the

48
00:04:12,470 --> 00:04:17,060
talk we move on to look at a specific
implementation, and it's no secret anymore

49
00:04:17,060 --> 00:04:23,880
that we are going to look at the specific
implementation of Threema. So let's just

50
00:04:23,880 --> 00:04:29,590
dive right in.
You are at a party, a party in a house

51
00:04:29,590 --> 00:04:33,150
full of people and a friend approaches
you wanting to have a private

52
00:04:33,150 --> 00:04:38,430
conversation. Now what do you do? You
ideally would find a place at this party

53
00:04:38,430 --> 00:04:43,090
that is, well, private, and in our
scenario you find a room, maybe the

54
00:04:43,090 --> 00:04:47,600
bedroom of the host where nobody's in
there, you enter the room, you close the

55
00:04:47,600 --> 00:04:52,340
door behind you. Meaning you are now
private, you have a one-on-one,

56
00:04:52,340 --> 00:04:56,280
one-to-one session in this room in
private. And we are going to look at

57
00:04:56,280 --> 00:05:00,420
what that means.

58
00:05:00,420 --> 00:05:06,919
First of all the most, the most intuitive
one is what we call confidentiality and

59
00:05:06,919 --> 00:05:11,319
that means that since nobody is there in
the room with you you are absolutely sure

60
00:05:11,319 --> 00:05:15,509
that anything you say and anything your
communication partner says, if you imagine

61
00:05:15,509 --> 00:05:21,029
Frieder and me having this conversation,
can only be heard by the other person.

62
00:05:21,029 --> 00:05:26,300
If that is guaranteed we say… we call this
confidentiality because nobody who's

63
00:05:26,300 --> 00:05:32,270
not intended to overhear any of
the conversation will be able to.

64
00:05:32,270 --> 00:05:37,770
The second part… no, the second

65
00:05:37,770 --> 00:05:42,580
claim that we make is: if you guys
know each other, and again,

66
00:05:42,580 --> 00:05:45,909
if I had a talk with Frieder I know I've
been knowing him for a long time,

67
00:05:45,909 --> 00:05:50,619
more than five years now, I know what
his face looks like, I know his voice,

68
00:05:50,619 --> 00:05:56,199
I know that if I talk to him I actually
talk to ‘him’, meaning I know exactly

69
00:05:56,199 --> 00:06:01,009
who my communication partner is
and the same thing goes vice versa,

70
00:06:01,009 --> 00:06:06,660
so if this is achieved, if we can say
I definitely know who I'm talking to,

71
00:06:06,660 --> 00:06:11,409
there's no chance that somebody else
switches in and poses off as Frieder

72
00:06:11,409 --> 00:06:17,109
we call this ‘authenticity’.
Moving on. Integrity.

73
00:06:17,109 --> 00:06:21,840
Integrity is a bit… this is where
the analogy falls short,

74
00:06:21,840 --> 00:06:27,579
well, somewhat. But, basically, if I can
make sure that everything I say

75
00:06:27,579 --> 00:06:31,619
reaches Frieder exactly the way I wanted
to say it and there is no messenger

76
00:06:31,619 --> 00:06:36,860
in between, I'm not telling a third friend
"Please tell Frieder something" and

77
00:06:36,860 --> 00:06:43,400
he will then alter the message because
he remembered it wrong or

78
00:06:43,400 --> 00:06:49,070
has malicious intentions. If I can
make sure that everything I say

79
00:06:49,070 --> 00:06:54,190
is received by Frieder exactly the way
I said it then we have ‘integrity’

80
00:06:54,190 --> 00:06:59,479
on our communication channel.
Okay. The next ones are two ones

81
00:06:59,479 --> 00:07:04,849
that are bit hard to grasp at first.
Therefore we are going to take a few

82
00:07:04,849 --> 00:07:09,050
minutes to look at these, and they are
‘forward and future secrecy’. Suppose

83
00:07:09,050 --> 00:07:14,900
somebody entered the room while we had our
talk and that person would stay a while

84
00:07:14,900 --> 00:07:21,449
overhear some portion of our talk and
then they would leave the room again. Now

85
00:07:21,449 --> 00:07:25,059
if they, if at the
point where they entered the room they

86
00:07:25,059 --> 00:07:28,630
wouldn't learn anything about the
conversation that we had before, which is

87
00:07:28,630 --> 00:07:32,349
intuitive in this scenario which, that's
why we chose it, they enter the room, and

88
00:07:32,349 --> 00:07:36,660
everything that can overhear is only the
portion of the talk that takes place while

89
00:07:36,660 --> 00:07:41,389
they are in the room, they don't learn
anything about what we said before,

90
00:07:41,389 --> 00:07:46,610
meaning we have what we call forward
security, we'll get back to that, and

91
00:07:46,610 --> 00:07:51,190
after they left they wouldn't be able to
overhear anything, anything more that we

92
00:07:51,190 --> 00:07:56,319
say. This is what we call future security.
Because those are a bit hard to understand

93
00:07:56,319 --> 00:08:00,090
we have made a graphic here. And we are
going to get back to this graphic when we

94
00:08:00,090 --> 00:08:05,180
translate this so I'm going to take a
minute to introduce it. We have a time

95
00:08:05,180 --> 00:08:08,509
line that is blue, goes from left to
right, and on this time line we have green

96
00:08:08,509 --> 00:08:14,160
bar that denotes our secret on our secret
conversation. The first pink bar there is

97
00:08:14,160 --> 00:08:19,159
when the third person enters the room,
then our secret conversation turns orange

98
00:08:19,159 --> 00:08:23,279
because it's no longer secret, it's now
overheard by the third person and after

99
00:08:23,279 --> 00:08:29,979
they left they wouldn't know anything that
was said after that. So the left part of

100
00:08:29,979 --> 00:08:36,510
it meaning the fact that they can't hear
anything into the past is what we call

101
00:08:36,510 --> 00:08:40,299
forward security and if they can't learn
anything after they left we call it future

102
00:08:40,299 --> 00:08:48,440
secure, future secrecy, sorry. Okay, the
last one that we're going to talk about

103
00:08:48,440 --> 00:08:53,310
since we're trying to keep things simple
is deniability. Since we are only two

104
00:08:53,310 --> 00:08:57,720
people in the room and there are no
witnesses we achieve deniability because

105
00:08:57,720 --> 00:09:01,540
after we had this talk we returned to the
party and people asked us what happened,

106
00:09:01,540 --> 00:09:06,110
um, I can always point to Frieder as you
could to your friend and say he said

107
00:09:06,110 --> 00:09:10,070
something. Frieder could always say, no I
didn't, and it would be my word against

108
00:09:10,070 --> 00:09:17,130
his and if this is, you know, if our
scenario allows for this we have

109
00:09:17,130 --> 00:09:22,190
deniability because every one of us can
always deny having said or not having said

110
00:09:22,190 --> 00:09:28,209
something.
And now we are going to look at messaging.

111
00:09:28,209 --> 00:09:33,870
Now in messaging a third player comes into
the room and this could be your provider

112
00:09:33,870 --> 00:09:40,040
if we talk about text messaging like short
messages that we used to send in the 90s,

113
00:09:40,040 --> 00:09:44,000
it could be your messaging provider if you
use something more sophisticated, it could

114
00:09:44,000 --> 00:09:47,600
be WhatsApp for example could be Apple
depending on what your favorite messenger

115
00:09:47,600 --> 00:09:54,100
is but there is always, unless you use,
like, federated systems, if some some of

116
00:09:54,100 --> 00:09:59,310
you guys might think but I'm using Jabber
I know but we are looking at centralized

117
00:09:59,310 --> 00:10:03,740
systems right now and in these there will
always be one third party that all

118
00:10:03,740 --> 00:10:07,820
messages go through, whether you want it
or not. And whether you're aware of it or

119
00:10:07,820 --> 00:10:16,620
not. And this brings us to our second
analogy which is Postal Services now while

120
00:10:16,620 --> 00:10:20,431
messaging feels like you have a private
conversation with the other person and I

121
00:10:20,431 --> 00:10:23,822
think everyone can relate to that you have
your phone you see you are

122
00:10:23,822 --> 00:10:28,410
displayed with the conversation and it
looks like only you and this other person,

123
00:10:28,410 --> 00:10:32,300
in my case Frida, are having this
conversation we feel like we have a

124
00:10:32,300 --> 00:10:36,820
private conversation, while actually our
messages go through a service provider all

125
00:10:36,820 --> 00:10:42,810
the time. Meaning we are now looking
something at something more akin to postal

126
00:10:42,810 --> 00:10:49,230
services. We prepare a message send it
off, our message provider takes the

127
00:10:49,230 --> 00:10:53,170
message, takes a to our intended
recipient, and they can then read the

128
00:10:53,170 --> 00:11:00,740
message. And this is this this applies to
all the messages we exchange. And to

129
00:11:00,740 --> 00:11:04,700
underline that we're going to look at what
I initially called traditional messaging

130
00:11:04,700 --> 00:11:12,399
meaning text messaging, unencrypted SMS
messaging, and as you may or may not be

131
00:11:12,399 --> 00:11:17,029
aware of these messages also go through
our providers: more than one provider

132
00:11:17,029 --> 00:11:21,760
even. Say I'm at Vodafone and Frieder is
with Verizon, I don't know, I would send

133
00:11:21,760 --> 00:11:26,100
my messages to Vodaphone, they would
forward them to Verizon who would then

134
00:11:26,100 --> 00:11:32,089
deliver it to Frieders phone. So since
both of our providers would know all the

135
00:11:32,089 --> 00:11:36,420
messages; they are unencrypted; we would
have no confidentiality.

136
00:11:36,420 --> 00:11:41,000
They could change the messages and these
things have happened actually. So we

137
00:11:41,000 --> 00:11:44,000
don't have any integrity we don't know if
the messages received are actually the

138
00:11:44,000 --> 00:11:51,410
ones that were sent. We also have no
authentication because phone numbers are

139
00:11:51,410 --> 00:11:56,690
very weak for authenticating people, they
are managed by our providers they don't

140
00:11:56,690 --> 00:12:01,720
they are not fixed that there's no fixed
mapping to our phones or our SIM cards.

141
00:12:01,720 --> 00:12:06,459
They can be changed they can be rerouted
so we don't we never know if the messages

142
00:12:06,459 --> 00:12:10,730
we send are actually received by the
people we intended to: no authenticity and

143
00:12:10,730 --> 00:12:17,279
no authentication. Now forward secrecy and
future secrecy don't even apply because we

144
00:12:17,279 --> 00:12:24,269
have no secrecy. We do have some sort of
deniability but this goes into like

145
00:12:24,269 --> 00:12:33,370
philosophically.. Let's do that again:
philosophical claims of whether when I say

146
00:12:33,370 --> 00:12:36,850
I haven't sent anything this must have
been the provider they can technically,

147
00:12:36,850 --> 00:12:41,629
you know, guarantee they did or did not do
something. So let's not dive too deeply

148
00:12:41,629 --> 00:12:46,920
into that discussion, but we can summarize
that messaging translates, at least

149
00:12:46,920 --> 00:12:51,089
traditional messaging, translates very
badly to our privacy expectations when we

150
00:12:51,089 --> 00:13:00,430
think of a communication. Okay, moving on.
Looking at our postal analogy, actually

151
00:13:00,430 --> 00:13:05,390
our messages are more like postcards.
Because they are plain, our providers can

152
00:13:05,390 --> 00:13:09,600
look at them, can change them, you know
all the things we've just described: just

153
00:13:09,600 --> 00:13:14,440
as they would a postcard. They can see the
intended recipient, they can look at the

154
00:13:14,440 --> 00:13:18,690
sender, they can look at the tags, change
it: postcards. And what we want to achieve

155
00:13:18,690 --> 00:13:25,230
now is find a way to wrap these postcards
and make them more like letters, assuming

156
00:13:25,230 --> 00:13:29,819
that postal services don't open letters.
That's the one the one point with this

157
00:13:29,819 --> 00:13:35,960
analogy that we have to like, define. And
to be able to do that we're going to we're

158
00:13:35,960 --> 00:13:41,220
trying to give you the shortest encryption
to – the shortest introduction to

159
00:13:41,220 --> 00:13:46,790
encryption, see I'm confusing myself here,
that you will ever get. Starting with

160
00:13:46,790 --> 00:13:50,209
symmetric encryption.
Now, encryption, for those of you who

161
00:13:50,209 --> 00:13:55,500
don't know, is what we call the
translation of plain, readable text into

162
00:13:55,500 --> 00:14:00,459
text that looks like it's random, but it
can be reversed and turned back into plain

163
00:14:00,459 --> 00:14:05,690
text provided we have the right key for
that. So to stick with a very simple

164
00:14:05,690 --> 00:14:09,400
example please imagine this box that we've
just labeled crypto, and we are not

165
00:14:09,400 --> 00:14:13,839
concerned with what's in the box we just
imagine it as a machine. Please imagine it

166
00:14:13,839 --> 00:14:18,069
as a machine that takes two inputs the
plaintext and the key, and it produces

167
00:14:18,069 --> 00:14:21,959
something that we call ciphertext.
The ciphertext is undistinguishable from

168
00:14:21,959 --> 00:14:29,949
random text, but it can be reversed at the
recipient side using the same key and

169
00:14:29,949 --> 00:14:35,019
basically the same machine just doing the
operation, you know, in reverse: turning

170
00:14:35,019 --> 00:14:42,290
the ciphertext back into plain text. This
is what we call, sorry, this is what we

171
00:14:42,290 --> 00:14:48,079
call symmetric encryption because if you
imagine a line where the cipher text is

172
00:14:48,079 --> 00:14:52,959
you could basically mirror the thing on to
the other side so it's symmetric at that

173
00:14:52,959 --> 00:14:59,560
at that line. And when when there's
something that is called symmetric there

174
00:14:59,560 --> 00:15:03,350
is also something that is called
asymmetric and asymmetric encryption works

175
00:15:03,350 --> 00:15:08,630
relatively the same way, only there are
now two keys. We have made them a yellow

176
00:15:08,630 --> 00:15:13,709
one and a blue one. These keys are called
a key pair. They are mathematically

177
00:15:13,709 --> 00:15:19,300
linked. And the way this works now is that
anything encrypted with one of these keys

178
00:15:19,300 --> 00:15:26,649
can only be decrypted with the other one.
You can do it both ways, but the important

179
00:15:26,649 --> 00:15:31,950
thing to memorize here is just anything I
encrypt with the yellow key can only be

180
00:15:31,950 --> 00:15:42,370
decrypted with the blue key. Okay, since
we have that now, let's capitalize on this

181
00:15:42,370 --> 00:15:48,230
on this scenario. Imagine each of our
communication partners now has one of

182
00:15:48,230 --> 00:15:51,350
these two keys and we are still talking
about the same key pair that we've

183
00:15:51,350 --> 00:15:56,160
outlined on the previous slide. Now we
call one of them a secret key and one of

184
00:15:56,160 --> 00:16:03,950
them a public key. This is probably known
to most of you: traditional public key

185
00:16:03,950 --> 00:16:06,860
cryptography.
We've added something that is called an

186
00:16:06,860 --> 00:16:09,180
identity in this in this picture: we will
get back

187
00:16:09,180 --> 00:16:13,870
to that in a minute. But the scenario we
want we want you to envision right now is

188
00:16:13,870 --> 00:16:19,959
that both parties would publish their
public key to the public. And we are going

189
00:16:19,959 --> 00:16:24,829
to get back to what that means as well.
And keep their secret key, as the name

190
00:16:24,829 --> 00:16:29,790
says, secret. Some of you might know this
as a private key: it's the same the same

191
00:16:29,790 --> 00:16:38,670
concept applies. We just chose to call it
secret key. Because it more clearly

192
00:16:38,670 --> 00:16:44,110
denotes that it's actually secret and not
never published. So this would mean any

193
00:16:44,110 --> 00:16:48,550
message that would that would be encrypted
with one of the parties public key could

194
00:16:48,550 --> 00:16:54,100
then only be decrypted with that parties
secret key, putting us in a position where

195
00:16:54,100 --> 00:16:59,060
I could take Frieta's public key, encrypt
my message, send it to him, and I would

196
00:16:59,060 --> 00:17:04,689
know that he would be the only one able to
decrypt the message - as long as his

197
00:17:04,689 --> 00:17:13,080
secret key remains his, well, secret.
And he doesn't doesn't publish it. Well

198
00:17:13,080 --> 00:17:22,050
the problem is: it's a very expensive
scenario. We get something akin to a

199
00:17:22,050 --> 00:17:27,970
postal to a postal service where we can
now encrypt the message and envision it

200
00:17:27,970 --> 00:17:32,890
like putting a plain sheet of paper into
an envelope, seal it, we would put it on

201
00:17:32,890 --> 00:17:38,260
the way. Nobody on the line would be able
to look into the letter. They would of

202
00:17:38,260 --> 00:17:41,350
course, well, since there are addresses on
there, they would see who it is from and

203
00:17:41,350 --> 00:17:48,220
who it to - but they couldn't look inside
the letter: this is achieved. But as I've

204
00:17:48,220 --> 00:17:52,470
already said it's a very expensive
mechanism and by that we mean it is hard

205
00:17:52,470 --> 00:17:59,370
to do for devices - especially since you
are doing mobile messaging on your phones,

206
00:17:59,370 --> 00:18:07,610
ideally, especially hard to do on on small
devices like phones. So while if we had a

207
00:18:07,610 --> 00:18:15,320
mechanism that would allow us to combine
symmetric and asymmetric encryption. And

208
00:18:15,320 --> 00:18:20,990
it turns out we do. And we are going to
keep this very simple by just looking at

209
00:18:20,990 --> 00:18:26,650
what is called key establishment, and then
again also just one particular way of key

210
00:18:26,650 --> 00:18:33,160
establishment. We have two new boxes here:
they are called key generators. And the

211
00:18:33,160 --> 00:18:34,160
scheme
that we are

212
00:18:34,160 --> 00:18:36,860
looking at right now works works the
following way: You can take one of the

213
00:18:36,860 --> 00:18:41,890
secret keys, and another part and another
public key, like the one of the other

214
00:18:41,890 --> 00:18:45,580
party, put them into the key generator.
And remember, these keys are

215
00:18:45,580 --> 00:18:50,710
mathematically linked each secret key
belongs to exactly one public key. And the

216
00:18:50,710 --> 00:18:54,150
way this key generator works is that
through this mathematical this

217
00:18:54,150 --> 00:18:59,380
mathematical linking it doesn't matter if
you take, in this case, let's call them

218
00:18:59,380 --> 00:19:04,390
Alice and Bob: if you take Alice's secret
key and Bob public key, or Bob secret key

219
00:19:04,390 --> 00:19:09,780
and Alice's public key, you will always
come up with the same key. And we call

220
00:19:09,780 --> 00:19:13,830
this a shared key. Because this key can
now be it can be generated independently

221
00:19:13,830 --> 00:19:18,130
on both sides and it can then be used for
symmetric encryption, and as we've already

222
00:19:18,130 --> 00:19:26,300
told you symmetric encryption is a lot
cheaper than asymmetric encryption. So

223
00:19:26,300 --> 00:19:29,900
this has one advantage and one
disadvantage: the advantages I've already

224
00:19:29,900 --> 00:19:36,370
said is that it's way cheaper, and the
fact, well, the advantage is also that we

225
00:19:36,370 --> 00:19:39,900
come up with the key on both sides, and
the disadvantage is that we come up with

226
00:19:39,900 --> 00:19:47,090
one key on both sides - because whether or
not you've realized this by now since this

227
00:19:47,090 --> 00:19:51,580
is a very static scheme we always come up
with the same key. That is going to be a

228
00:19:51,580 --> 00:19:57,880
problem in a minute. So let's recap we
have looked at asymmetric encryption which

229
00:19:57,880 --> 00:20:02,429
as I've said gives us IDs, and we're going
to look at what means. But it is very

230
00:20:02,429 --> 00:20:06,400
expensive. We know that symmetric
encryption is cheap, but we have to find a

231
00:20:06,400 --> 00:20:12,309
way to get this key delivered to both
parties before they can even start

232
00:20:12,309 --> 00:20:16,839
encrypting their communication. And we
have looked at key establishment, which

233
00:20:16,839 --> 00:20:23,920
allows us which gives us symmetric keys
based on asymmetric key pairs. Meaning we

234
00:20:23,920 --> 00:20:28,350
have now basically achieved
confidentiality - we can use these keys

235
00:20:28,350 --> 00:20:32,029
put them in the machines with our
plaintext, get ciphertext, can, you know,

236
00:20:32,029 --> 00:20:37,030
we are able to transport it to the other
side. Nobody can look inside.

237
00:20:37,030 --> 00:20:42,670
Confidentiality is achieved.
Now deniability. Deniability in this

238
00:20:42,670 --> 00:20:47,510
scenario would basically mean, if you
think back at our initial sketch, where we

239
00:20:47,510 --> 00:20:51,250
could say I haven't said that, and the
other guy couldn't prove that we did,

240
00:20:51,250 --> 00:20:56,649
would in this case be a letter that was
sent to both of the participants, and it

241
00:20:56,649 --> 00:21:01,250
would be from either of the participants.
So that when looking at this

242
00:21:01,250 --> 00:21:05,200
cryptographically, we couldn't say this
was sent by me or this was sent by Frieda.

243
00:21:05,200 --> 00:21:10,429
You could just see it was sent by, well,
either of us. And if you think of the

244
00:21:10,429 --> 00:21:13,980
scheme that we've just sketched, since
both parties come up with the same key by

245
00:21:13,980 --> 00:21:20,010
using different by using a different set
of keys to to generate them, basically the

246
00:21:20,010 --> 00:21:25,320
same key can be generated on both sides.
And you can never really say, by just

247
00:21:25,320 --> 00:21:29,649
looking at a message, if it was encrypted
with a shared key generated on one or on

248
00:21:29,649 --> 00:21:35,940
the other side since they are the same.
So, very simply and on a very high level

249
00:21:35,940 --> 00:21:41,500
we have now achieved deniability. What
about forward and future secrecy? You

250
00:21:41,500 --> 00:21:45,330
remember this picture? Our overheard
conversation on the party that we were at

251
00:21:45,330 --> 00:21:52,740
at the beginning of the talk? Well, this
picture now changes to this. And what we

252
00:21:52,740 --> 00:21:58,200
are looking at now is something we call
key compromise and key renegotiation. Key

253
00:21:58,200 --> 00:22:03,669
compromise would be the scenario where one
of our keys were lost. And we are talking

254
00:22:03,669 --> 00:22:08,470
about the shared key that we generated
now. Which, if it would fall into the

255
00:22:08,470 --> 00:22:13,059
hands of an attacker, this attacker would
be able to decrypt our messages because

256
00:22:13,059 --> 00:22:23,140
it's the same key that we used for that.
Now, if if if at the point where the key

257
00:22:23,140 --> 00:22:28,000
was compromised they wouldn't be able to
decrypt anything prior to that point - we

258
00:22:28,000 --> 00:22:33,020
would have forward secrecy. And if we had
a way to renegotiate keys, and they would

259
00:22:33,020 --> 00:22:38,240
be different ,completely different, not
linked to the ones we had before, and then

260
00:22:38,240 --> 00:22:42,820
use that in the future, we would have
future secrecy. But we don't, since as

261
00:22:42,820 --> 00:22:48,279
we've already said the keys that we
generate are always the same. And we want

262
00:22:48,279 --> 00:22:51,210
you to keep this in mind because
we will get

263
00:22:51,210 --> 00:22:54,120
back to this
when we look at Threema in more detail.

264
00:22:58,573 --> 00:23:07,320
yeah, if we had a way to dump keys after
having used them, we could achieve forward

265
00:23:07,320 --> 00:23:13,669
and future secrecy. Since we don't, we
can't right now. Okay, next recap our key

266
00:23:13,669 --> 00:23:17,180
establishment protocol gives us
confidentiality, deniability, and

267
00:23:17,180 --> 00:23:23,159
authenticity. We don't have forward and
future secrecy. And if you've stuck with

268
00:23:23,159 --> 00:23:27,750
us you would realize we are omitting
integrity here - that is because we don't

269
00:23:27,750 --> 00:23:32,419
want to introduce a new concept right now
but we will get back to that, and you will

270
00:23:32,419 --> 00:23:39,279
see that when we look at Threema it
actually does have integrity. Now,

271
00:23:39,279 --> 00:23:43,419
basically you could think we fixed all
the-- well, we fixed everything, but you

272
00:23:43,419 --> 00:23:47,779
heard us talk about things like IDs, and
we said we haven't really lost a few words

273
00:23:47,779 --> 00:23:53,310
about them lost many words about them and
we're going to look at that now. And we

274
00:23:53,310 --> 00:23:56,590
are going to start with a quote by my very
own professor - don't worry you don't have

275
00:23:56,590 --> 00:24:01,159
to read that, I'm going to do it for you.
My professor says, "cryptography is

276
00:24:01,159 --> 00:24:04,950
rarely, if ever, the solution to a
security problem. Cryptography is a

277
00:24:04,950 --> 00:24:09,360
translation mechanism, usually converting
a communications security problem into a

278
00:24:09,360 --> 00:24:15,770
key management problem." And if you think
of it, this is exactly what we have now,

279
00:24:15,770 --> 00:24:19,970
because I know that Frieder has a private
key, a secret key I'm sorry, and a public

280
00:24:19,970 --> 00:24:24,890
key. He knows that I have a secret key and
a public key. How does I know which one of

281
00:24:24,890 --> 00:24:29,940
those public keys that are in the open is
actually his? How would I communicate to

282
00:24:29,940 --> 00:24:36,820
him what my public key is? Those of you
who've used PGP for example and then the

283
00:24:36,820 --> 00:24:42,040
couple in the last couple of decades know
what I'm talking about. And we have the

284
00:24:42,040 --> 00:24:46,240
same problem everywhere where public key
cryptography is used, so we also have the

285
00:24:46,240 --> 00:24:52,700
same problem in mobile messaging. To the
rescue comes our messaging server -

286
00:24:52,700 --> 00:24:57,030
because, since we have a central instance
inbetween us, we can now query this

287
00:24:57,030 --> 00:25:02,490
instance: I can now tell my public key; I
can now take my public key and my identity,

288
00:25:02,490 --> 00:25:04,440
tell the messaging server, "
Hey messaging server - this is my

289
00:25:04,440 --> 00:25:07,490
identity. Please store it for me." So that
Frieda, who has

290
00:25:07,490 --> 00:25:13,860
some well some kind of information to
identify me can then query, you, get my

291
00:25:13,860 --> 00:25:19,409
public key back. This of course assumes
that we trust the message messaging

292
00:25:19,409 --> 00:25:25,730
server. We may or may not do that. But for
now we have a way to at least communicate

293
00:25:25,730 --> 00:25:31,870
our our public keys to other parties. Now
what can we use as identities here? In

294
00:25:31,870 --> 00:25:37,029
our, like, now a figure here it's very
simple: Alice just goes to the messaging

295
00:25:37,029 --> 00:25:40,809
server and says, "Hey, what's the public
key for Bob?" And the messaging server

296
00:25:40,809 --> 00:25:45,840
magically knows who Bob is, and what his
public key is. And the same thing where I

297
00:25:45,840 --> 00:25:52,289
work works the other way. What would; the
question now is what is a good ID in this

298
00:25:52,289 --> 00:25:57,380
scenario. Remember we are on phones, so we
could think of using phone numbers, we

299
00:25:57,380 --> 00:26:02,000
could think of using email addresses, we
could think of something else. And

300
00:26:02,000 --> 00:26:06,830
something else will be the interesting
part, but let's look at the other parts

301
00:26:06,830 --> 00:26:10,559
one by one.
Phone numbers can identify users - you

302
00:26:10,559 --> 00:26:14,130
remember that you rely on your providers
for the mapping between phone numbers and

303
00:26:14,130 --> 00:26:19,210
SIM cards, so you have to trust another
instance in this situation. We're going to

304
00:26:19,210 --> 00:26:23,049
ignore that completely because we find
that phone numbers are personal

305
00:26:23,049 --> 00:26:27,711
information, and I for one my phone
number. And I mean the same phone number

306
00:26:27,711 --> 00:26:32,269
I've had it for like 18 years now. I
wouldn't want that to get into the wrong

307
00:26:32,269 --> 00:26:39,960
hands. And by using it to identify me as a
person, or, you know, my cryptographic

308
00:26:39,960 --> 00:26:45,429
identity that is bound to my to my keys: I
wouldn't necessarily want to use that,

309
00:26:45,429 --> 00:26:49,499
because I wouldn't be able to change it or
I would want to change it if it ever got

310
00:26:49,499 --> 00:26:54,640
compromised. Now something else comes to
mind: e-mail addresses. E-mail addresses

311
00:26:54,640 --> 00:27:00,740
basically are also personal information.
They are a bit shorter lived, as we would

312
00:27:00,740 --> 00:27:05,120
argue, than phone numbers. But, and you
can use temporary e-mails, you can do a

313
00:27:05,120 --> 00:27:09,730
lot more you are way more flexible with
e-mails. But ideally we want to have

314
00:27:09,730 --> 00:27:14,830
something that is that we call dedicated
IDs, meanings something that identifies me

315
00:27:14,830 --> 00:27:18,229
only within the bounds of the service that
we use.

316
00:27:18,229 --> 00:27:24,450
So that's what we want to have we are
going to show you how this might work but

317
00:27:24,450 --> 00:27:30,480
we still have to find a way to verify
ownership, because this is a scenario that

318
00:27:30,480 --> 00:27:36,030
is more or less likely to happen. I am
presented with a number of public keys to

319
00:27:36,030 --> 00:27:41,760
an identity that I know - and I have to
verify a way to, well, I have to find a

320
00:27:41,760 --> 00:27:46,049
way to verify which one is maybe the right
one, maybe the one that is actually used,

321
00:27:46,049 --> 00:27:51,429
maybe Frieda has used quite a number of
public keys - he's a lazy guy. He forgets

322
00:27:51,429 --> 00:27:55,100
to, you know, take his keys from one
machine to the other: he just, you know,

323
00:27:55,100 --> 00:27:59,210
buys a new laptop sets up a new public
key: bam, he has two - which one am I

324
00:27:59,210 --> 00:28:04,299
supposed to read to use right now. Now
remember that we are looking at the

325
00:28:04,299 --> 00:28:10,159
messenger server for, you know, key
brokerage, and we are now going to add a

326
00:28:10,159 --> 00:28:18,929
third line here and that is this one.
Basically we introduce a way to meet in

327
00:28:18,929 --> 00:28:23,860
person, and again PGP veterans will know
what I'm talking about, and verify our

328
00:28:23,860 --> 00:28:28,580
keys independently. We've chosen QR codes
here - free mail uses QR codes, many other

329
00:28:28,580 --> 00:28:33,440
messengers and do as well, and we want to
like tell you why this is an important

330
00:28:33,440 --> 00:28:39,520
feature to be able to to verify our public
keys independently of the messaging

331
00:28:39,520 --> 00:28:43,620
server. Because once we did that we no
longer have to trust the messaging server

332
00:28:43,620 --> 00:28:47,790
to tell us or - we don't have longer we no
longer have to trust his promise that this

333
00:28:47,790 --> 00:28:54,150
is actually the key we are looking for. We
have verified that independently. Okay, we

334
00:28:54,150 --> 00:29:00,050
have basically solved our authenticity
problem. We know that we can identify

335
00:29:00,050 --> 00:29:04,269
users by phone numbers and emails, and you
remember our queries to the server for

336
00:29:04,269 --> 00:29:08,100
Bob: we can still use phone numbers for
that if we want to. We can use emails for

337
00:29:08,100 --> 00:29:12,789
that if we want to. We don't have to. We can
use our ids anonymously. But we have a way

338
00:29:12,789 --> 00:29:18,190
to verify them independently. The
remaining problem is users changing their

339
00:29:18,190 --> 00:29:24,179
IDs - that is where we have to verify
again. And we also get back to that later,

340
00:29:24,179 --> 00:29:27,800
but I want to look at something else
first, and that is the handling of

341
00:29:27,800 --> 00:29:31,320
metadata.
Now, we know that an attacker can no

342
00:29:31,320 --> 00:29:36,210
longer look inside our messages. They can,
however, still see the addressee, who the

343
00:29:36,210 --> 00:29:39,540
message is from, and they can see how
large the message is, they can see they

344
00:29:39,540 --> 00:29:44,649
can look at timestamps and stuff like
that. And since we are getting a bit tight

345
00:29:44,649 --> 00:29:50,899
on the clock I'm going to try to
accelerate this a bit. Metadata handling:

346
00:29:50,899 --> 00:29:56,440
we want to conceal now who a message is
from, who a message is to. And we are

347
00:29:56,440 --> 00:30:01,050
doing this by taking the envelope that
we've just generated, wrapping it into a

348
00:30:01,050 --> 00:30:05,480
third envelope, and then sending that to
the messenger server first. And the

349
00:30:05,480 --> 00:30:12,169
messenger server gets a lot of envelopes.
They are all just addressed to the

350
00:30:12,169 --> 00:30:15,950
messenger server, so anyone on the network
would basically see there's there's one

351
00:30:15,950 --> 00:30:19,699
party sending a lot of messages to the
messenger server; maybe there are a lot of

352
00:30:19,699 --> 00:30:24,590
parties. But they couldn't look at they
couldn't look at the end-to-end, we call a

353
00:30:24,590 --> 00:30:29,819
channel, that's seeing what the address is
on each internal envelope are. The

354
00:30:29,819 --> 00:30:35,690
messaging server, however, can. They would
open the other-- the outer envelope, look

355
00:30:35,690 --> 00:30:40,559
at the inside, see , "Okay this is a
message directed at Alice," wrap it into

356
00:30:40,559 --> 00:30:43,880
another envelope - that would just say,
"This is the message from the messaging

357
00:30:43,880 --> 00:30:50,320
server and it is directed to Alice." Who
would then be able to, you know, open the

358
00:30:50,320 --> 00:30:54,230
outer envelope, open the inner envelope,
see this is actually a message from Bob.

359
00:30:54,230 --> 00:30:59,559
And what we have thereby achieved is a to
where two layer end to end communication

360
00:30:59,559 --> 00:31:06,230
tunnel as we call it, where the purple and
the blue bar are encrypted channels

361
00:31:06,230 --> 00:31:13,150
between both communication partners and
the messaging server, and they carry an

362
00:31:13,150 --> 00:31:18,560
encrypted tunnel between both partners,
you know, both communication partners,

363
00:31:18,560 --> 00:31:24,860
directly. But, and we've had this caveat
before, the messaging server still knows

364
00:31:24,860 --> 00:31:29,080
both communication partners, they still
know the times that the messages were

365
00:31:29,080 --> 00:31:33,940
sent. And they also know the size of the
message. But we can do something against

366
00:31:33,940 --> 00:31:39,269
that. And we what we do is introduce
padding - meaning,

367
00:31:39,269 --> 00:31:42,169
in the inner envelope we
just stick a bunch of extra

368
00:31:42,169 --> 00:31:47,270
pages so the envelope looks a bit thicker.
And we do that by just appending random

369
00:31:47,270 --> 00:31:51,790
information to the actual message before
we encrypt it. So anything looking at the

370
00:31:51,790 --> 00:31:56,479
encrypted message would just see a large
message. And, of course, that should be

371
00:31:56,479 --> 00:31:59,940
random information every time - it should
have should never have the same length

372
00:31:59,940 --> 00:32:05,730
twice. But if we can achieve that, we can
at least conceal the size of the message.

373
00:32:05,730 --> 00:32:12,639
Now so much for our gentle introduction to
mobile messaging. And for those those of

374
00:32:12,639 --> 00:32:19,210
you stuck around, we are now moving on to
analyze Threema. Now I want to say a few

375
00:32:19,210 --> 00:32:24,289
things before we do that - we are not
affiliated with Threema, we don't, we are

376
00:32:24,289 --> 00:32:30,529
not here to recommend that the the app to
you or the service. We didn't do any kind

377
00:32:30,529 --> 00:32:35,380
of formal analysis. There will be no
guarantees. We will not be quoted with

378
00:32:35,380 --> 00:32:41,509
saying, "use it or don't use it." What we
want to do is make more people aware of

379
00:32:41,509 --> 00:32:48,070
the mechanisms that are in use and we have
chosen basically a random message provider

380
00:32:48,070 --> 00:32:52,370
- we could have chosen anyone. We chose
Threema for the fact that they do offer

381
00:32:52,370 --> 00:32:57,190
dedicated IDs. That they don't bind keys
to phone numbers, which many messengers

382
00:32:57,190 --> 00:33:04,240
do. Those of you who use WhatsApp know
what I'm talking about. And well, since it

383
00:33:04,240 --> 00:33:08,710
is closed source we found it interesting
to look at what is actually happening inside

384
00:33:08,710 --> 00:33:13,700
the app and make that publicly aware. Now
we are not the only ones we've done this,

385
00:33:13,700 --> 00:33:18,770
we are also not the first ones who've done
this, and we don't claim we are. But we

386
00:33:18,770 --> 00:33:24,049
are here now and we want to try to make
you aware of the inner workings of the app

387
00:33:24,049 --> 00:33:33,490
as far as we have understood it. And with
that I hand the presenter over to Frieda.

388
00:33:33,490 --> 00:33:42,670
<i>Applause</i>

389
00:33:42,670 --> 00:33:45,530
Frieda: So I'll be presenting to you our

390
00:33:45,530 --> 00:33:52,460
understanding of the Threema protocol and
how the application works as we deduced

391
00:33:52,460 --> 00:33:59,260
from mostly reverse engineering the
Android app. And so this won't be a

392
00:33:59,260 --> 00:34:03,539
complete picture, but it will it will be a
picture presenting to you the most

393
00:34:03,539 --> 00:34:09,380
essential features and how the protocol
works. And I'll start by giving you a

394
00:34:09,380 --> 00:34:16,909
bird's eye look at the overall
architecture and why Roland was giving you

395
00:34:16,909 --> 00:34:21,419
this abstract introduction to mobile
messaging, there was also always this

396
00:34:21,419 --> 00:34:26,719
third party - this messaging provider.
And this now became actually three

397
00:34:26,719 --> 00:34:34,220
entities because Threema has three
different servers, mostly, doing well,

398
00:34:34,220 --> 00:34:41,230
very different stuff for for the apps
working. And I'll start with the directory

399
00:34:41,230 --> 00:34:48,840
server in orange at the bottom, because
that is the server you most likely will be

400
00:34:48,840 --> 00:34:55,149
contacted contacting first if you want to
engage in any conversation with someone

401
00:34:55,149 --> 00:34:59,770
you never talked to before. Because this
is the server that handles all the

402
00:34:59,770 --> 00:35:05,850
identity public key related stuff that
Roland was talking about so much. This is

403
00:35:05,850 --> 00:35:12,089
the server you'll be querying for whose
public key - I have this Threema ID,

404
00:35:12,089 --> 00:35:17,050
what's the corresponding public key, for
example stuff like that. Above that there

405
00:35:17,050 --> 00:35:23,410
is the messaging server, which is kind of
the core central entity in this this whole

406
00:35:23,410 --> 00:35:30,140
scenario because it's task is relaying
messages from one communication partner to

407
00:35:30,140 --> 00:35:34,989
another. And above that we have the media
server, and I'll be talking about that

408
00:35:34,989 --> 00:35:42,670
later. In short, its its task, its
purpose, is storing large media files like

409
00:35:42,670 --> 00:35:49,190
images and videos you send to your
communication partners. But as I said I

410
00:35:49,190 --> 00:35:54,319
want to start with the directory server,
and in the case of Threema, this directory

411
00:35:54,319 --> 00:36:01,650
server is offers a REST API so
communication with this server happens

412
00:36:01,650 --> 00:36:12,260
via HTTP. It is HTTPS actually so it's
TLS encrypted. And this encryption is also

413
00:36:12,260 --> 00:36:18,550
fulfills all the requirements you would
have to to to a proper TLS connection and,

414
00:36:18,550 --> 00:36:21,990
so, if you if you want to communicate with
the new person and you have

415
00:36:21,990 --> 00:36:22,990
their phone
number or

416
00:36:22,990 --> 00:36:27,460
the email address or Threema ID. You'll be
asking your app will be asking the

417
00:36:27,460 --> 00:36:30,609
directory server, "Hey, I have this phone
number, do you have a corresponding

418
00:36:30,609 --> 00:36:37,380
Threema account and public key." And the
response will hopefully be, "Yes, I do -

419
00:36:37,380 --> 00:36:41,090
that's a public key that's the Threema ID:
go ahead."

420
00:36:41,090 --> 00:36:51,420
And as Ron said we kind of chose Threema
for the arbitrary use of IDs and

421
00:36:51,420 --> 00:36:57,210
especially for the system of verifying
fingerprints in person by scanning QR

422
00:36:57,210 --> 00:37:06,339
codes and because this is something
Threema has and other messengers do not

423
00:37:06,339 --> 00:37:12,400
have I want to talk a little bit about
that, because if you just ask the

424
00:37:12,400 --> 00:37:17,050
directory server "hey I have a threema ID
what is the corresponding public key?" the

425
00:37:17,050 --> 00:37:20,980
threema location will say "ok I got an
answer from from the directory server I

426
00:37:20,980 --> 00:37:25,660
have a public key but I have very little
trust, that you actually know who the real

427
00:37:25,660 --> 00:37:29,480
person behind this threema account is,
we're not quite sure about that", so it'll

428
00:37:29,480 --> 00:37:37,230
mark this contact with one red dot and if
you had a phone number or an email address

429
00:37:37,230 --> 00:37:40,840
and asked the directory server, "hey
what's the corresponding threema account

430
00:37:40,840 --> 00:37:46,240
and public key?" the app will say, "ok we
still have to trust the directory server,

431
00:37:46,240 --> 00:37:51,640
but we're a little bit more confident that
the person on the other hand is actually

432
00:37:51,640 --> 00:37:55,109
who you think they are because you have a
phone number probably linked to a real

433
00:37:55,109 --> 00:37:59,810
person and you have a better idea who
you're talking to but still we rely on the

434
00:37:59,810 --> 00:38:06,640
threema server", so it'll knock a contact
like that with two orange dots and then

435
00:38:06,640 --> 00:38:11,230
there is the final stage if you met
someone in person and scan their, their

436
00:38:11,230 --> 00:38:17,390
public key and threema ID in form of a QR
code such a contact will be marked with

437
00:38:17,390 --> 00:38:23,470
three green dots and in that case the app
says "We're 100% confident we're talking

438
00:38:23,470 --> 00:38:29,589
to the person we want to talk to and we
have the proper keys." So right now we're

439
00:38:29,589 --> 00:38:35,600
at if we think of engaging a conversation,
we were at the point where we do have all

440
00:38:35,600 --> 00:38:41,410
necessary details to start encrypting our
communication, but question remains, how

441
00:38:41,410 --> 00:38:46,260
do we encrypt our communication,
in case of threema.

442
00:38:46,260 --> 00:38:52,260
Threema uses a library called salt has
been developed by Daniel Bernstein and he

443
00:38:52,260 --> 00:38:59,730
called it salt but it's spelled NaCl so
I'm sorry for for the play on words, but

444
00:38:59,730 --> 00:39:07,240
if you see NaCl its salt so this is a
library specifically designed for the

445
00:39:07,240 --> 00:39:12,440
encryption of
messages and it's supposed to be very

446
00:39:12,440 --> 00:39:20,560
simple in use and give us all the the
necessary features we wanted and this is

447
00:39:20,560 --> 00:39:25,020
Salt's authenticated encryption giving us
all the features Roland was talking about

448
00:39:25,020 --> 00:39:29,930
in abstract before. It gives us integrity,
it gives us authenticity, it gives us

449
00:39:29,930 --> 00:39:39,800
confidentiality and just a quick look and
on how this this library would be used is,

450
00:39:39,800 --> 00:39:44,619
as you can see up there like everything in
the grey box is, what the library does and

451
00:39:44,619 --> 00:39:49,800
we only need our secret key, if we want to
encrypt something to someone, the

452
00:39:49,800 --> 00:39:58,520
recipients public key, our message. So far
very obvious and the library also requires

453
00:39:58,520 --> 00:40:04,960
a nonce, which is something that should be
only used once, that's actually yeah part

454
00:40:04,960 --> 00:40:08,670
of the definition, so we generate
something random and include that in the

455
00:40:08,670 --> 00:40:13,099
process of encrypting the message this is
just so that if we encrypt the same

456
00:40:13,099 --> 00:40:19,030
content same message twice, we do not get
the same ciphertext. This is not nothing

457
00:40:19,030 --> 00:40:23,090
secret because as you can see at the
output the library actually gives us

458
00:40:23,090 --> 00:40:27,770
ciphertext, Roland talked a bit about that
what it is and it'll also give you it was

459
00:40:27,770 --> 00:40:32,690
a MAC and I'll just stick with a very
simple definition of what that is, it is

460
00:40:32,690 --> 00:40:38,069
something that ensures that there's kind
of a checksum so someone getting looking

461
00:40:38,069 --> 00:40:43,359
at the cipher text and the MAC can ensure
no one tampered with the cipher text so

462
00:40:43,359 --> 00:40:50,280
the cipher text is still in the state when
it was, when we sent it and if we want to

463
00:40:50,280 --> 00:40:54,859
transmit our message now in encrypted form
to someone, we have to include the nonce,

464
00:40:54,859 --> 00:40:58,060
the nonce is not secret, we can just send
it along with the cipher text, but to

465
00:40:58,060 --> 00:41:04,690
decrypt we need the nonce and well so this
is what we might use for encryption, but

466
00:41:04,690 --> 00:41:07,420
as you might remember from Roland's
introduction, this scheme

467
00:41:07,420 --> 00:41:17,460
does not offer us any forward or future
secrecy and we can still try to to add

468
00:41:17,460 --> 00:41:24,410
some form of forward to future secrecy to
this scheme and this is usually done,

469
00:41:24,410 --> 00:41:29,790
sorry for skipping with a, with something
something called a handshake and

470
00:41:29,790 --> 00:41:36,250
handshakes are a system of discarding old
keys and agreeing agreeing a new keys,

471
00:41:36,250 --> 00:41:42,960
this is usually what we do with the
handshake and scenarios like this and

472
00:41:42,960 --> 00:41:48,309
doing a handshake with someone that is not
online at the moment is pretty difficult

473
00:41:48,309 --> 00:41:52,559
there are protocols to do that; the signal
messaging for app, app for example does

474
00:41:52,559 --> 00:41:57,340
something like that but it's kind of
complicated and threema's protocol spares

475
00:41:57,340 --> 00:42:02,140
the effort and only does this kind of
handshake with the Threema servers because

476
00:42:02,140 --> 00:42:07,150
they are always online, we can always do a
handshake with them, so Threema has some

477
00:42:07,150 --> 00:42:13,160
form of forward secrecy on this connection
to the messaging server and how this is

478
00:42:13,160 --> 00:42:19,589
achieved, I'll try to present to you right
now and we walk through this handshake

479
00:42:19,589 --> 00:42:27,559
step by step and I try to put some focus
on what every step tries to achieve, so if

480
00:42:27,559 --> 00:42:31,319
we initiate a connection, if we start
sending a message the threema app will

481
00:42:31,319 --> 00:42:35,270
connect to the to the messaging server and
start the connection by sending a client

482
00:42:35,270 --> 00:42:43,109
hello, this is a very simple packet. It is
only there to communicate the public key

483
00:42:43,109 --> 00:42:48,190
we from now on intend to use
and a nonce prefix in this case

484
00:42:48,190 --> 00:42:54,140
notice it is I'd say half a nonce and the
other part is some some kind of a counter

485
00:42:54,140 --> 00:43:01,819
that will during the ongoing communication
always be increased by one. So but it'll

486
00:43:01,819 --> 00:43:08,140
do no harm if you just see it as a nonce
right now, so we start the conversation by

487
00:43:08,140 --> 00:43:12,740
saying "hey, we want to use a new key pair
from now on and this is our public key,

488
00:43:12,740 --> 00:43:17,410
please take note" and the server will
react by saying "okay, I need a fresh key

489
00:43:17,410 --> 00:43:23,859
pair as well then", generate a fresh key
pair and let us know what it's public key

490
00:43:23,859 --> 00:43:33,260
from now on is. The only thing to note is,
I mean as you can see there is, there's

491
00:43:33,260 --> 00:43:38,589
not much more than then the things
the client sent

492
00:43:38,589 --> 00:43:42,689
corresponding things from the server side,
but there's also the client nonce

493
00:43:42,689 --> 00:43:47,920
included, so so as we can we can see this
is actually a response to our client hello

494
00:43:47,920 --> 00:43:54,020
we just sent, not something that got, I
don't know redirected to us on accident,

495
00:43:54,020 --> 00:44:00,180
whatever. And as you can see the latter
part of the message including the server's

496
00:44:00,180 --> 00:44:06,339
public key is encrypted that's what what
this bracket saying ciphertext says and it

497
00:44:06,339 --> 00:44:13,089
is encrypted with the server's long-term
secret key and our ephemeral temporary key

498
00:44:13,089 --> 00:44:18,490
and by doing so, the server does something
only the person in possession of the

499
00:44:18,490 --> 00:44:23,280
service long-term secret key can do and
proves to us, this public key we just

500
00:44:23,280 --> 00:44:27,869
received from the server, in this server
"hello", has actually been been sent by

501
00:44:27,869 --> 00:44:31,940
the proper threema server, no one can
impersonate the threema server at that

502
00:44:31,940 --> 00:44:42,430
point, so, after that we are at a point
where the client application knows, this

503
00:44:42,430 --> 00:44:45,830
is the public key threema server wants to
use and it's actually the threema server,

504
00:44:45,830 --> 00:44:49,880
not someone impersonating it, the server
know was there is someone who wants to

505
00:44:49,880 --> 00:44:54,599
talk to me using this public key, but
knows nothing else it doesn't know who's

506
00:44:54,599 --> 00:44:59,220
actually talking to him and this is going
to change with the next packet, because

507
00:44:59,220 --> 00:45:05,700
the threema app is going to, to now send a
client authentication packet, we call it

508
00:45:05,700 --> 00:45:10,940
that way, which includes information about
the client, the first thing is the threema

509
00:45:10,940 --> 00:45:17,730
ID , the threema IDs are eight character
strings, it's just uppercase letters and

510
00:45:17,730 --> 00:45:24,520
numbers and what follows is a user agent
string which is not technically necessary

511
00:45:24,520 --> 00:45:28,820
for the protocol, it's something the
threema app sends, it includes the threema

512
00:45:28,820 --> 00:45:34,640
version, your system; Android iOS and
your, in case of Android, the Android

513
00:45:34,640 --> 00:45:41,960
version and stuff like that so it's very
similar to user agent in web browsers,

514
00:45:41,960 --> 00:45:49,560
yeah. I don't know why they sent it, but
they do and the rest of it is nonces.

515
00:45:49,560 --> 00:45:54,040
Let's get skip over them, but also the
client's ephemeral public key we already

516
00:45:54,040 --> 00:45:58,160
sent in the client hello but this time
encrypted

517
00:45:58,160 --> 00:46:01,859
with our long-term secret key, so we just
repeat what the server just did, proving

518
00:46:01,859 --> 00:46:06,400
by encrypting with our long-term key,
proving that we are, who we claim to be

519
00:46:06,400 --> 00:46:12,170
and that we vouch that we really want to
use this, this temporal key and after that

520
00:46:12,170 --> 00:46:17,050
happens each party knows, what public key
what new keypair the other party wants to

521
00:46:17,050 --> 00:46:23,420
use from now on and that the other party
is actually who they claim to be and so

522
00:46:23,420 --> 00:46:25,910
the handshake is just concluded
by the server

523
00:46:25,910 --> 00:46:29,880
sending a bunch of zeros and grouped
encrypted with the newly exchanged key

524
00:46:29,880 --> 00:46:34,800
pairs. This is just so the client can
decrypt it, see it as a bunch of zeros,

525
00:46:34,800 --> 00:46:40,990
everything worked out, we have a working
connection now so if we've done that we

526
00:46:40,990 --> 00:46:46,930
have this, we have, if you remember this
picture, we have established forward

527
00:46:46,930 --> 00:46:51,700
secrecy in the paths between the app and
the server we do not have established

528
00:46:51,700 --> 00:46:55,839
anything for the inner crypto layer, which
is in case of threema, just taking

529
00:46:55,839 --> 00:46:59,619
messages encrypting them with the salt
library and sending them over the wire.

530
00:46:59,619 --> 00:47:04,550
There's nothing more to it, it's just as I
showed you the scheme before, used in a

531
00:47:04,550 --> 00:47:11,650
very simple way so we now have channels
established and we can communicate via

532
00:47:11,650 --> 00:47:17,579
those and the next step I want to look at,
what we are actually sending via this

533
00:47:17,579 --> 00:47:24,069
channels and so I'm introducing the
threema packet format and this is the

534
00:47:24,069 --> 00:47:28,950
format packets do have, that your
application sends to the threema service,

535
00:47:28,950 --> 00:47:36,190
this is what if what the threema server
sees, in this case it is the form a packet

536
00:47:36,190 --> 00:47:42,540
has if it's something I want to send to a
communication partner, for example, the

537
00:47:42,540 --> 00:47:45,710
content could be a text message
I want to send to someone.

538
00:47:45,710 --> 00:47:50,250
There are different looking messages for,
for management purposes, for exchanges

539
00:47:50,250 --> 00:47:55,240
with the server, that will never be
relayed to someone else, but this is the

540
00:47:55,240 --> 00:48:01,250
the most basic format we use when sending
images, text to, to communication parts

541
00:48:01,250 --> 00:48:06,780
and as you can see there's a packet type,
its purpose is kind of obvious and what

542
00:48:06,780 --> 00:48:12,180
follows is the fields on the envelope as
Roland introduced, it's saying "this is a

543
00:48:12,180 --> 00:48:17,140
message from me"
from Alice to Bob and so you recall the

544
00:48:17,140 --> 00:48:21,390
server can see that, what follows is a
message ID this is just a random ID

545
00:48:21,390 --> 00:48:27,630
generated when sending a message, follows
a timestamp so the server knows this is a

546
00:48:27,630 --> 00:48:33,340
recent message that has been stuck in
transit for a long time, whatever.

547
00:48:33,340 --> 00:48:38,750
What follows is some things to threema
specific, threema does have public

548
00:48:38,750 --> 00:48:45,440
nicknames, it's just an alias for, for
your account you can set that in the app

549
00:48:45,440 --> 00:48:50,491
and if you do it actually gets transmitted
with every message you send, so if you

550
00:48:50,491 --> 00:48:56,230
change it, your name will change at your
communication partners phone with the

551
00:48:56,230 --> 00:49:04,569
first message you sent to them and what
follows is a nonce and that is the nonce

552
00:49:04,569 --> 00:49:08,960
used to encrypt the cypher text as
follows, the cypher text you see down

553
00:49:08,960 --> 00:49:14,990
below is the inner envelope, as in
Roland's earlier pictures and we're now

554
00:49:14,990 --> 00:49:22,340
going to look at what is in this envelope,
how do the messages look we transmitted to

555
00:49:22,340 --> 00:49:28,610
our end-to-end communication partners and
the most simple thing we could look at is

556
00:49:28,610 --> 00:49:35,670
a text message and you can see grayed out
above, still all the stuff from the outer

557
00:49:35,670 --> 00:49:41,140
envelope and down below it's very simple,
we have a message type it's just one byte

558
00:49:41,140 --> 00:49:46,619
indicating in this case that it is a text
message and what follows is text.

559
00:49:46,619 --> 00:49:55,400
It's nothing more, it's just plain plain
text and after that, noteworthy maybe is

560
00:49:55,400 --> 00:50:01,200
padding and this padding is as you can see
in the most inner encryption layer so the

561
00:50:01,200 --> 00:50:06,300
threema server does not know how big your
your actual messages are, this is kind of

562
00:50:06,300 --> 00:50:10,630
useful because there's stuff like typing
notifications you send to your

563
00:50:10,630 --> 00:50:18,619
communication partners, which are always
the same size and to make this, to hide

564
00:50:18,619 --> 00:50:24,030
this from the threema servers, we have
this padding in the inner crypto layer.

565
00:50:24,030 --> 00:50:32,819
Next I want to look at a other message
type, like I'd say the most, yeah, I think

566
00:50:32,819 --> 00:50:37,550
one of the basic message types most people
use with instant messaging app is image

567
00:50:37,550 --> 00:50:42,200
messages, I want to send someone an image,
this is something we do regularly and this

568
00:50:42,200 --> 00:50:48,712
looks a little bit weird in the first on
the first look; because it has a message

569
00:50:48,712 --> 00:50:53,389
type, we know that, we know what what it's
burst with the purposes follows a blob

570
00:50:53,389 --> 00:50:59,740
ID, what a blob ID is, I'm going to
explain in a minute. Follows the size is

571
00:50:59,740 --> 00:51:04,380
very basic, it's just the size of the image
just should be transmitted and what

572
00:51:04,380 --> 00:51:10,200
follows is a key and the mandatory
padding, so, the questions are, what is

573
00:51:10,200 --> 00:51:16,370
this blob ID what is the key ID and what
is this key and this is where the media

574
00:51:16,370 --> 00:51:22,610
server comes into the picture. The media
server is, well I'll show you what happens

575
00:51:22,610 --> 00:51:28,350
if you send an image message. Your app
will take the image you want to send,

576
00:51:28,350 --> 00:51:34,950
generate a random key, encrypt this image
with this key and send it to the media

577
00:51:34,950 --> 00:51:38,760
server and the media server will say "okay
I'll store this under the following blob

578
00:51:38,760 --> 00:51:44,339
ID" and your app takes note of this blob
ID and then, we'll send this kind of image

579
00:51:44,339 --> 00:51:48,830
message I just showed to you to the
messaging server via the messaging server

580
00:51:48,830 --> 00:51:53,919
to your communication partner, your
communication partner opens up the message

581
00:51:53,919 --> 00:51:59,010
looks at it sees a blob ID sees the key
and goes to the media server and says "hey

582
00:51:59,010 --> 00:52:04,010
do you have a blob ID, something stored
under this blob ID?" and the media server

583
00:52:04,010 --> 00:52:09,540
will respond "yes I do, here's the encrypted
stuff" and your communication partner

584
00:52:09,540 --> 00:52:16,210
can take this encrypted stuff, decrypt it
with the key you sent and look at your image.

585
00:52:16,210 --> 00:52:22,190
This is how image sending works. So right
now we do have the basic the basics of

586
00:52:22,190 --> 00:52:26,250
modern instant messaging, we can send
text, we can send images, this is the

587
00:52:26,250 --> 00:52:35,059
simple stuff and what I want to look at
next is something that most people would

588
00:52:35,059 --> 00:52:41,150
want a modern messenger to have as well
and that is group conversations.

589
00:52:41,150 --> 00:52:46,440
Group conversations essentially in threema
do work not very different from other from

590
00:52:46,440 --> 00:52:54,079
other method messages because if you send
something to a group your app will just

591
00:52:54,079 --> 00:52:57,790
encrypt the message several times for
every communication partner involved and

592
00:52:57,790 --> 00:53:02,849
send it to them, but your communication
partners need to know, well this is a

593
00:53:02,849 --> 00:53:08,809
group message and it belongs to this and
that group and to do so threema has group

594
00:53:08,809 --> 00:53:15,780
packets and they include exactly that
information, they include a creator ID

595
00:53:15,780 --> 00:53:21,670
which is the threema ID of the person who
created the group and a group ID which is

596
00:53:21,670 --> 00:53:28,059
something randomly generated when creating
a group and after that folIows a regular

597
00:53:28,059 --> 00:53:32,790
packet format; in this case a text message,
if it were an image message you would see

598
00:53:32,790 --> 00:53:37,840
exactly the same stuff as shown in the
Image message before so this is how group

599
00:53:37,840 --> 00:53:43,070
messages look, but we need a way to
introduce new groups to change names and

600
00:53:43,070 --> 00:53:51,330
for that there are special packets and
this for example is a group "set members

601
00:53:51,330 --> 00:53:55,069
message", which tells everybody there is
this new group and it has the following

602
00:53:55,069 --> 00:54:00,590
members as you can see here there is
only a group ID, there is no longer a

603
00:54:00,590 --> 00:54:03,880
group creator ID included and that is
because a threema group management

604
00:54:03,880 --> 00:54:10,500
is very static, there can only be one person
managing a group and that is the person

605
00:54:10,500 --> 00:54:14,830
who created the group. So only the person
who created the group can send this kind

606
00:54:14,830 --> 00:54:20,670
of messages, saying there is a new member
in the group for example and therefore the

607
00:54:20,670 --> 00:54:27,810
group creator is implicit in this case, it
is the sender of the message, so this is

608
00:54:27,810 --> 00:54:33,260
kind of annoying because you cannot have
a group where everybody can have members for

609
00:54:33,260 --> 00:54:39,710
example and stuff like that. Just if you
set a name for a group, the message looks

610
00:54:39,710 --> 00:54:47,710
very similar it just doesn't include a
member list, but a name field. So, what I


611
00:54:47,710 --> 00:54:52,180
want to talk about next is something that
happens above all the stuff I talked

612
00:54:52,180 --> 00:54:57,070
about right now, because now I show you
there are different kinds of packets doing

613
00:54:57,070 --> 00:55:01,069
all that stuff, there there are lots of
more packages for all your messages for

614
00:55:01,069 --> 00:55:07,030
example they look very similar to the
image messages, because they just I mean

615
00:55:07,030 --> 00:55:11,340
we have a blob ID for the audio file and
stuff like that but what is kind of

616
00:55:11,340 --> 00:55:17,760
interesting I thought, we thought, is that
above this layer of packet formats,

617
00:55:17,760 --> 00:55:24,091
there's, there's also some additional stuff
happening and a good example for that is

618
00:55:24,091 --> 00:55:30,420
how Threema handles subtitles for images,
you can I think a lot of modern messengers

619
00:55:30,420 --> 00:55:35,810
support that at some some kind of text to
an image and Threema doesn't have a packet

620
00:55:35,810 --> 00:55:42,429
format of a field in some kind of image
message for that, but they just embed the

621
00:55:42,429 --> 00:55:47,630
subtitle of the image, in the actual image
and the acts of data of the image and send

622
00:55:47,630 --> 00:55:54,920
it along. This has the advantage of being
compatible with Threema versions not aware

623
00:55:54,920 --> 00:55:58,690
of this feature, because they can just
happily ignore this exif data, you won't

624
00:55:58,690 --> 00:56:03,680
see the subtitle but it won't break
anything. It is though kind of wonky because

625
00:56:03,680 --> 00:56:07,839
it's not actually a feature which is not
reflected in the actual packet format and

626
00:56:07,839 --> 00:56:13,070
this is also very similar happening with
quotes, you can quote other people in

627
00:56:13,070 --> 00:56:17,540
Threema you can like, mark your message
and say I want to quote that and in the

628
00:56:17,540 --> 00:56:23,339
app it looks like like some kind of fixed
feature, yeah, you have this message you

629
00:56:23,339 --> 00:56:28,559
quoted, included in your new message and
it looks like like it's somehow linked to

630
00:56:28,559 --> 00:56:36,050
the old message, but in reality it's just
a text message, including some markdown,

631
00:56:36,050 --> 00:56:42,349
which if you're Threema version supports
this this kind of stuff, is rendered

632
00:56:42,349 --> 00:56:46,809
nicely as is shown below, but if your
version doesn't support it, you'll just

633
00:56:46,809 --> 00:56:50,990
see the plain text.
So again, being compatible with versions

634
00:56:50,990 --> 00:57:01,039
that don't have it introduces some, yeah,
weird layer. And with that, I'll stop

635
00:57:01,039 --> 00:57:07,680
showing you all the features Threema has.
There's certainly more to talk about, but

636
00:57:07,680 --> 00:57:16,550
I think you should have an idea how how it
works in basic terms. What it does; all

637
00:57:16,550 --> 00:57:21,880
the other stuff is kind of similar to what
I showed you and differs in

638
00:57:21,880 --> 00:57:27,619
particularities which aren't so important
I think and I'll just hand over to Roland

639
00:57:27,619 --> 00:57:34,089
who'll be wrapping up our talk and say
something about the results of our reverse

640
00:57:34,089 --> 00:57:36,294
engineering.

641
00:57:36,294 --> 00:57:45,440
<i>Applause</i>

642
00:57:45,440 --> 00:57:50,300
Roland: Okay, we told you we reversed the
app and we told you we weren't the first

643
00:57:50,300 --> 00:57:58,980
ones and this is all true. But we came
here to tell you guys or to make you guys

644
00:57:58,980 --> 00:58:04,839
aware of things you can expect from
messaging apps, and we hope that by using

645
00:58:04,839 --> 00:58:10,369
Threema as an example we have we have
shown you how you can relate your own

646
00:58:10,369 --> 00:58:14,109
privacy expectations to different apps and
we also hope we gave you enough

647
00:58:14,109 --> 00:58:20,559
terminology and explanation to that so you
can make a more more competent decision

648
00:58:20,559 --> 00:58:28,480
next time you look at a messenger and look
at what its promises are. Since we

649
00:58:28,480 --> 00:58:33,880
reversed it anyway and we did a lot of
coding to do that what we did is put it in

650
00:58:33,880 --> 00:58:39,960
a library. Now, I don't know how many of
you guys know the term academic code

651
00:58:39,960 --> 00:58:45,970
<i>Laughter</i>
We are of course we are of course I'm

652
00:58:45,970 --> 00:58:50,709
working at a university, so we've been
doing this on and off for for quite some

653
00:58:50,709 --> 00:58:55,320
time. We started roughly two years ago,
did it for a couple of days then left it

654
00:58:55,320 --> 00:59:00,569
lying around. Eventually we had the whole
thing lying in a drawer for about a year

655
00:59:00,569 --> 00:59:05,859
before we decided to finish it so we we
didn't we never actually put a lot of

656
00:59:05,859 --> 00:59:09,790
effort into the code. We are not
proficient programmers. But we still

657
00:59:09,790 --> 00:59:15,130
wanted to we still wanted to publish what
we did with the hopes that a small

658
00:59:15,130 --> 00:59:21,980
community might form around this, maybe
extend it, help us you know fix the few

659
00:59:21,980 --> 00:59:25,849
things that we didn't do so well, help us
document it - you don't have to take

660
00:59:25,849 --> 00:59:32,910
photographs by the way will will upload
the slides. So these repositories they

661
00:59:32,910 --> 00:59:38,230
exist we push to them we made a GitHub
organization that we push to them

662
00:59:38,230 --> 00:59:43,289
yesterday. If you wanted to look if you
wanted to start coding right away, say if

663
00:59:43,289 --> 00:59:47,209
you wanted to write a bot, we'd recommend
you wait a few weeks say two to three

664
00:59:47,209 --> 00:59:51,830
because we still want it like, fix a few
of the kinks in there. Everyone else we

665
00:59:51,830 --> 00:59:56,579
hope will just look at it, maybe this will
help your understanding of what actually

666
00:59:56,579 --> 01:00:04,260
does. And also the activists in us hope
that this might get the people at Threema

667
01:00:04,260 --> 01:00:08,329
to open-source their code because no
matter what we tell you here, and no

668
01:00:08,329 --> 01:00:11,690
matter what they tell you how their their
app actually works - and this is always

669
01:00:11,690 --> 01:00:15,950
true for non open-source software, there
will never be true transparency: you will

670
01:00:15,950 --> 01:00:20,010
never be able to prove that what runs on
your phone is actually implemented the

671
01:00:20,010 --> 01:00:25,531
same way we've shown you. With our library
you would have these guarantees, you can

672
01:00:25,531 --> 01:00:30,430
actually you can definitely use it to
write bots if you ever wanted to do that.

673
01:00:30,430 --> 01:00:34,549
Or if you just want to understand how it
works please go ahead and dive right into

674
01:00:34,549 --> 01:00:43,780
there. Well, with that said, we thank you
for your attention.

675
01:00:43,780 --> 01:00:58,990
<i>Applause</i>
Herald: Okay, thank you very much, Roland,

676
01:00:58,990 --> 01:01:06,220
Frieder, we only have time for one
question, so who has a super eager

677
01:01:06,220 --> 01:01:11,540
question - the signal angel is signalling.
Signal Angel: There's a couple of

678
01:01:11,540 --> 01:01:16,930
questions, but I will pick the best one.
The best one was from alien: could you use

679
01:01:16,930 --> 01:01:22,690
captions to inject malicious Exif data
into the images?

680
01:01:22,690 --> 01:01:29,880
Frieder: What is malicious Exif data?
Signal Angel: Well some data that probably

681
01:01:29,880 --> 01:01:37,420
the image passing library.
Frieder: What we did not do was have

682
01:01:37,420 --> 01:01:42,750
looked very particular at security
problems in the implementation of Threema.

683
01:01:42,750 --> 01:01:48,099
I could, like, and I would say this falls
into this department: there's also a

684
01:01:48,099 --> 01:01:52,280
library handling the gif display meant and
stuff like that. We could have looked at

685
01:01:52,280 --> 01:01:57,140
is this broken, maybe. We did not. We
looked at the protocol from a higher level

686
01:01:57,140 --> 01:02:01,029
and, so I cannot say anything about it.
Signal Angel: Okay and another question

687
01:02:01,029 --> 01:02:07,570
was when an non-group originating user
sends the group update message, what

688
01:02:07,570 --> 01:02:13,529
happens?
Frieder: The thing is, Threema group IDs

689
01:02:13,529 --> 01:02:19,839
aren't globally unique. A Threema group ID
only refers to a particular group together

690
01:02:19,839 --> 01:02:26,569
with the group creator's ID. So if you
send an update group message from your

691
01:02:26,569 --> 01:02:31,029
account, the app would look for a
different group than you intended. Because

692
01:02:31,029 --> 01:02:36,930
your group ID would say I'm I'm trying to
update a group created by me with this and

693
01:02:36,930 --> 01:02:43,930
that ID. So it won't be the group
you want to hijack.

694
01:02:43,930 --> 01:02:47,163
Herald: Okay, very well. Another round
of applause for our speakers!

695
01:02:47,163 --> 01:02:56,571
<i>applause</i>

696
01:02:56,571 --> 01:03:12,741
<i>postroll music</i>

697
01:03:12,741 --> 01:03:19,741
<i>Subtitles created by c3subtitles.de
in the year 2018</i>