1
00:00:01,280 --> 00:00:12,559
[Music]

2
00:00:15,440 --> 00:00:17,199
when i was planning on doing a talk here

3
00:00:17,199 --> 00:00:18,480
i was trying to figure out what kind of

4
00:00:18,480 --> 00:00:20,720
angle to to attack it from

5
00:00:20,720 --> 00:00:22,720
and um normally we talk about these

6
00:00:22,720 --> 00:00:24,320
holistic things with what we are doing

7
00:00:24,320 --> 00:00:25,279
in tor

8
00:00:25,279 --> 00:00:27,199
but i looked at the content that we had

9
00:00:27,199 --> 00:00:28,960
been doing over the the past few years

10
00:00:28,960 --> 00:00:30,560
also with corona and we haven't been out

11
00:00:30,560 --> 00:00:32,558
talking much about what we're doing so

12
00:00:32,558 --> 00:00:34,320
the focus in this presentation is going

13
00:00:34,320 --> 00:00:35,200
to be

14
00:00:35,200 --> 00:00:37,440
uh specifically on the torn network and

15
00:00:37,440 --> 00:00:39,520
the tools that we're using to like

16
00:00:39,520 --> 00:00:41,680
operate and experiment with the network

17
00:00:41,680 --> 00:00:42,640
um

18
00:00:42,640 --> 00:00:45,440
we won't be talking much about like the

19
00:00:45,440 --> 00:00:47,039
anti-censorship technology that we're

20
00:00:47,039 --> 00:00:49,760
also doing the tour browser localization

21
00:00:49,760 --> 00:00:51,440
efforts metrics all these kind of things

22
00:00:51,440 --> 00:00:52,960
so it's going to be a little bit on the

23
00:00:52,960 --> 00:00:55,039
on the back end kind of thing of the of

24
00:00:55,039 --> 00:00:57,280
the network

25
00:00:57,280 --> 00:00:59,359
so my name is alex i've been involved

26
00:00:59,359 --> 00:01:02,960
with the tor project since 2017

27
00:01:02,960 --> 00:01:05,040
and i've been leading the network team

28
00:01:05,040 --> 00:01:06,479
since 19.

29
00:01:06,479 --> 00:01:08,080
we're the team responsible for writing

30
00:01:08,080 --> 00:01:10,240
the software that is called tor like the

31
00:01:10,240 --> 00:01:12,640
binary you get if you apt install tor

32
00:01:12,640 --> 00:01:14,560
and it's also the binary that comes with

33
00:01:14,560 --> 00:01:17,119
tor browser in the bundle

34
00:01:17,119 --> 00:01:19,040
that gives you the connectivity to the

35
00:01:19,040 --> 00:01:21,759
network um i've been doing free software

36
00:01:21,759 --> 00:01:24,000
since 2006 i think the most famous

37
00:01:24,000 --> 00:01:25,360
project i've been involved with other

38
00:01:25,360 --> 00:01:29,119
than tor is the erc irc client

39
00:01:29,119 --> 00:01:31,439
and the om was my first hacker camp in

40
00:01:31,439 --> 00:01:33,280
13 it's really really wonderful to be

41
00:01:33,280 --> 00:01:34,880
back

42
00:01:34,880 --> 00:01:37,520
after we went to om and some of the ccc

43
00:01:37,520 --> 00:01:39,200
camp we decided to do our own hacker

44
00:01:39,200 --> 00:01:41,040
camp in born hack

45
00:01:41,040 --> 00:01:44,240
in denmark called born hack so if you

46
00:01:44,240 --> 00:01:46,240
have the sort of blues when a shower is

47
00:01:46,240 --> 00:01:47,680
over you can pack your car and just

48
00:01:47,680 --> 00:01:49,280
drive to denmark and build it all up

49
00:01:49,280 --> 00:01:50,720
again and we'll do another hacker camp

50
00:01:50,720 --> 00:01:52,560
then

51
00:01:52,560 --> 00:01:54,479
so there was a lot of hands up here when

52
00:01:54,479 --> 00:01:56,799
uh when though you were asked if if you

53
00:01:56,799 --> 00:01:58,719
know tor so i'm going to do like a very

54
00:01:58,719 --> 00:02:00,479
quick primer to to what it is so

55
00:02:00,479 --> 00:02:02,159
everybody is sort of in on the lingo and

56
00:02:02,159 --> 00:02:03,119
so on

57
00:02:03,119 --> 00:02:05,200
we do online anonymity and censorship

58
00:02:05,200 --> 00:02:07,759
resistance technology we do free

59
00:02:07,759 --> 00:02:08,959
software everything we do is free

60
00:02:08,959 --> 00:02:10,479
software because we believe that the

61
00:02:10,479 --> 00:02:12,160
only way to sort of do secure software

62
00:02:12,160 --> 00:02:13,360
with the promises that we want to

63
00:02:13,360 --> 00:02:14,480
guarantee

64
00:02:14,480 --> 00:02:16,640
is to have the source code available for

65
00:02:16,640 --> 00:02:18,800
other people researchers and so on to

66
00:02:18,800 --> 00:02:20,319
look at

67
00:02:20,319 --> 00:02:22,800
the network itself is open there are

68
00:02:22,800 --> 00:02:24,319
many people who are running different

69
00:02:24,319 --> 00:02:25,840
kind of relays how many people in here

70
00:02:25,840 --> 00:02:28,560
are running relays or bridges

71
00:02:28,560 --> 00:02:30,640
okay great that's awesome and we of

72
00:02:30,640 --> 00:02:32,720
course like a large community outside of

73
00:02:32,720 --> 00:02:33,840
sort of the

74
00:02:33,840 --> 00:02:35,440
the nonprofit that we're running

75
00:02:35,440 --> 00:02:37,440
ourselves of like researchers developers

76
00:02:37,440 --> 00:02:39,200
users relay operators all kinds of

77
00:02:39,200 --> 00:02:40,720
people who are participating in one way

78
00:02:40,720 --> 00:02:42,879
or another in our community

79
00:02:42,879 --> 00:02:44,959
so normally when we do software you get

80
00:02:44,959 --> 00:02:46,720
a lot of metrics like we have all these

81
00:02:46,720 --> 00:02:48,400
systems today to collect metrics but

82
00:02:48,400 --> 00:02:49,920
because we're doing anonymity we have a

83
00:02:49,920 --> 00:02:51,360
hard time sort of figuring out how many

84
00:02:51,360 --> 00:02:53,200
people are actually using it but the

85
00:02:53,200 --> 00:02:54,800
current research seems to indicate that

86
00:02:54,800 --> 00:02:56,800
it's somewhere between 2 million and 8

87
00:02:56,800 --> 00:02:58,640
million daily users

88
00:02:58,640 --> 00:03:00,560
so if we take a quick primer to how tour

89
00:03:00,560 --> 00:03:02,480
works so here we have alice we have bob

90
00:03:02,480 --> 00:03:04,560
bob is usually a server that you want to

91
00:03:04,560 --> 00:03:06,480
reach on the internet we have the tor

92
00:03:06,480 --> 00:03:08,159
network in the middle consisting of a

93
00:03:08,159 --> 00:03:10,319
number of relays operated by by

94
00:03:10,319 --> 00:03:12,400
different kind of people so what alice

95
00:03:12,400 --> 00:03:13,840
does is that she knows the entire

96
00:03:13,840 --> 00:03:15,440
composition of the network she knows of

97
00:03:15,440 --> 00:03:17,360
all the relays that exist in this system

98
00:03:17,360 --> 00:03:19,200
and decides on three nodes that she

99
00:03:19,200 --> 00:03:21,120
wants to connect through before reaching

100
00:03:21,120 --> 00:03:23,920
bob she starts by establishing a session

101
00:03:23,920 --> 00:03:25,680
key like a cryptographic session key

102
00:03:25,680 --> 00:03:28,239
with the first relay she expands it to

103
00:03:28,239 --> 00:03:29,599
the second relay

104
00:03:29,599 --> 00:03:32,239
further expands it to the last relay and

105
00:03:32,239 --> 00:03:34,080
then finally makes sort of the tcp

106
00:03:34,080 --> 00:03:35,840
stream out to bob and is able to start

107
00:03:35,840 --> 00:03:38,000
communicating over like application

108
00:03:38,000 --> 00:03:40,560
level protocols such as http or https

109
00:03:40,560 --> 00:03:43,040
and so on

110
00:03:43,200 --> 00:03:46,319
we call this sort of a telescope style

111
00:03:46,319 --> 00:03:48,000
connectivity as you can see it sort of

112
00:03:48,000 --> 00:03:49,680
resembles some of the flagpoles that we

113
00:03:49,680 --> 00:03:51,519
have here in camp and that fits pretty

114
00:03:51,519 --> 00:03:53,120
well to that

115
00:03:53,120 --> 00:03:55,760
usually when we talk about this

116
00:03:55,760 --> 00:03:57,360
these three nodes with the first one we

117
00:03:57,360 --> 00:03:59,040
call a guard node the second one we call

118
00:03:59,040 --> 00:04:00,480
a middle node and the third one is the

119
00:04:00,480 --> 00:04:02,720
exit node we also have something called

120
00:04:02,720 --> 00:04:04,480
onion services basically if you want to

121
00:04:04,480 --> 00:04:06,640
think of onion services you eliminate

122
00:04:06,640 --> 00:04:08,400
the exit node add another node there and

123
00:04:08,400 --> 00:04:10,319
then you mirror the entire display on

124
00:04:10,319 --> 00:04:12,400
the other side because onion services

125
00:04:12,400 --> 00:04:14,080
are sort of these services that exist

126
00:04:14,080 --> 00:04:17,358
only in the tor network itself

127
00:04:17,358 --> 00:04:20,560
so a little while ago our wonderful ux

128
00:04:20,560 --> 00:04:23,360
and ui people were

129
00:04:23,360 --> 00:04:25,199
were asking this survey out in the tour

130
00:04:25,199 --> 00:04:26,560
community on

131
00:04:26,560 --> 00:04:28,400
what kind of problem people were facing

132
00:04:28,400 --> 00:04:31,040
with using torn the daily and

133
00:04:31,040 --> 00:04:32,960
this was sort of the order that things

134
00:04:32,960 --> 00:04:35,600
came up with um in in terms of what was

135
00:04:35,600 --> 00:04:38,000
more important to the to the general

136
00:04:38,000 --> 00:04:40,479
user

137
00:04:40,639 --> 00:04:42,639
the speed problem is of course related

138
00:04:42,639 --> 00:04:44,479
to the performance of the tor network

139
00:04:44,479 --> 00:04:45,759
there's a lot of people who have sort of

140
00:04:45,759 --> 00:04:48,000
a feeling that tour is slow to use and

141
00:04:48,000 --> 00:04:51,280
they would like to be have to be faster

142
00:04:51,280 --> 00:04:52,800
and it of course also has to do with

143
00:04:52,800 --> 00:04:54,720
like the throughput and the latency is

144
00:04:54,720 --> 00:04:57,919
related to that blocking has to do with

145
00:04:57,919 --> 00:04:59,840
website blocking we see a lot of capture

146
00:04:59,840 --> 00:05:01,199
portals when you're using the tor

147
00:05:01,199 --> 00:05:03,039
browser from websites who sort of deny

148
00:05:03,039 --> 00:05:06,240
access to tor browser users

149
00:05:06,240 --> 00:05:07,840
the blocking issue is particularly going

150
00:05:07,840 --> 00:05:09,520
to be interesting in the near future

151
00:05:09,520 --> 00:05:11,680
because the big fruit company have

152
00:05:11,680 --> 00:05:13,280
announced for their paid customers that

153
00:05:13,280 --> 00:05:15,039
they have like this privacy relay on

154
00:05:15,039 --> 00:05:17,120
their iphone devices and so on so

155
00:05:17,120 --> 00:05:18,560
they're probably going to be facing some

156
00:05:18,560 --> 00:05:20,080
of these similar issues that we have or

157
00:05:20,080 --> 00:05:22,080
the internet will have to evolve to to

158
00:05:22,080 --> 00:05:23,680
use smarter technology than just

159
00:05:23,680 --> 00:05:25,440
blocking people who

160
00:05:25,440 --> 00:05:28,080
seems like they're doing something bad

161
00:05:28,080 --> 00:05:30,000
we of course have some privacy anonymity

162
00:05:30,000 --> 00:05:32,960
guarantees provided by tor that

163
00:05:32,960 --> 00:05:34,240
that we have to

164
00:05:34,240 --> 00:05:35,520
considerably

165
00:05:35,520 --> 00:05:38,080
like over time tune we have the security

166
00:05:38,080 --> 00:05:39,919
of all the different torque components

167
00:05:39,919 --> 00:05:42,720
we have um of course sort of the user

168
00:05:42,720 --> 00:05:45,360
interface of our products which has uh

169
00:05:45,360 --> 00:05:46,800
if you're using it on the daily you will

170
00:05:46,800 --> 00:05:48,080
probably have seen that it has changed a

171
00:05:48,080 --> 00:05:50,560
lot over time and is i personally think

172
00:05:50,560 --> 00:05:53,840
it's getting way better

173
00:05:53,840 --> 00:05:55,280
if we look at

174
00:05:55,280 --> 00:05:58,080
the toy network it's an open network it

175
00:05:58,080 --> 00:05:59,360
means that everybody can join it

176
00:05:59,360 --> 00:06:01,120
everybody is able to run a relay if you

177
00:06:01,120 --> 00:06:02,639
have an ip and you have some bandwidth

178
00:06:02,639 --> 00:06:04,720
you're able to set up a node

179
00:06:04,720 --> 00:06:06,720
we right now have between six thousand

180
00:06:06,720 --> 00:06:09,280
and seven thousand relay notes and

181
00:06:09,280 --> 00:06:10,880
like i mentioned earlier it's hosted by

182
00:06:10,880 --> 00:06:12,720
probably by some people in here and by

183
00:06:12,720 --> 00:06:14,960
different uh non-profit organizations

184
00:06:14,960 --> 00:06:17,600
around uh around the planet or just

185
00:06:17,600 --> 00:06:19,440
individuals who set up a machine at home

186
00:06:19,440 --> 00:06:22,000
because they have some spare capacity

187
00:06:22,000 --> 00:06:24,400
we have in the network nine what we call

188
00:06:24,400 --> 00:06:26,000
directory authorities these are

189
00:06:26,000 --> 00:06:27,759
specifically trusted nodes they are a

190
00:06:27,759 --> 00:06:31,840
little bit like a ca in like the x 509

191
00:06:31,840 --> 00:06:34,080
tls system and we also have something

192
00:06:34,080 --> 00:06:35,520
called the bridge authority which is for

193
00:06:35,520 --> 00:06:36,319
these

194
00:06:36,319 --> 00:06:38,800
non-public bridge nodes that

195
00:06:38,800 --> 00:06:41,600
that also exist for people in censored

196
00:06:41,600 --> 00:06:43,039
areas who are connecting into the

197
00:06:43,039 --> 00:06:45,440
network

198
00:06:45,840 --> 00:06:48,319
if we take a look at the number of

199
00:06:48,319 --> 00:06:50,479
relays over time we can see that

200
00:06:50,479 --> 00:06:52,319
specifically after the snowden

201
00:06:52,319 --> 00:06:55,840
revelations in the summer of 2013 we

202
00:06:55,840 --> 00:06:58,160
sort of see the curve going up and then

203
00:06:58,160 --> 00:07:00,479
it's sort of reaching a plateau where we

204
00:07:00,479 --> 00:07:02,060
are today

205
00:07:02,060 --> 00:07:03,759
[Music]

206
00:07:03,759 --> 00:07:04,960
the

207
00:07:04,960 --> 00:07:06,720
the bridges are a little bit more sort

208
00:07:06,720 --> 00:07:08,479
of laggy but we recently ran a campaign

209
00:07:08,479 --> 00:07:10,240
to get more bridges unfortunately a lot

210
00:07:10,240 --> 00:07:12,960
of people here in 2022

211
00:07:12,960 --> 00:07:15,039
have started running bridges

212
00:07:15,039 --> 00:07:17,360
even though we sort of have hit sort of

213
00:07:17,360 --> 00:07:19,039
a sweet spot between somewhere between

214
00:07:19,039 --> 00:07:22,080
6000 and 7000 the bandwidth of the

215
00:07:22,080 --> 00:07:24,720
network continues to sort of grow

216
00:07:24,720 --> 00:07:26,639
and get faster also as the internet in

217
00:07:26,639 --> 00:07:28,800
general gets faster

218
00:07:28,800 --> 00:07:30,400
we're going to look more on the

219
00:07:30,400 --> 00:07:32,400
bandwidth in in recent time later in the

220
00:07:32,400 --> 00:07:34,800
presentation but i'm quickly going to go

221
00:07:34,800 --> 00:07:38,639
to uh to sort of the next part

222
00:07:38,639 --> 00:07:41,520
so one of the small thing that we are

223
00:07:41,520 --> 00:07:43,520
about to come up with here in in the

224
00:07:43,520 --> 00:07:44,639
near future

225
00:07:44,639 --> 00:07:46,879
the um the idea with many of these

226
00:07:46,879 --> 00:07:48,720
things is it's stuff that we are either

227
00:07:48,720 --> 00:07:50,639
already working on or something that we

228
00:07:50,639 --> 00:07:53,520
have grant uh grants out to to receive

229
00:07:53,520 --> 00:07:55,039
funding for

230
00:07:55,039 --> 00:07:57,360
so that we are actually able to do it

231
00:07:57,360 --> 00:07:59,120
so people who are familiar with some of

232
00:07:59,120 --> 00:08:00,800
the technical aspects of the tor

233
00:08:00,800 --> 00:08:02,800
protocol we use something called

234
00:08:02,800 --> 00:08:05,199
circuits which is the internal layer of

235
00:08:05,199 --> 00:08:06,960
encryption where you pass what is called

236
00:08:06,960 --> 00:08:09,039
cells around this is similar to other

237
00:08:09,039 --> 00:08:11,520
protocols that uses packets or another

238
00:08:11,520 --> 00:08:13,199
synonym for that

239
00:08:13,199 --> 00:08:17,520
we pass around like these 498 byte cells

240
00:08:17,520 --> 00:08:19,520
one of the issues we've had is that we

241
00:08:19,520 --> 00:08:22,160
don't have we have signal signaling

242
00:08:22,160 --> 00:08:24,479
mechanisms inside the protocol where we

243
00:08:24,479 --> 00:08:26,160
are interested in transferring data that

244
00:08:26,160 --> 00:08:27,840
is smaller than like significantly

245
00:08:27,840 --> 00:08:30,479
smaller than 498 bytes

246
00:08:30,479 --> 00:08:32,880
um we have two proposals there that we

247
00:08:32,880 --> 00:08:34,559
have merged into this what is called

248
00:08:34,559 --> 00:08:36,719
proposal 340

249
00:08:36,719 --> 00:08:38,799
which is our way of sort of like doing

250
00:08:38,799 --> 00:08:41,360
rfc style network updates that are that

251
00:08:41,360 --> 00:08:42,719
are being reviewed

252
00:08:42,719 --> 00:08:44,800
one of them is packed cells it allows us

253
00:08:44,800 --> 00:08:46,800
to take multiple smaller cells and

254
00:08:46,800 --> 00:08:49,120
compress into a single cell that will

255
00:08:49,120 --> 00:08:51,839
then be expanded on the receiving side

256
00:08:51,839 --> 00:08:53,760
whether it's the guard middle or exit

257
00:08:53,760 --> 00:08:56,880
node that is the target

258
00:08:56,880 --> 00:08:58,560
we also have something called fragmented

259
00:08:58,560 --> 00:09:00,800
cells which is i'm going to return to

260
00:09:00,800 --> 00:09:02,800
why this one is important in a bit

261
00:09:02,800 --> 00:09:04,720
but it will allow us to have

262
00:09:04,720 --> 00:09:06,959
very large cells that we split into

263
00:09:06,959 --> 00:09:08,880
multiple cells and will then be gathered

264
00:09:08,880 --> 00:09:10,959
at the destination

265
00:09:10,959 --> 00:09:14,080
and will be packed back into into the

266
00:09:14,080 --> 00:09:16,800
full payload

267
00:09:16,800 --> 00:09:20,320
so the reason that we need this is

268
00:09:20,320 --> 00:09:22,080
there there's a lot of um i don't know

269
00:09:22,080 --> 00:09:23,920
if people are like following these in

270
00:09:23,920 --> 00:09:25,680
this competition that has been recently

271
00:09:25,680 --> 00:09:28,000
on post quantum cryptography

272
00:09:28,000 --> 00:09:29,920
um there was i think it was announced

273
00:09:29,920 --> 00:09:32,160
two weeks ago who the winners were

274
00:09:32,160 --> 00:09:34,320
but these post quantum handshakes we

275
00:09:34,320 --> 00:09:37,360
have historically moved from like uh rsa

276
00:09:37,360 --> 00:09:39,040
and classic divi hellman over to

277
00:09:39,040 --> 00:09:40,720
elliptic curve cryptography when we

278
00:09:40,720 --> 00:09:42,720
entered sort of the mobile world

279
00:09:42,720 --> 00:09:44,000
and um

280
00:09:44,000 --> 00:09:46,240
we got significantly smaller handshakes

281
00:09:46,240 --> 00:09:48,480
like there was way less data on the wire

282
00:09:48,480 --> 00:09:50,399
that we were transferring around but now

283
00:09:50,399 --> 00:09:52,240
we are entering into this

284
00:09:52,240 --> 00:09:53,600
reality of this post quantum

285
00:09:53,600 --> 00:09:55,600
cryptography and the idea there is that

286
00:09:55,600 --> 00:09:57,600
you take these

287
00:09:57,600 --> 00:09:59,360
new handshakes that have significantly

288
00:09:59,360 --> 00:10:00,240
large

289
00:10:00,240 --> 00:10:02,399
both secret keys and public keys but

290
00:10:02,399 --> 00:10:03,920
also the handshake material that you

291
00:10:03,920 --> 00:10:05,920
have to transfer around is

292
00:10:05,920 --> 00:10:07,839
large and biased it's also larger than

293
00:10:07,839 --> 00:10:10,000
what we use for rsa

294
00:10:10,000 --> 00:10:12,160
and this is why we need the fragmented

295
00:10:12,160 --> 00:10:14,160
cells to carry over these

296
00:10:14,160 --> 00:10:18,240
this amount of additional data um

297
00:10:18,240 --> 00:10:20,079
we have two parts that we need to

298
00:10:20,079 --> 00:10:22,399
protect for people who are not aware of

299
00:10:22,399 --> 00:10:24,480
sort of the post quantum stuff the idea

300
00:10:24,480 --> 00:10:26,079
here is that we're worried that

301
00:10:26,079 --> 00:10:27,920
eventually someone will build a quantum

302
00:10:27,920 --> 00:10:30,480
computer and be able to decrypt um the

303
00:10:30,480 --> 00:10:31,760
the handshakes that we've been

304
00:10:31,760 --> 00:10:33,839
transferring over the internet added

305
00:10:33,839 --> 00:10:36,000
with that if you have this notion that

306
00:10:36,000 --> 00:10:37,680
there might be an adversary right now

307
00:10:37,680 --> 00:10:39,680
recording all internet traffic even the

308
00:10:39,680 --> 00:10:41,839
encrypted one then they will eventually

309
00:10:41,839 --> 00:10:43,680
when these machines become available if

310
00:10:43,680 --> 00:10:45,519
they become available we'll go back and

311
00:10:45,519 --> 00:10:47,360
like replay all of this and like decrypt

312
00:10:47,360 --> 00:10:48,240
every

313
00:10:48,240 --> 00:10:49,600
transmission that has happened in the

314
00:10:49,600 --> 00:10:51,279
past right

315
00:10:51,279 --> 00:10:54,160
so we have two parts of tor that we need

316
00:10:54,160 --> 00:10:56,320
to look into and secure against this

317
00:10:56,320 --> 00:10:59,600
kind of adversarial model the tls layer

318
00:10:59,600 --> 00:11:01,279
is sort of the outer layer of the tor

319
00:11:01,279 --> 00:11:03,440
protocol we use ordinary tls we don't

320
00:11:03,440 --> 00:11:04,959
use like let's encrypt or anything like

321
00:11:04,959 --> 00:11:06,640
that because we don't depend on external

322
00:11:06,640 --> 00:11:08,800
services the network is sort of

323
00:11:08,800 --> 00:11:11,760
self-hosting so to say

324
00:11:11,760 --> 00:11:14,160
the tls layer protects against the

325
00:11:14,160 --> 00:11:16,240
adversary who's recording traffic going

326
00:11:16,240 --> 00:11:19,279
around in the network right

327
00:11:19,279 --> 00:11:21,040
and then we have the tor circuit layer

328
00:11:21,040 --> 00:11:24,320
which is a protection mechanism against

329
00:11:24,320 --> 00:11:26,000
an adversary who is currently in the

330
00:11:26,000 --> 00:11:27,920
network for example as a middle node and

331
00:11:27,920 --> 00:11:29,600
is monitoring the encrypted traffic that

332
00:11:29,600 --> 00:11:32,160
it sees that is unpacked from the tls

333
00:11:32,160 --> 00:11:34,480
stack

334
00:11:35,760 --> 00:11:38,240
one of the the other things that we

335
00:11:38,240 --> 00:11:41,680
recently deployed in the tor 047 like

336
00:11:41,680 --> 00:11:43,040
the the post quantum stuff is not

337
00:11:43,040 --> 00:11:44,399
deployed yet that's still in sort of the

338
00:11:44,399 --> 00:11:45,680
research phase

339
00:11:45,680 --> 00:11:47,279
but congestion control was added here

340
00:11:47,279 --> 00:11:50,800
into tor 047 which was released at the

341
00:11:50,800 --> 00:11:52,800
end of april into its stable version

342
00:11:52,800 --> 00:11:54,240
there was some alpha releases before

343
00:11:54,240 --> 00:11:55,760
that

344
00:11:55,760 --> 00:11:57,680
what we did there was um

345
00:11:57,680 --> 00:11:59,279
i personally find it to be a very

346
00:11:59,279 --> 00:12:01,920
interesting project it was led by uh

347
00:12:01,920 --> 00:12:04,399
tour developer mike perry and we use

348
00:12:04,399 --> 00:12:06,240
pretty much all of our different teams

349
00:12:06,240 --> 00:12:08,160
and like all the researchers that we are

350
00:12:08,160 --> 00:12:10,480
near contact with to do this

351
00:12:10,480 --> 00:12:13,760
so what happened was that we implemented

352
00:12:13,760 --> 00:12:16,240
three algorithms like classic algorithms

353
00:12:16,240 --> 00:12:19,120
from tcp for congestion control

354
00:12:19,120 --> 00:12:20,959
it's westwood the one called vegas and

355
00:12:20,959 --> 00:12:23,200
the one called nola you can google these

356
00:12:23,200 --> 00:12:24,320
things and you will be able to read

357
00:12:24,320 --> 00:12:27,200
wikipedia articles about how it works

358
00:12:27,200 --> 00:12:28,560
and

359
00:12:28,560 --> 00:12:30,399
what the team did then was that they

360
00:12:30,399 --> 00:12:32,639
took this very scientific approach to it

361
00:12:32,639 --> 00:12:34,560
with running a ton of simulations to see

362
00:12:34,560 --> 00:12:36,720
how the performance were actually were

363
00:12:36,720 --> 00:12:39,680
they working or were they not working

364
00:12:39,680 --> 00:12:42,720
we um we also we we found some issues

365
00:12:42,720 --> 00:12:44,800
with with two of them despite having

366
00:12:44,800 --> 00:12:46,560
spent time implementing them namely uh

367
00:12:46,560 --> 00:12:48,480
westwood and nola

368
00:12:48,480 --> 00:12:50,000
have this um

369
00:12:50,000 --> 00:12:52,000
compression problem that is uh that is

370
00:12:52,000 --> 00:12:53,920
happening in some congestion algorithms

371
00:12:53,920 --> 00:12:55,920
in the way we were using them so they

372
00:12:55,920 --> 00:12:57,680
overestimated this bandwidth delay

373
00:12:57,680 --> 00:12:59,760
product which led to like these bizarre

374
00:12:59,760 --> 00:13:02,320
conditions that that didn't really work

375
00:13:02,320 --> 00:13:05,279
uh google also came with a bbr algorithm

376
00:13:05,279 --> 00:13:06,720
which is which is another sort of

377
00:13:06,720 --> 00:13:08,959
schoolbook uh congestion control

378
00:13:08,959 --> 00:13:11,360
algorithm um but it would suffer from

379
00:13:11,360 --> 00:13:12,880
these same kind of mechanisms that we

380
00:13:12,880 --> 00:13:15,279
saw with the westwood and nola so there

381
00:13:15,279 --> 00:13:17,440
was no reason to to further dive into

382
00:13:17,440 --> 00:13:19,279
this

383
00:13:19,279 --> 00:13:20,720
um

384
00:13:20,720 --> 00:13:21,920
however

385
00:13:21,920 --> 00:13:24,000
the vegas one

386
00:13:24,000 --> 00:13:26,320
worked extremely beautifully and worked

387
00:13:26,320 --> 00:13:29,680
in simulation uh exactly how we

388
00:13:29,680 --> 00:13:31,839
were going to think of it in the paper

389
00:13:31,839 --> 00:13:33,600
so these plots are a little bit hard to

390
00:13:33,600 --> 00:13:37,680
read it's sort of a distribution of um

391
00:13:37,680 --> 00:13:39,920
of the data that we're sending the blue

392
00:13:39,920 --> 00:13:43,600
you see um is the uh

393
00:13:43,600 --> 00:13:47,440
is the old version of tor and the

394
00:13:47,440 --> 00:13:49,760
rng yellow thing is

395
00:13:49,760 --> 00:13:51,600
the modern version after congestion

396
00:13:51,600 --> 00:13:52,639
control

397
00:13:52,639 --> 00:13:54,959
the first one is simulated as being a

398
00:13:54,959 --> 00:13:56,320
client in

399
00:13:56,320 --> 00:13:58,720
germany where we have because in germany

400
00:13:58,720 --> 00:14:00,320
there's hetzner and like we generally

401
00:14:00,320 --> 00:14:02,000
have a lot of tour notes in central

402
00:14:02,000 --> 00:14:04,959
europe and in northern america

403
00:14:04,959 --> 00:14:06,480
and the second

404
00:14:06,480 --> 00:14:08,480
image is from hong kong

405
00:14:08,480 --> 00:14:11,199
and what we see here is that in general

406
00:14:11,199 --> 00:14:13,360
people are able to achieve much higher

407
00:14:13,360 --> 00:14:15,199
amount of bandwidth

408
00:14:15,199 --> 00:14:17,360
when doing this

409
00:14:17,360 --> 00:14:19,600
it's worth adding that historically like

410
00:14:19,600 --> 00:14:21,760
the team that i'm in we have when we do

411
00:14:21,760 --> 00:14:23,519
experiments we have like these two tools

412
00:14:23,519 --> 00:14:26,000
that we can pull in for doing local tour

413
00:14:26,000 --> 00:14:27,680
network simulations we have one called

414
00:14:27,680 --> 00:14:28,959
chutney

415
00:14:28,959 --> 00:14:30,959
which is a tool where you specify in

416
00:14:30,959 --> 00:14:32,639
these python files that i want a toy

417
00:14:32,639 --> 00:14:35,199
network consisting of 200 nodes some

418
00:14:35,199 --> 00:14:38,000
bridges like four directory authorities

419
00:14:38,000 --> 00:14:39,519
and then it spawns it up on your machine

420
00:14:39,519 --> 00:14:41,519
and you can do like some some like

421
00:14:41,519 --> 00:14:43,920
testing to see how things are working we

422
00:14:43,920 --> 00:14:45,519
also have sort of the big artillery

423
00:14:45,519 --> 00:14:48,639
which is called shadow it's made by

424
00:14:48,639 --> 00:14:50,160
originally made by

425
00:14:50,160 --> 00:14:51,920
a person called robinson who's one of

426
00:14:51,920 --> 00:14:53,440
the researchers heavily involved with

427
00:14:53,440 --> 00:14:55,279
tor

428
00:14:55,279 --> 00:14:56,800
and he has actually a team now who's

429
00:14:56,800 --> 00:14:58,880
sitting and working on getting a shadow

430
00:14:58,880 --> 00:14:59,600
to

431
00:14:59,600 --> 00:15:01,839
work a lot better and we finally started

432
00:15:01,839 --> 00:15:03,839
adopting this in our workflows

433
00:15:03,839 --> 00:15:06,320
i i don't know if there's anything out

434
00:15:06,320 --> 00:15:08,440
yet um on our blog like

435
00:15:08,440 --> 00:15:10,240
blockchairproject.org but it's really

436
00:15:10,240 --> 00:15:11,920
interesting to look at how this was run

437
00:15:11,920 --> 00:15:13,839
we we did it with it's almost worth its

438
00:15:13,839 --> 00:15:14,880
own talk

439
00:15:14,880 --> 00:15:16,160
um

440
00:15:16,160 --> 00:15:18,560
we use gitlab runners to spawn large

441
00:15:18,560 --> 00:15:21,199
amounts of simulation nodes so that the

442
00:15:21,199 --> 00:15:22,320
team could

443
00:15:22,320 --> 00:15:23,920
consistently every time they wanted to

444
00:15:23,920 --> 00:15:25,440
run new experiments it was just pushing

445
00:15:25,440 --> 00:15:26,720
and then they got the results and they

446
00:15:26,720 --> 00:15:27,920
could sort of see it a little while

447
00:15:27,920 --> 00:15:29,920
after

448
00:15:29,920 --> 00:15:31,839
so this is um

449
00:15:31,839 --> 00:15:34,240
the total relay bandwidth plot that you

450
00:15:34,240 --> 00:15:36,320
saw before where it was like going steep

451
00:15:36,320 --> 00:15:38,320
up and it was difficult to see this is

452
00:15:38,320 --> 00:15:41,920
only from 2021 and 2022.

453
00:15:41,920 --> 00:15:44,240
um let's see if this thing works

454
00:15:44,240 --> 00:15:47,040
okay so you see these two huge spikes

455
00:15:47,040 --> 00:15:49,440
here to understand this plot

456
00:15:49,440 --> 00:15:51,360
the top one

457
00:15:51,360 --> 00:15:53,440
the the top part of the plot

458
00:15:53,440 --> 00:15:56,320
is relays are consistently observing how

459
00:15:56,320 --> 00:15:58,399
much traffic they're seeing and they're

460
00:15:58,399 --> 00:16:01,040
noting down the maximum value of traffic

461
00:16:01,040 --> 00:16:02,639
they're seeing in the network right now

462
00:16:02,639 --> 00:16:04,399
and they're reporting it back to the

463
00:16:04,399 --> 00:16:05,920
directory authorities when they sort of

464
00:16:05,920 --> 00:16:08,480
call in and say hey i'm still alive

465
00:16:08,480 --> 00:16:09,279
the

466
00:16:09,279 --> 00:16:10,240
orange

467
00:16:10,240 --> 00:16:12,320
part is

468
00:16:12,320 --> 00:16:14,079
where they write how much real traffic

469
00:16:14,079 --> 00:16:16,079
they've actually seen

470
00:16:16,079 --> 00:16:18,959
so these two spikes that happened in

471
00:16:18,959 --> 00:16:20,880
oh wow it's very dead

472
00:16:20,880 --> 00:16:23,839
these two spikes here are

473
00:16:23,839 --> 00:16:25,600
comes from an experiment where what we

474
00:16:25,600 --> 00:16:27,600
did was that we essentially wrote a

475
00:16:27,600 --> 00:16:29,920
script that would iterate over the

476
00:16:29,920 --> 00:16:32,000
entire set of chore notes

477
00:16:32,000 --> 00:16:34,320
and start just hammering traffic over it

478
00:16:34,320 --> 00:16:36,399
in a very short amount of time so that

479
00:16:36,399 --> 00:16:38,399
the relay would discover its actual

480
00:16:38,399 --> 00:16:39,600
capacity

481
00:16:39,600 --> 00:16:41,759
and be able to report back oh i actually

482
00:16:41,759 --> 00:16:43,839
am able to transfer much more traffic

483
00:16:43,839 --> 00:16:45,519
the rolling window then goes out

484
00:16:45,519 --> 00:16:47,680
eventually and we fall back to sort of

485
00:16:47,680 --> 00:16:48,880
the the

486
00:16:48,880 --> 00:16:50,880
normal kind of of traffic that's

487
00:16:50,880 --> 00:16:52,000
happening

488
00:16:52,000 --> 00:16:54,320
and as you can see the um

489
00:16:54,320 --> 00:16:56,079
the amount of reported traffic is not

490
00:16:56,079 --> 00:16:58,160
increasing so this had no impact on sort

491
00:16:58,160 --> 00:17:00,639
of the the bandwidth of the network

492
00:17:00,639 --> 00:17:03,120
what is however interesting is

493
00:17:03,120 --> 00:17:05,679
here this is the moment where we

494
00:17:05,679 --> 00:17:08,079
deployed congestion control and you can

495
00:17:08,079 --> 00:17:10,319
see that we sort of start increasing the

496
00:17:10,319 --> 00:17:12,160
amount of of traffic that is in the

497
00:17:12,160 --> 00:17:13,199
network

498
00:17:13,199 --> 00:17:15,439
um but we also start seeing the moment a

499
00:17:15,439 --> 00:17:17,359
little bit after the tor browser release

500
00:17:17,359 --> 00:17:19,679
came out with 047 in with the stable

501
00:17:19,679 --> 00:17:21,599
version and we can see people start to

502
00:17:21,599 --> 00:17:22,959
utilize

503
00:17:22,959 --> 00:17:24,319
more traffic

504
00:17:24,319 --> 00:17:26,959
however as you can see the curve is sort

505
00:17:26,959 --> 00:17:31,120
of cutting a little bit short after

506
00:17:31,120 --> 00:17:32,960
we have this um

507
00:17:32,960 --> 00:17:34,960
since we are a little bit of a social

508
00:17:34,960 --> 00:17:36,480
experiment as well with that we have all

509
00:17:36,480 --> 00:17:38,480
these people running the relays

510
00:17:38,480 --> 00:17:40,000
we unfortunately also have some people

511
00:17:40,000 --> 00:17:41,679
who are attacking the network using sort

512
00:17:41,679 --> 00:17:43,840
of traditional mechanisms of denial of

513
00:17:43,840 --> 00:17:45,760
service through either flooding or

514
00:17:45,760 --> 00:17:47,039
finding different kind of things in the

515
00:17:47,039 --> 00:17:49,840
network that is that is costly

516
00:17:49,840 --> 00:17:52,080
so in the last couple of weeks we've

517
00:17:52,080 --> 00:17:53,600
seen

518
00:17:53,600 --> 00:17:55,679
like an ongoing denial of service using

519
00:17:55,679 --> 00:17:57,440
different kind of techniques

520
00:17:57,440 --> 00:17:58,240
and

521
00:17:58,240 --> 00:18:00,799
it has made it pretty hard for us to to

522
00:18:00,799 --> 00:18:02,880
see if the deployment of this congestion

523
00:18:02,880 --> 00:18:04,720
control feature is going well but

524
00:18:04,720 --> 00:18:06,799
usually after a while these things stop

525
00:18:06,799 --> 00:18:09,679
and we also have some some plans for

526
00:18:09,679 --> 00:18:11,840
um mitigating some of this that i will

527
00:18:11,840 --> 00:18:15,840
return to a little bit later in the talk

528
00:18:16,000 --> 00:18:19,520
this is a very beautiful

529
00:18:19,520 --> 00:18:20,400
plot

530
00:18:20,400 --> 00:18:23,200
it shows the number of like the versions

531
00:18:23,200 --> 00:18:24,880
that are currently active in the tor

532
00:18:24,880 --> 00:18:26,080
network

533
00:18:26,080 --> 00:18:27,280
two versions that are a little bit

534
00:18:27,280 --> 00:18:30,799
special the o45 is an lts version i

535
00:18:30,799 --> 00:18:33,039
believe that is the one packed in debian

536
00:18:33,039 --> 00:18:34,400
stable today

537
00:18:34,400 --> 00:18:37,679
and o35 was the older lts version which

538
00:18:37,679 --> 00:18:40,160
is now like completely gone

539
00:18:40,160 --> 00:18:42,160
um

540
00:18:42,160 --> 00:18:44,559
it's really really awesome like i said

541
00:18:44,559 --> 00:18:46,240
the we released

542
00:18:46,240 --> 00:18:48,480
0.47 staple at the end of

543
00:18:48,480 --> 00:18:49,520
april

544
00:18:49,520 --> 00:18:51,200
and we can see very quickly thereafter

545
00:18:51,200 --> 00:18:54,000
that relay operator starts um upgrading

546
00:18:54,000 --> 00:18:57,760
from 046 to 2047

547
00:18:57,760 --> 00:19:00,640
so a massive thank you for to the people

548
00:19:00,640 --> 00:19:01,679
who have been doing this if you're

549
00:19:01,679 --> 00:19:03,200
running relays and you're not upgraded

550
00:19:03,200 --> 00:19:05,919
to 0.47 yet please when it's not as warm

551
00:19:05,919 --> 00:19:07,440
as it is now

552
00:19:07,440 --> 00:19:10,240
go home and and and upgrade because one

553
00:19:10,240 --> 00:19:12,480
of the problems for us with having this

554
00:19:12,480 --> 00:19:15,120
very heterogeneous network

555
00:19:15,120 --> 00:19:17,520
is that

556
00:19:17,679 --> 00:19:19,679
we we need to be able to upgrade quickly

557
00:19:19,679 --> 00:19:21,440
to get the new features so we can

558
00:19:21,440 --> 00:19:22,720
actually see that they're working if

559
00:19:22,720 --> 00:19:24,960
nobody is upgrading then we will

560
00:19:24,960 --> 00:19:27,120
finish and wrapping up our part of it

561
00:19:27,120 --> 00:19:28,480
then we'll deploy it to the network and

562
00:19:28,480 --> 00:19:30,400
there will be all kinds of problems

563
00:19:30,400 --> 00:19:32,160
so we've spent like significant portions

564
00:19:32,160 --> 00:19:33,840
of time doing like reach out and trying

565
00:19:33,840 --> 00:19:36,160
to get people to um to to actually

566
00:19:36,160 --> 00:19:38,400
operate so so thank you to everybody who

567
00:19:38,400 --> 00:19:40,559
has been doing that and and continue to

568
00:19:40,559 --> 00:19:42,960
maintain their tour relays in in a

569
00:19:42,960 --> 00:19:45,520
really nice way manner

570
00:19:45,520 --> 00:19:47,200
we have some more stuff to do here in

571
00:19:47,200 --> 00:19:49,120
the congestion control for people who

572
00:19:49,120 --> 00:19:50,480
are a little bit technical about the

573
00:19:50,480 --> 00:19:51,760
tour network we have something called

574
00:19:51,760 --> 00:19:53,600
flags that the directory authorities can

575
00:19:53,600 --> 00:19:56,080
give to to relays we have something

576
00:19:56,080 --> 00:19:57,760
called fast and we have something called

577
00:19:57,760 --> 00:19:58,640
guard

578
00:19:58,640 --> 00:20:00,880
fast is that you are like a part of the

579
00:20:00,880 --> 00:20:02,799
faster amount of relays that we're

580
00:20:02,799 --> 00:20:04,960
seeing in the total network and guard is

581
00:20:04,960 --> 00:20:06,400
that you seem to be stable enough that

582
00:20:06,400 --> 00:20:08,799
we can use you as the first node

583
00:20:08,799 --> 00:20:10,799
we have these cutoff values which says

584
00:20:10,799 --> 00:20:12,480
that you can only get this flag if you

585
00:20:12,480 --> 00:20:14,320
transmit like if you're able to transmit

586
00:20:14,320 --> 00:20:16,080
a certain amount of traffic

587
00:20:16,080 --> 00:20:17,840
and we are likely going to bump that

588
00:20:17,840 --> 00:20:21,200
value up because we still have a lot of

589
00:20:21,200 --> 00:20:24,000
um i guess it's hard for us to to guess

590
00:20:24,000 --> 00:20:25,280
but i would assume it's something like

591
00:20:25,280 --> 00:20:26,720
people are running tor relays on their

592
00:20:26,720 --> 00:20:29,120
home connection on our raspberry pi 1

593
00:20:29,120 --> 00:20:31,679
and is probably suffering a bit so such

594
00:20:31,679 --> 00:20:33,440
notes shouldn't should likely not be

595
00:20:33,440 --> 00:20:36,080
neither a fast nor a guard because

596
00:20:36,080 --> 00:20:37,360
if it is the guard node it will

597
00:20:37,360 --> 00:20:39,120
significantly impact

598
00:20:39,120 --> 00:20:40,960
um people who

599
00:20:40,960 --> 00:20:42,960
who want to have a faster experience

600
00:20:42,960 --> 00:20:45,360
over the tor network

601
00:20:45,360 --> 00:20:47,360
so to wrap things up a bit if you're an

602
00:20:47,360 --> 00:20:48,799
onion service operator you will also

603
00:20:48,799 --> 00:20:50,559
benefit from the congestion control

604
00:20:50,559 --> 00:20:52,880
changes relay operators should probably

605
00:20:52,880 --> 00:20:54,640
prepare if they're running big relays to

606
00:20:54,640 --> 00:20:56,960
set limits to

607
00:20:56,960 --> 00:20:58,559
to to how much bandwidth you want to use

608
00:20:58,559 --> 00:21:00,799
because as the network upgrades slowly

609
00:21:00,799 --> 00:21:03,200
we will see the hoses hopefully get get

610
00:21:03,200 --> 00:21:04,400
filled more

611
00:21:04,400 --> 00:21:05,760
if you want to read more about the

612
00:21:05,760 --> 00:21:07,520
congestion control stuff you should read

613
00:21:07,520 --> 00:21:10,080
mike perry's summary block which is on

614
00:21:10,080 --> 00:21:11,600
on this link i will also upload this

615
00:21:11,600 --> 00:21:12,960
slide somewhere where you can just click

616
00:21:12,960 --> 00:21:14,640
on it if you can't remember it but it's

617
00:21:14,640 --> 00:21:17,760
one of our recent blog posts

618
00:21:17,760 --> 00:21:19,280
another thing we're going to look at is

619
00:21:19,280 --> 00:21:21,360
something called conflux

620
00:21:21,360 --> 00:21:24,159
um the idea here is to add one more

621
00:21:24,159 --> 00:21:26,000
layer to tor which

622
00:21:26,000 --> 00:21:27,840
should ideally work like help us with

623
00:21:27,840 --> 00:21:29,919
some of the network performance issues

624
00:21:29,919 --> 00:21:31,679
or bottlenecks

625
00:21:31,679 --> 00:21:33,440
and that is called a technique called

626
00:21:33,440 --> 00:21:34,720
traffic splitting

627
00:21:34,720 --> 00:21:36,559
we have a proposal for it and we have

628
00:21:36,559 --> 00:21:38,640
like the paper originally written by the

629
00:21:38,640 --> 00:21:41,280
by the researchers who did this um and

630
00:21:41,280 --> 00:21:42,799
it is worth a read if you're interested

631
00:21:42,799 --> 00:21:44,400
in that kind of stuff

632
00:21:44,400 --> 00:21:45,919
the way it works is that normally we

633
00:21:45,919 --> 00:21:47,600
have this alice and bob image again

634
00:21:47,600 --> 00:21:50,000
where alice have established a session

635
00:21:50,000 --> 00:21:51,600
all the way out to bob

636
00:21:51,600 --> 00:21:52,480
um

637
00:21:52,480 --> 00:21:54,640
one of the issues here is if like we

638
00:21:54,640 --> 00:21:56,400
know the network like the internet is a

639
00:21:56,400 --> 00:22:00,480
pretty chaotic place um so the

640
00:22:00,480 --> 00:22:02,480
so we're traveling through a lot of as

641
00:22:02,480 --> 00:22:04,480
numbers in in this plot like it's not

642
00:22:04,480 --> 00:22:05,760
like these nodes are sitting on the same

643
00:22:05,760 --> 00:22:07,600
network or anything like that

644
00:22:07,600 --> 00:22:10,640
um so if one of the nodes or the network

645
00:22:10,640 --> 00:22:12,400
between them goes down the entire

646
00:22:12,400 --> 00:22:14,320
circuit is turned off and you lose like

647
00:22:14,320 --> 00:22:16,320
your ssh connection or your download

648
00:22:16,320 --> 00:22:18,880
stops and these kind of things

649
00:22:18,880 --> 00:22:21,200
so what conflux does

650
00:22:21,200 --> 00:22:23,280
is that it allows alice to establish

651
00:22:23,280 --> 00:22:26,159
multiple paths to the exit node and be

652
00:22:26,159 --> 00:22:28,400
able to transmit on the one that is the

653
00:22:28,400 --> 00:22:31,039
least congested so we use the congestion

654
00:22:31,039 --> 00:22:32,880
algorithm to sort of get a feedback on

655
00:22:32,880 --> 00:22:34,799
how things are going and we will use the

656
00:22:34,799 --> 00:22:37,120
fastest one if a connection is torn down

657
00:22:37,120 --> 00:22:38,559
we can just start transmitting on the

658
00:22:38,559 --> 00:22:40,240
other one and start establishing a new

659
00:22:40,240 --> 00:22:42,400
conflux path through the network at the

660
00:22:42,400 --> 00:22:44,000
exit node and

661
00:22:44,000 --> 00:22:45,760
the exit node will then be responsible

662
00:22:45,760 --> 00:22:47,120
for buffering a little bit and

663
00:22:47,120 --> 00:22:48,720
transmitting data of course in the right

664
00:22:48,720 --> 00:22:50,720
order

665
00:22:50,720 --> 00:22:53,600
oh the next slide is a hot potato

666
00:22:53,600 --> 00:22:55,679
so one of the issues we've seen with the

667
00:22:55,679 --> 00:22:58,159
denial of service attacks is that

668
00:22:58,159 --> 00:23:00,000
they are often happening towards onion

669
00:23:00,000 --> 00:23:01,120
services

670
00:23:01,120 --> 00:23:03,280
and because we have this

671
00:23:03,280 --> 00:23:05,520
architecture today that you have

672
00:23:05,520 --> 00:23:07,840
the tor client running and i say client

673
00:23:07,840 --> 00:23:10,159
because onion services are essentially

674
00:23:10,159 --> 00:23:11,840
clients to the network

675
00:23:11,840 --> 00:23:13,520
and then you have nginx or a web server

676
00:23:13,520 --> 00:23:15,440
or an irc server an ssh server or

677
00:23:15,440 --> 00:23:17,039
whatever running on it

678
00:23:17,039 --> 00:23:18,880
there's no good sort of pushback

679
00:23:18,880 --> 00:23:20,640
mechanism that we know from distributed

680
00:23:20,640 --> 00:23:23,280
systems here to sort of

681
00:23:23,280 --> 00:23:26,080
avoid having to flood the tor binaries

682
00:23:26,080 --> 00:23:27,760
added with the tor

683
00:23:27,760 --> 00:23:29,679
the the current architecture of tor is

684
00:23:29,679 --> 00:23:32,240
single threaded and like not very good

685
00:23:32,240 --> 00:23:33,919
at handling these many connections we do

686
00:23:33,919 --> 00:23:35,600
see attacks on onion services that are

687
00:23:35,600 --> 00:23:37,360
problematic

688
00:23:37,360 --> 00:23:39,120
so one of the designs that we can

689
00:23:39,120 --> 00:23:41,279
implement here that

690
00:23:41,279 --> 00:23:43,600
it's disabled by default

691
00:23:43,600 --> 00:23:45,679
but the idea is that if an onion service

692
00:23:45,679 --> 00:23:47,279
starts detecting that it's being the

693
00:23:47,279 --> 00:23:48,799
target of something

694
00:23:48,799 --> 00:23:49,600
that

695
00:23:49,600 --> 00:23:52,000
is sort of pathological in nature what

696
00:23:52,000 --> 00:23:53,600
we can do is that we can start setting a

697
00:23:53,600 --> 00:23:55,679
difficulty at the introduction points

698
00:23:55,679 --> 00:23:58,799
into the network into the onion services

699
00:23:58,799 --> 00:24:00,240
where the client have to deliver some

700
00:24:00,240 --> 00:24:01,360
kind of proof that they've done a

701
00:24:01,360 --> 00:24:03,279
computation so you cannot do the trivial

702
00:24:03,279 --> 00:24:05,039
flooding here

703
00:24:05,039 --> 00:24:07,440
we've gotten some help for from

704
00:24:07,440 --> 00:24:09,440
a hacker called tivador on this and

705
00:24:09,440 --> 00:24:10,960
we're still experimenting a little bit

706
00:24:10,960 --> 00:24:13,200
with the entire setup

707
00:24:13,200 --> 00:24:15,840
it all happened during a heck week doing

708
00:24:15,840 --> 00:24:17,520
the ongoing donatio service a couple of

709
00:24:17,520 --> 00:24:19,200
weeks ago with

710
00:24:19,200 --> 00:24:22,480
where david and mike dived into this

711
00:24:22,480 --> 00:24:23,919
so i mentioned a little bit some of the

712
00:24:23,919 --> 00:24:26,080
shortcomings with the

713
00:24:26,080 --> 00:24:28,080
with the tor architecture itself and

714
00:24:28,080 --> 00:24:29,440
sort of the

715
00:24:29,440 --> 00:24:31,679
performance nature of it

716
00:24:31,679 --> 00:24:33,120
one of the really cool things we're

717
00:24:33,120 --> 00:24:36,000
doing right now is a project called rd

718
00:24:36,000 --> 00:24:39,840
rd stands for a rust tor implementation

719
00:24:39,840 --> 00:24:41,360
so

720
00:24:41,360 --> 00:24:42,320
what we're doing is that we're

721
00:24:42,320 --> 00:24:44,720
essentially rewriting tor and rust in a

722
00:24:44,720 --> 00:24:47,120
smarter way

723
00:24:47,120 --> 00:24:49,919
and the goal here is to build it as a

724
00:24:49,919 --> 00:24:53,600
library to work with tor in general

725
00:24:53,600 --> 00:24:55,919
so with tour as it is today it's it's

726
00:24:55,919 --> 00:24:57,840
like this very classic

727
00:24:57,840 --> 00:24:59,600
unix architecture where you have like a

728
00:24:59,600 --> 00:25:02,400
single binary it does multiple things

729
00:25:02,400 --> 00:25:03,919
it's both a client it can act like a

730
00:25:03,919 --> 00:25:05,360
relay it can act like a directory

731
00:25:05,360 --> 00:25:07,039
authority that there's only 10 off and

732
00:25:07,039 --> 00:25:08,240
like running

733
00:25:08,240 --> 00:25:10,240
in production right

734
00:25:10,240 --> 00:25:12,000
it's also an onion service client and

735
00:25:12,000 --> 00:25:13,039
all these different kind of things so

736
00:25:13,039 --> 00:25:14,960
instead of doing it with this one binary

737
00:25:14,960 --> 00:25:16,960
and architected as a

738
00:25:16,960 --> 00:25:18,720
as a binary with a ton of global state

739
00:25:18,720 --> 00:25:20,720
and so on what we're doing is that we're

740
00:25:20,720 --> 00:25:22,640
building it as a library as a rust

741
00:25:22,640 --> 00:25:24,000
library

742
00:25:24,000 --> 00:25:25,919
this will hopefully make it easier for

743
00:25:25,919 --> 00:25:28,159
example mobile developers to integrate

744
00:25:28,159 --> 00:25:30,720
tor into their applications for example

745
00:25:30,720 --> 00:25:32,400
for people doing messaging or people

746
00:25:32,400 --> 00:25:35,279
doing we've had these uh kovit 19

747
00:25:35,279 --> 00:25:37,520
tracing project in germany who's been

748
00:25:37,520 --> 00:25:39,919
experimenting a bit with integrating rd

749
00:25:39,919 --> 00:25:43,480
on on ios

750
00:25:43,520 --> 00:25:45,760
historically we've also used a library

751
00:25:45,760 --> 00:25:48,159
called stem which is a python library

752
00:25:48,159 --> 00:25:50,480
which can parse like the directory

753
00:25:50,480 --> 00:25:52,080
documents that we are passing around and

754
00:25:52,080 --> 00:25:53,760
the different objects that exist within

755
00:25:53,760 --> 00:25:55,520
the tor network

756
00:25:55,520 --> 00:25:57,679
and the goal here is that we get rd to

757
00:25:57,679 --> 00:25:59,200
also do this so we

758
00:25:59,200 --> 00:26:01,120
so our metrics team eventually will be

759
00:26:01,120 --> 00:26:03,440
able to parse like network descriptors

760
00:26:03,440 --> 00:26:07,120
in rust and and use that instead

761
00:26:07,120 --> 00:26:09,039
onion services is of course also a big

762
00:26:09,039 --> 00:26:10,799
part of it onion services today is a

763
00:26:10,799 --> 00:26:12,400
binary where you just get like tcp

764
00:26:12,400 --> 00:26:13,840
connections coming out of the tour

765
00:26:13,840 --> 00:26:16,400
process into your service or unix domain

766
00:26:16,400 --> 00:26:17,520
circuits

767
00:26:17,520 --> 00:26:19,440
and having onion services being able to

768
00:26:19,440 --> 00:26:21,840
not be

769
00:26:22,159 --> 00:26:24,080
having any sockets involved in all that

770
00:26:24,080 --> 00:26:25,919
it's just like api calls where you can

771
00:26:25,919 --> 00:26:27,440
for example do a callback instead it's

772
00:26:27,440 --> 00:26:28,480
going to be

773
00:26:28,480 --> 00:26:31,760
way way way nicer for um

774
00:26:31,760 --> 00:26:33,440
for developers because we will also be

775
00:26:33,440 --> 00:26:34,960
able to deliver more metadata about

776
00:26:34,960 --> 00:26:36,799
what's going on in the network

777
00:26:36,799 --> 00:26:38,320
um even though we have tried some of

778
00:26:38,320 --> 00:26:40,320
those things with tor that that was not

779
00:26:40,320 --> 00:26:41,919
very beautiful we've done some pretty

780
00:26:41,919 --> 00:26:43,360
iggy hacks for

781
00:26:43,360 --> 00:26:44,880
for the large providers of onion

782
00:26:44,880 --> 00:26:46,640
services like facebook and cloudflare

783
00:26:46,640 --> 00:26:49,039
and so on who needed this

784
00:26:49,039 --> 00:26:51,919
so why on earth would we start rewriting

785
00:26:51,919 --> 00:26:54,080
a project that have existed for so long

786
00:26:54,080 --> 00:26:55,840
and it's such a

787
00:26:55,840 --> 00:26:58,240
a big part of the code base that we're

788
00:26:58,240 --> 00:26:59,279
running

789
00:26:59,279 --> 00:27:02,559
so writing safe c and i have safe c and

790
00:27:02,559 --> 00:27:04,720
quotation marks it's pretty costly like

791
00:27:04,720 --> 00:27:06,799
we spend a lot of time on like static

792
00:27:06,799 --> 00:27:08,960
code analysis having external parties

793
00:27:08,960 --> 00:27:10,480
review stuff

794
00:27:10,480 --> 00:27:12,320
even doing internal code review in the

795
00:27:12,320 --> 00:27:14,480
team is costly

796
00:27:14,480 --> 00:27:16,320
we have to

797
00:27:16,320 --> 00:27:18,840
be very careful when we architect new

798
00:27:18,840 --> 00:27:21,120
plans that we

799
00:27:21,120 --> 00:27:22,880
are able to split it up into sort of

800
00:27:22,880 --> 00:27:24,640
smaller chunks so we won't have half of

801
00:27:24,640 --> 00:27:26,320
the team spending two weeks sitting and

802
00:27:26,320 --> 00:27:27,919
reviewing code

803
00:27:27,919 --> 00:27:31,120
so added with that the network team at

804
00:27:31,120 --> 00:27:34,720
tour was all very excited about rust and

805
00:27:34,720 --> 00:27:36,000
all of them expressed interest in

806
00:27:36,000 --> 00:27:37,520
spending more time of it so it grew a

807
00:27:37,520 --> 00:27:39,520
little bit natural we did an experiment

808
00:27:39,520 --> 00:27:41,840
before rd with

809
00:27:41,840 --> 00:27:44,240
replacing parts of the c tour code base

810
00:27:44,240 --> 00:27:45,679
with rust

811
00:27:45,679 --> 00:27:47,760
but all the because of the tour

812
00:27:47,760 --> 00:27:49,760
architecture the all the different

813
00:27:49,760 --> 00:27:51,440
layers where we had to call from sea

814
00:27:51,440 --> 00:27:53,600
into rust and from rust out to sea

815
00:27:53,600 --> 00:27:56,320
became pretty nasty um

816
00:27:56,320 --> 00:27:59,600
and uh we never decided to to sort of

817
00:27:59,600 --> 00:28:01,919
instead do it the the hard way and do it

818
00:28:01,919 --> 00:28:05,039
from from scratch

819
00:28:05,200 --> 00:28:07,279
added with um people in here are

820
00:28:07,279 --> 00:28:09,360
probably familiar with cvs

821
00:28:09,360 --> 00:28:11,919
we have our own tracking called a trove

822
00:28:11,919 --> 00:28:14,960
which is when we have

823
00:28:15,200 --> 00:28:18,559
like security implicating bugs we tried

824
00:28:18,559 --> 00:28:20,880
to track those specifically and we could

825
00:28:20,880 --> 00:28:23,200
look at uh thanks to nick matthewson who

826
00:28:23,200 --> 00:28:24,880
spent some time categorizing our

827
00:28:24,880 --> 00:28:26,320
different bugs that we've used this

828
00:28:26,320 --> 00:28:29,600
trophy it turned out that 21 out of 34

829
00:28:29,600 --> 00:28:31,679
of these was related to memory issues

830
00:28:31,679 --> 00:28:34,399
that like the c programming uh allowed

831
00:28:34,399 --> 00:28:35,520
us to do

832
00:28:35,520 --> 00:28:37,919
um and

833
00:28:37,919 --> 00:28:40,000
like i'm not a very uh bragging person

834
00:28:40,000 --> 00:28:42,640
but i think the team is is a very good

835
00:28:42,640 --> 00:28:44,399
team of c programmers

836
00:28:44,399 --> 00:28:46,399
and we even make these mistakes and i

837
00:28:46,399 --> 00:28:48,240
think that will go for every like good

838
00:28:48,240 --> 00:28:50,320
team who is who's writing large code

839
00:28:50,320 --> 00:28:52,960
bases in c

840
00:28:52,960 --> 00:28:55,360
so the audio roadmap as it is right now

841
00:28:55,360 --> 00:28:56,880
is that we're

842
00:28:56,880 --> 00:28:58,880
we're working towards api stability so

843
00:28:58,880 --> 00:29:00,559
that we have some kind of base where we

844
00:29:00,559 --> 00:29:02,159
can start telling people like try this

845
00:29:02,159 --> 00:29:04,559
out and start experimenting with stuff

846
00:29:04,559 --> 00:29:07,039
um we need to at some point focus on

847
00:29:07,039 --> 00:29:09,440
like usability performance and stability

848
00:29:09,440 --> 00:29:11,120
so that things are working things are

849
00:29:11,120 --> 00:29:12,799
able to reach the network every time and

850
00:29:12,799 --> 00:29:14,880
the way you sort of expect it

851
00:29:14,880 --> 00:29:16,960
for the 1.1 release we are going to

852
00:29:16,960 --> 00:29:19,039
start integrating pluggable transports

853
00:29:19,039 --> 00:29:20,799
bridge support being able to run these

854
00:29:20,799 --> 00:29:22,399
things there's likely some stuff with

855
00:29:22,399 --> 00:29:23,919
plugable transports that we want to look

856
00:29:23,919 --> 00:29:25,440
at with sort of the general architecture

857
00:29:25,440 --> 00:29:27,039
of that

858
00:29:27,039 --> 00:29:29,039
1.2 is going to be onion services and

859
00:29:29,039 --> 00:29:30,960
2.0 is going to be the release where we

860
00:29:30,960 --> 00:29:33,039
should be able to replace tor as a

861
00:29:33,039 --> 00:29:35,679
client not as a relay node but as a

862
00:29:35,679 --> 00:29:37,039
client

863
00:29:37,039 --> 00:29:38,840
we will after that begin working on

864
00:29:38,840 --> 00:29:41,600
relays bridges directory authorities and

865
00:29:41,600 --> 00:29:43,120
all these different services that we use

866
00:29:43,120 --> 00:29:44,640
in the network

867
00:29:44,640 --> 00:29:45,840
relays are going to be really

868
00:29:45,840 --> 00:29:47,360
interesting because of the the

869
00:29:47,360 --> 00:29:49,600
architecture of rd we will naturally get

870
00:29:49,600 --> 00:29:51,919
sort of a multi-threaded architecture

871
00:29:51,919 --> 00:29:53,039
and hopefully we will see some

872
00:29:53,039 --> 00:29:54,960
performance gains and notes because of

873
00:29:54,960 --> 00:29:57,520
that so people will

874
00:29:57,520 --> 00:30:00,159
avoid having to run multiple tour demons

875
00:30:00,159 --> 00:30:01,440
on their

876
00:30:01,440 --> 00:30:03,520
on their machines

877
00:30:03,520 --> 00:30:05,120
this of course have some implications

878
00:30:05,120 --> 00:30:07,760
for the what we can now call a legacy

879
00:30:07,760 --> 00:30:10,320
tour like the currently existing tour

880
00:30:10,320 --> 00:30:11,840
right now we have three out of seven of

881
00:30:11,840 --> 00:30:13,440
her team members is working full time on

882
00:30:13,440 --> 00:30:15,840
the rus and

883
00:30:15,840 --> 00:30:19,120
and rd related deliverables um our goal

884
00:30:19,120 --> 00:30:20,880
is to get the entire team over but we of

885
00:30:20,880 --> 00:30:22,960
course still have like deliverables we

886
00:30:22,960 --> 00:30:25,120
need to do and we also have to continue

887
00:30:25,120 --> 00:30:27,200
to support ctor for

888
00:30:27,200 --> 00:30:28,640
because it is the one that we ship in

889
00:30:28,640 --> 00:30:29,840
tor browse that is the one that's

890
00:30:29,840 --> 00:30:31,760
currently running the network right so

891
00:30:31,760 --> 00:30:33,279
we will not be able to just completely

892
00:30:33,279 --> 00:30:35,360
abandon the ship and and go do this

893
00:30:35,360 --> 00:30:37,039
other thing we're going to continue

894
00:30:37,039 --> 00:30:38,559
maintaining both in parallel for a

895
00:30:38,559 --> 00:30:40,960
little while but you will likely see a

896
00:30:40,960 --> 00:30:43,520
reduction in um

897
00:30:43,520 --> 00:30:45,679
in features that are going in

898
00:30:45,679 --> 00:30:47,039
with the exception of stuff that of

899
00:30:47,039 --> 00:30:48,640
course touches the network where we need

900
00:30:48,640 --> 00:30:50,480
it for for some of the other things like

901
00:30:50,480 --> 00:30:52,080
post-quantum cryptography and these kind

902
00:30:52,080 --> 00:30:54,399
of things

903
00:30:55,039 --> 00:30:56,480
one of the other exciting things that we

904
00:30:56,480 --> 00:30:59,519
are planning to do is udp support um we

905
00:30:59,519 --> 00:31:01,519
want to support these sort of more

906
00:31:01,519 --> 00:31:04,159
modern technologies such as uh like voip

907
00:31:04,159 --> 00:31:06,480
and webrtc we haven't there touching

908
00:31:06,480 --> 00:31:08,880
into that so far because like the the

909
00:31:08,880 --> 00:31:10,480
latency issue has been too hard like we

910
00:31:10,480 --> 00:31:11,919
need to solve performance before we need

911
00:31:11,919 --> 00:31:13,519
to go to this thing

912
00:31:13,519 --> 00:31:15,039
um

913
00:31:15,039 --> 00:31:17,440
the cool thing about that is with like

914
00:31:17,440 --> 00:31:19,200
with congestion control we are able to

915
00:31:19,200 --> 00:31:20,240
do this

916
00:31:20,240 --> 00:31:22,799
with only having to upgrade clients and

917
00:31:22,799 --> 00:31:25,120
the exit nodes like the middle nodes and

918
00:31:25,120 --> 00:31:27,279
the other parts don't have to upgrade so

919
00:31:27,279 --> 00:31:29,120
uh one thing i missed to say when i said

920
00:31:29,120 --> 00:31:30,799
that it was very nice all the operators

921
00:31:30,799 --> 00:31:33,120
upgraded was that we actually saw a much

922
00:31:33,120 --> 00:31:34,799
higher amount of people upgrading

923
00:31:34,799 --> 00:31:37,279
quickly who was exit node operators and

924
00:31:37,279 --> 00:31:39,519
that means that the congestion control

925
00:31:39,519 --> 00:31:41,120
part was available for the clients who

926
00:31:41,120 --> 00:31:42,799
had it earlier

927
00:31:42,799 --> 00:31:44,559
we will use the congestion control

928
00:31:44,559 --> 00:31:47,200
system to decide which packets to drop

929
00:31:47,200 --> 00:31:50,559
as you know with udp

930
00:31:50,559 --> 00:31:52,640
the the way most of the protocols is

931
00:31:52,640 --> 00:31:54,240
engineered is that you both have to take

932
00:31:54,240 --> 00:31:56,240
into account the mtu of the networks

933
00:31:56,240 --> 00:31:57,919
that you're traveling in but you also

934
00:31:57,919 --> 00:31:59,840
need to be aware that routers on your

935
00:31:59,840 --> 00:32:02,399
path might decide to drop an individual

936
00:32:02,399 --> 00:32:04,080
package if they are congested or

937
00:32:04,080 --> 00:32:05,440
whatever

938
00:32:05,440 --> 00:32:07,279
the way we are going to do it is

939
00:32:07,279 --> 00:32:08,880
historically we have been talking about

940
00:32:08,880 --> 00:32:10,799
doing this inter-relay communication

941
00:32:10,799 --> 00:32:12,640
over udp that is completely dropped with

942
00:32:12,640 --> 00:32:14,080
the congestion control stuff we're going

943
00:32:14,080 --> 00:32:15,760
to continue being a

944
00:32:15,760 --> 00:32:19,760
tcp over tls with tcp

945
00:32:19,760 --> 00:32:21,200
the way it works is that you will

946
00:32:21,200 --> 00:32:23,279
establish a normal tcp connection

947
00:32:23,279 --> 00:32:25,600
through your like guard and so on to the

948
00:32:25,600 --> 00:32:27,440
exit node and then instead of creating a

949
00:32:27,440 --> 00:32:30,000
tcp stream you have the option of doing

950
00:32:30,000 --> 00:32:33,120
a udp connection out from the exit node

951
00:32:33,120 --> 00:32:35,918
this will um

952
00:32:36,320 --> 00:32:38,559
this there's not any good options sort

953
00:32:38,559 --> 00:32:41,200
of um socks or these kind of things for

954
00:32:41,200 --> 00:32:43,360
udp even though

955
00:32:43,360 --> 00:32:45,440
it is specified by itf and so on that

956
00:32:45,440 --> 00:32:47,039
there is an option for it but most udp

957
00:32:47,039 --> 00:32:49,200
applications don't support it

958
00:32:49,200 --> 00:32:50,640
because of that we're going to start

959
00:32:50,640 --> 00:32:52,240
looking into

960
00:32:52,240 --> 00:32:55,519
having a vpn mode for tor

961
00:32:55,519 --> 00:32:57,600
as you know guardian project who does

962
00:32:57,600 --> 00:32:59,919
orbot on android already have this it

963
00:32:59,919 --> 00:33:01,519
only supports tcp and it's sort of

964
00:33:01,519 --> 00:33:03,279
limited by the functionality that exists

965
00:33:03,279 --> 00:33:05,600
in tor we're going to build from scratch

966
00:33:05,600 --> 00:33:07,600
with rd um

967
00:33:07,600 --> 00:33:09,679
like an application which is essentially

968
00:33:09,679 --> 00:33:11,360
a vpn

969
00:33:11,360 --> 00:33:13,120
the goal is to release at some point in

970
00:33:13,120 --> 00:33:15,440
2023 i would guess it's going to be in

971
00:33:15,440 --> 00:33:17,440
the late part of 2023 but i don't

972
00:33:17,440 --> 00:33:19,360
remember the the deliverable dates

973
00:33:19,360 --> 00:33:21,279
exactly

974
00:33:21,279 --> 00:33:23,440
to do this we're doing a

975
00:33:23,440 --> 00:33:26,240
small component called onion mask the

976
00:33:26,240 --> 00:33:27,760
way it essentially works is that you

977
00:33:27,760 --> 00:33:29,840
should see it as a net router the way

978
00:33:29,840 --> 00:33:31,840
most net routers works for udp is that

979
00:33:31,840 --> 00:33:33,840
they need to sort of see a udp package

980
00:33:33,840 --> 00:33:35,600
stream as sort of being a little bit

981
00:33:35,600 --> 00:33:37,519
stateful despite that we teach people

982
00:33:37,519 --> 00:33:39,600
that udp is stateless

983
00:33:39,600 --> 00:33:41,440
so what this library will be doing is

984
00:33:41,440 --> 00:33:42,320
that

985
00:33:42,320 --> 00:33:44,640
it will read and write ip packets from

986
00:33:44,640 --> 00:33:46,640
these 10 devices that exist on the

987
00:33:46,640 --> 00:33:48,240
platform

988
00:33:48,240 --> 00:33:50,240
it will be handling multiplexing

989
00:33:50,240 --> 00:33:53,360
incoming tcp and udp flows to rd's

990
00:33:53,360 --> 00:33:54,880
circuit interface and sort of making

991
00:33:54,880 --> 00:33:57,679
sure that things get transported

992
00:33:57,679 --> 00:34:00,159
we we will do onion services a bit like

993
00:34:00,159 --> 00:34:02,320
the dns port works if you're like a cube

994
00:34:02,320 --> 00:34:04,399
user or something like that the way

995
00:34:04,399 --> 00:34:06,640
you use tor there is that you have a

996
00:34:06,640 --> 00:34:08,480
fake dns server which gives you like a

997
00:34:08,480 --> 00:34:09,440
token

998
00:34:09,440 --> 00:34:11,359
um when you try to connect to a dot

999
00:34:11,359 --> 00:34:13,040
onion and uh

1000
00:34:13,040 --> 00:34:14,879
that token can be like and a

1001
00:34:14,879 --> 00:34:17,520
specifically ipv4 network or a larger

1002
00:34:17,520 --> 00:34:19,679
ipv6 network and then when it sees

1003
00:34:19,679 --> 00:34:20,879
connection going to one of those

1004
00:34:20,879 --> 00:34:22,879
magically mapped ip addresses it will

1005
00:34:22,879 --> 00:34:24,159
accept your connection to the onion

1006
00:34:24,159 --> 00:34:25,839
service instead

1007
00:34:25,839 --> 00:34:27,918
we also need to do some basic filtering

1008
00:34:27,918 --> 00:34:30,000
um like that i don't want applications

1009
00:34:30,000 --> 00:34:31,359
to this endpoint or i don't want

1010
00:34:31,359 --> 00:34:35,679
applications from this this source point

1011
00:34:35,679 --> 00:34:37,280
usually when you use netstat and stuff

1012
00:34:37,280 --> 00:34:38,480
like that you're used to looking at

1013
00:34:38,480 --> 00:34:40,079
these five tuples like you have the

1014
00:34:40,079 --> 00:34:43,440
source address source port target port

1015
00:34:43,440 --> 00:34:45,440
and target address and of course the

1016
00:34:45,440 --> 00:34:48,399
protocol whether it's tcp or udp we need

1017
00:34:48,399 --> 00:34:50,399
to populate a little bit more metadata

1018
00:34:50,399 --> 00:34:52,320
to be able to do isolation primitives

1019
00:34:52,320 --> 00:34:54,079
properly as you know in tor browser we

1020
00:34:54,079 --> 00:34:56,560
isolate like tabs and like the origin of

1021
00:34:56,560 --> 00:34:58,480
the website so that they cannot sort of

1022
00:34:58,480 --> 00:35:01,200
see that they're coming from the same

1023
00:35:01,200 --> 00:35:03,040
what we have identified that we is

1024
00:35:03,040 --> 00:35:04,960
hopefully able to do on modern android

1025
00:35:04,960 --> 00:35:08,160
is that we can get the application uuid

1026
00:35:08,160 --> 00:35:10,480
um a hostname that is the target and

1027
00:35:10,480 --> 00:35:12,640
also the dns cookie that is that is

1028
00:35:12,640 --> 00:35:15,359
available here

1029
00:35:15,359 --> 00:35:17,280
so we're getting towards the end

1030
00:35:17,280 --> 00:35:19,280
if you want to help the tour project in

1031
00:35:19,280 --> 00:35:20,880
any way you can run tor relays or

1032
00:35:20,880 --> 00:35:23,359
bridges you can teach others about tor

1033
00:35:23,359 --> 00:35:25,359
and like these things that excite you

1034
00:35:25,359 --> 00:35:26,640
about privacy

1035
00:35:26,640 --> 00:35:29,119
finding and fixing bugs for us is really

1036
00:35:29,119 --> 00:35:31,680
nice there are some features that we

1037
00:35:31,680 --> 00:35:32,640
or or

1038
00:35:32,640 --> 00:35:34,240
minor annoyances

1039
00:35:34,240 --> 00:35:36,079
that we don't have time to do because we

1040
00:35:36,079 --> 00:35:37,359
also have all the like research

1041
00:35:37,359 --> 00:35:38,960
deliverables and grants and so on that

1042
00:35:38,960 --> 00:35:40,240
we need to do

1043
00:35:40,240 --> 00:35:42,640
so we love getting help from volunteers

1044
00:35:42,640 --> 00:35:45,359
and with rd it seems like the volunteers

1045
00:35:45,359 --> 00:35:47,119
it's gonna be it's getting easier to to

1046
00:35:47,119 --> 00:35:49,599
contribute to these parts with uh

1047
00:35:49,599 --> 00:35:51,440
when we sort of leave the dc code a

1048
00:35:51,440 --> 00:35:52,960
little bit behind

1049
00:35:52,960 --> 00:35:54,480
you can of course also donate to our

1050
00:35:54,480 --> 00:35:55,920
project at the end of the years we

1051
00:35:55,920 --> 00:35:57,040
usually have these things where you can

1052
00:35:57,040 --> 00:36:00,320
donate and get a t-shirt and so on

1053
00:36:00,320 --> 00:36:03,280
for the relay operators in the room

1054
00:36:03,280 --> 00:36:05,359
we have a meet-up tonight in the sea

1055
00:36:05,359 --> 00:36:06,800
base tent

1056
00:36:06,800 --> 00:36:09,040
it's at 21 and we'll meet and talk a bit

1057
00:36:09,040 --> 00:36:10,640
about what's going on and people can ask

1058
00:36:10,640 --> 00:36:13,359
questions and like we can have a bit of

1059
00:36:13,359 --> 00:36:14,560
a chat about

1060
00:36:14,560 --> 00:36:16,400
what's going on in the relay operators

1061
00:36:16,400 --> 00:36:18,880
community

1062
00:36:18,960 --> 00:36:21,520
that was all for me i have

1063
00:36:21,520 --> 00:36:26,440
some times for questions i believe um

1064
00:36:26,550 --> 00:36:37,159
[Applause]

1065
00:36:38,960 --> 00:36:40,960
uh now you can

1066
00:36:40,960 --> 00:36:42,880
thank you very much for the talk it was

1067
00:36:42,880 --> 00:36:44,800
very interesting also for me personally

1068
00:36:44,800 --> 00:36:46,320
i think

1069
00:36:46,320 --> 00:36:49,680
for most of the people in the room uh

1070
00:36:49,680 --> 00:36:51,680
too since uh

1071
00:36:51,680 --> 00:36:53,839
barely none left

1072
00:36:53,839 --> 00:36:56,160
so

1073
00:36:56,160 --> 00:37:01,599
now i see we are queuing up uh

1074
00:37:01,599 --> 00:37:04,240
let's start with uh

1075
00:37:04,240 --> 00:37:06,960
the mic at the front please

1076
00:37:06,960 --> 00:37:09,359
hi i wonder are you using or are you

1077
00:37:09,359 --> 00:37:11,520
planning to use quick for transporting

1078
00:37:11,520 --> 00:37:13,040
data uh

1079
00:37:13,040 --> 00:37:14,560
in future

1080
00:37:14,560 --> 00:37:16,640
uh you're thinking about the inter relay

1081
00:37:16,640 --> 00:37:19,920
communication yes so quick was when we

1082
00:37:19,920 --> 00:37:21,280
when we started the congestion control

1083
00:37:21,280 --> 00:37:23,040
project quick was considered because

1084
00:37:23,040 --> 00:37:24,800
quick comes with the dome mechanism for

1085
00:37:24,800 --> 00:37:26,800
both defining the cryptography like

1086
00:37:26,800 --> 00:37:28,880
roaming and the congestion control it

1087
00:37:28,880 --> 00:37:30,480
was evaluated but we

1088
00:37:30,480 --> 00:37:32,800
it would it was a significant easier way

1089
00:37:32,800 --> 00:37:34,640
for us to upgrade just the congestion

1090
00:37:34,640 --> 00:37:36,720
control at the end point over tcp

1091
00:37:36,720 --> 00:37:38,880
because most of the network is connected

1092
00:37:38,880 --> 00:37:41,200
on like good lines on like the internet

1093
00:37:41,200 --> 00:37:43,520
lag in data centers and so on so quick

1094
00:37:43,520 --> 00:37:45,359
was evaluated but we decided not to go

1095
00:37:45,359 --> 00:37:47,839
with it there is a research group in

1096
00:37:47,839 --> 00:37:49,680
cambridge before quick was the thing

1097
00:37:49,680 --> 00:37:53,440
that did a tour version where it does um

1098
00:37:53,440 --> 00:37:56,240
dtls over udp between the inter

1099
00:37:56,240 --> 00:37:58,560
communication there between relays and

1100
00:37:58,560 --> 00:38:00,480
we looked at it and it seemed more

1101
00:38:00,480 --> 00:38:03,440
natural to upgrade tcp because

1102
00:38:03,440 --> 00:38:05,839
we are very familiar with tcp sort of in

1103
00:38:05,839 --> 00:38:08,079
general right thanks no problem

1104
00:38:08,079 --> 00:38:11,359
um okay thank you for your question then

1105
00:38:11,359 --> 00:38:16,000
we go to the back microphone

1106
00:38:16,000 --> 00:38:17,520
hi

1107
00:38:17,520 --> 00:38:19,920
thank you for a very nice talk

1108
00:38:19,920 --> 00:38:23,119
um some context four years ago around

1109
00:38:23,119 --> 00:38:24,960
four years ago there was a certain

1110
00:38:24,960 --> 00:38:26,960
middle eastern country that

1111
00:38:26,960 --> 00:38:29,040
was trying to block telegram

1112
00:38:29,040 --> 00:38:32,800
huh i can almost not hear you

1113
00:38:32,800 --> 00:38:35,040
can you hear me now yes yeah

1114
00:38:35,040 --> 00:38:37,040
speak up a bit yes it's fine okay so

1115
00:38:37,040 --> 00:38:38,400
four years ago there was a certain

1116
00:38:38,400 --> 00:38:40,320
middle eastern country that was in the

1117
00:38:40,320 --> 00:38:42,560
middle of an upheaval and they tried to

1118
00:38:42,560 --> 00:38:43,520
block

1119
00:38:43,520 --> 00:38:45,040
telegram access

1120
00:38:45,040 --> 00:38:47,119
for people to prevent them to organize

1121
00:38:47,119 --> 00:38:50,160
from organizing and as a result sciphone

1122
00:38:50,160 --> 00:38:53,359
had a huge uptick in bandwidth and as a

1123
00:38:53,359 --> 00:38:56,000
result to that they started blocking the

1124
00:38:56,000 --> 00:38:57,200
providers

1125
00:38:57,200 --> 00:38:58,720
of iphone

1126
00:38:58,720 --> 00:39:02,320
aws ip blocks etc

1127
00:39:02,320 --> 00:39:05,440
the graph that you showed

1128
00:39:05,440 --> 00:39:08,320
that showed an uptick of bandwidth

1129
00:39:08,320 --> 00:39:10,000
kind of correlates to a certain big

1130
00:39:10,000 --> 00:39:12,880
event which is which started

1131
00:39:12,880 --> 00:39:15,119
recently

1132
00:39:15,119 --> 00:39:16,960
yes that one yes

1133
00:39:16,960 --> 00:39:18,640
so if i'm i'm i'm not really seeing the

1134
00:39:18,640 --> 00:39:21,200
months there but we are in 2022 another

1135
00:39:21,200 --> 00:39:23,520
that one the at the end right

1136
00:39:23,520 --> 00:39:26,160
yeah 20 this is uh at the where we are

1137
00:39:26,160 --> 00:39:29,200
now the very end

1138
00:39:29,200 --> 00:39:31,280
uh okay but if i'm looking that

1139
00:39:31,280 --> 00:39:33,040
correctly the big uptick started

1140
00:39:33,040 --> 00:39:34,480
somewhere around

1141
00:39:34,480 --> 00:39:37,440
april march april yes

1142
00:39:37,440 --> 00:39:39,760
um okay i see some correlation with the

1143
00:39:39,760 --> 00:39:41,599
current events which are happening on

1144
00:39:41,599 --> 00:39:43,920
european soil and another large country

1145
00:39:43,920 --> 00:39:46,000
which is trying to again block its

1146
00:39:46,000 --> 00:39:48,960
people from getting access to uh well

1147
00:39:48,960 --> 00:39:52,160
organizing power and and information so

1148
00:39:52,160 --> 00:39:54,240
there's i see some correlation but is

1149
00:39:54,240 --> 00:39:56,079
there actually any causation have you

1150
00:39:56,079 --> 00:39:57,920
investigated and also the the ddos

1151
00:39:57,920 --> 00:40:00,079
attacks that you mentioned could that be

1152
00:40:00,079 --> 00:40:02,320
also in response to people maybe trying

1153
00:40:02,320 --> 00:40:03,599
to use store

1154
00:40:03,599 --> 00:40:05,680
i think if there was a correlation then

1155
00:40:05,680 --> 00:40:07,119
either our congestion control stuff

1156
00:40:07,119 --> 00:40:09,440
doesn't work which i i would be uh very

1157
00:40:09,440 --> 00:40:11,280
sad about but the interesting plot is

1158
00:40:11,280 --> 00:40:13,040
more this one because that is what the

1159
00:40:13,040 --> 00:40:14,480
traffic has that has actually been

1160
00:40:14,480 --> 00:40:16,960
utilized this is just what we observe

1161
00:40:16,960 --> 00:40:19,680
that is available in the network so this

1162
00:40:19,680 --> 00:40:21,760
bumper and the utilization fits

1163
00:40:21,760 --> 00:40:23,200
extremely well with the tor browser

1164
00:40:23,200 --> 00:40:24,560
release and the availability of

1165
00:40:24,560 --> 00:40:26,079
congestion control so i don't think

1166
00:40:26,079 --> 00:40:28,960
those two things are related if i had

1167
00:40:28,960 --> 00:40:29,680
i

1168
00:40:29,680 --> 00:40:31,359
usually also have a plot in my slides

1169
00:40:31,359 --> 00:40:32,960
that describes

1170
00:40:32,960 --> 00:40:35,280
traffic coming in for bridges we would

1171
00:40:35,280 --> 00:40:37,359
be able to there see

1172
00:40:37,359 --> 00:40:38,560
the

1173
00:40:38,560 --> 00:40:40,880
the sort of the guip of the incoming

1174
00:40:40,880 --> 00:40:42,880
clients batched up in these small

1175
00:40:42,880 --> 00:40:44,160
buckets

1176
00:40:44,160 --> 00:40:46,160
um i think if you go to metrics to our

1177
00:40:46,160 --> 00:40:47,839
project.org you will be able to see it

1178
00:40:47,839 --> 00:40:49,280
more specifically to the country and

1179
00:40:49,280 --> 00:40:50,960
then i think you would be able to make

1180
00:40:50,960 --> 00:40:52,800
probably a better conclusion than based

1181
00:40:52,800 --> 00:40:54,319
on looking at the global state here in

1182
00:40:54,319 --> 00:40:56,560
the network yes excellent i was trying

1183
00:40:56,560 --> 00:40:58,240
to detract from the program no no no no

1184
00:40:58,240 --> 00:40:59,920
that's fine excellent thank you it's a

1185
00:40:59,920 --> 00:41:02,720
good question um okay let's go to the

1186
00:41:02,720 --> 00:41:04,319
front mic thank you

1187
00:41:04,319 --> 00:41:06,720
hi there thanks uh for the talk it's uh

1188
00:41:06,720 --> 00:41:08,400
quite good and thanks for your work it's

1189
00:41:08,400 --> 00:41:11,040
uh it's very important um i do have a

1190
00:41:11,040 --> 00:41:12,800
question about trade-offs because you

1191
00:41:12,800 --> 00:41:14,800
did have your uh your survey there you

1192
00:41:14,800 --> 00:41:16,800
had the slide it said

1193
00:41:16,800 --> 00:41:19,440
we think speed is more important than

1194
00:41:19,440 --> 00:41:21,119
privacy

1195
00:41:21,119 --> 00:41:23,119
and then two sl two slides later you had

1196
00:41:23,119 --> 00:41:25,599
the thing about quantum handshakes which

1197
00:41:25,599 --> 00:41:28,640
of course are larger and uh that means

1198
00:41:28,640 --> 00:41:30,720
that will decrease speed so there are

1199
00:41:30,720 --> 00:41:32,560
some trade-offs you have to make there i

1200
00:41:32,560 --> 00:41:35,280
assume so how is that uh decision how is

1201
00:41:35,280 --> 00:41:36,640
that made

1202
00:41:36,640 --> 00:41:38,400
so of course um

1203
00:41:38,400 --> 00:41:40,480
this is not the kind of survey where the

1204
00:41:40,480 --> 00:41:42,480
end result is that we uh drop everything

1205
00:41:42,480 --> 00:41:44,079
we have in our hands and then only focus

1206
00:41:44,079 --> 00:41:46,000
on speed and then like the privacy

1207
00:41:46,000 --> 00:41:47,280
like that that would not be the thing

1208
00:41:47,280 --> 00:41:48,960
right um

1209
00:41:48,960 --> 00:41:50,960
so the the thing with the handshakes

1210
00:41:50,960 --> 00:41:53,119
remember that the handshakes

1211
00:41:53,119 --> 00:41:55,119
you you establish a circuit to the exit

1212
00:41:55,119 --> 00:41:56,800
node there you have the number of

1213
00:41:56,800 --> 00:41:58,640
handshakes but from the exit node you

1214
00:41:58,640 --> 00:42:00,720
can create multiple streams out from

1215
00:42:00,720 --> 00:42:02,880
there so the cost of these additional

1216
00:42:02,880 --> 00:42:04,720
handshakes both in terms of computation

1217
00:42:04,720 --> 00:42:07,119
power but also in transport is is not

1218
00:42:07,119 --> 00:42:09,920
that important in this it's actually

1219
00:42:09,920 --> 00:42:11,839
it until we also started having it in

1220
00:42:11,839 --> 00:42:13,920
tls which is likely going to happen very

1221
00:42:13,920 --> 00:42:15,359
soon like both google and cloudflare

1222
00:42:15,359 --> 00:42:17,760
have done experiments with that um

1223
00:42:17,760 --> 00:42:20,560
this cost is very minimal to the entire

1224
00:42:20,560 --> 00:42:22,480
part of the network but you are right

1225
00:42:22,480 --> 00:42:24,560
everything we do has to sort of balance

1226
00:42:24,560 --> 00:42:25,680
like are we doing something that

1227
00:42:25,680 --> 00:42:27,680
potentially has performance impact the

1228
00:42:27,680 --> 00:42:30,000
proof of work stuff historically on

1229
00:42:30,000 --> 00:42:32,480
apple ios platform we've been suffering

1230
00:42:32,480 --> 00:42:34,000
because network extension has a

1231
00:42:34,000 --> 00:42:36,640
ridiculously low memory limit

1232
00:42:36,640 --> 00:42:38,319
far smaller than what we were able to do

1233
00:42:38,319 --> 00:42:40,480
they recently bumped it in like version

1234
00:42:40,480 --> 00:42:43,040
15 or whatever it is

1235
00:42:43,040 --> 00:42:44,640
and there we sort of need to be sure

1236
00:42:44,640 --> 00:42:47,119
like can we even do like a like a memory

1237
00:42:47,119 --> 00:42:48,880
ballooning kind of proof of work there

1238
00:42:48,880 --> 00:42:51,040
because if we just have a network

1239
00:42:51,040 --> 00:42:52,480
extension and we run out of memory then

1240
00:42:52,480 --> 00:42:54,079
torque closes and everything just flows

1241
00:42:54,079 --> 00:42:55,839
over to the internet right so yes there

1242
00:42:55,839 --> 00:42:57,599
is a lot of sort of analysis being done

1243
00:42:57,599 --> 00:43:00,000
to what are the impacts

1244
00:43:00,000 --> 00:43:03,119
of the features that we're doing

1245
00:43:03,119 --> 00:43:05,440
thanks for the question and now we go

1246
00:43:05,440 --> 00:43:08,880
back again to the back mike

1247
00:43:08,880 --> 00:43:10,560
thank you for the talk

1248
00:43:10,560 --> 00:43:13,040
um i had a question about the conflux

1249
00:43:13,040 --> 00:43:15,359
the multipath uh

1250
00:43:15,359 --> 00:43:16,400
feature

1251
00:43:16,400 --> 00:43:17,920
and i was wondering if it had any

1252
00:43:17,920 --> 00:43:20,000
security implications for kind of

1253
00:43:20,000 --> 00:43:22,079
correlation timing attacks absolutely

1254
00:43:22,079 --> 00:43:23,760
and like everything we modify and these

1255
00:43:23,760 --> 00:43:25,200
kind of things needs to have pretty deep

1256
00:43:25,200 --> 00:43:27,200
analysis done to them on sort of

1257
00:43:27,200 --> 00:43:29,280
correlation factors and there's also

1258
00:43:29,280 --> 00:43:31,040
like all these papers about

1259
00:43:31,040 --> 00:43:32,640
choosing the guards and we have like

1260
00:43:32,640 --> 00:43:34,240
this new system called vanguards that

1261
00:43:34,240 --> 00:43:37,040
also implies implic is implicated here

1262
00:43:37,040 --> 00:43:38,000
um

1263
00:43:38,000 --> 00:43:39,680
the paper

1264
00:43:39,680 --> 00:43:41,440
that

1265
00:43:41,440 --> 00:43:43,040
that you can read here the path less

1266
00:43:43,040 --> 00:43:44,960
traveled overcoming towards bottlenecks

1267
00:43:44,960 --> 00:43:46,880
with traffic splitting has some of that

1268
00:43:46,880 --> 00:43:48,480
analysis and we're probably going to

1269
00:43:48,480 --> 00:43:50,240
discover more things as we as we

1270
00:43:50,240 --> 00:43:52,640
engineered so absolutely every time we

1271
00:43:52,640 --> 00:43:55,440
modify anything on anything related to

1272
00:43:55,440 --> 00:43:57,839
incoming flows and outgoing flows it has

1273
00:43:57,839 --> 00:43:59,520
to have some pretty deep analysis done

1274
00:43:59,520 --> 00:44:00,800
to it

1275
00:44:00,800 --> 00:44:01,920
thank you

1276
00:44:01,920 --> 00:44:04,960
thanks for your question and now

1277
00:44:04,960 --> 00:44:08,560
to the question in the front mic

1278
00:44:08,560 --> 00:44:10,800
thanks alexander great talk

1279
00:44:10,800 --> 00:44:12,880
i couldn't really follow the udp part

1280
00:44:12,880 --> 00:44:14,640
you said you had a

1281
00:44:14,640 --> 00:44:16,720
trick that

1282
00:44:16,720 --> 00:44:19,839
you had a dns cookie that you use is

1283
00:44:19,839 --> 00:44:22,240
that just purely for the exit relay in

1284
00:44:22,240 --> 00:44:25,280
order to track udp connections

1285
00:44:25,280 --> 00:44:26,400
no

1286
00:44:26,400 --> 00:44:29,280
the dns cookie is for onion services

1287
00:44:29,280 --> 00:44:30,480
only

1288
00:44:30,480 --> 00:44:32,000
it's only used for onion services

1289
00:44:32,000 --> 00:44:35,200
because onion services are a host name

1290
00:44:35,200 --> 00:44:37,599
but like when we're working on layer 3

1291
00:44:37,599 --> 00:44:39,760
we need to have ip addresses so the idea

1292
00:44:39,760 --> 00:44:41,359
there is the dns server will respond

1293
00:44:41,359 --> 00:44:44,160
with like some fake long ipv6 address

1294
00:44:44,160 --> 00:44:46,240
then when you make a connection into the

1295
00:44:46,240 --> 00:44:48,640
software net router onion mask then it

1296
00:44:48,640 --> 00:44:50,319
will be able to look up and say hey it's

1297
00:44:50,319 --> 00:44:52,079
a connection to this onion addresses

1298
00:44:52,079 --> 00:44:53,680
establish a torch circuit to that

1299
00:44:53,680 --> 00:44:56,160
instead and you don't need it for tcp

1300
00:44:56,160 --> 00:44:56,960
right

1301
00:44:56,960 --> 00:44:59,040
yes we need it for tcp

1302
00:44:59,040 --> 00:45:00,560
as well for onion addresses because you

1303
00:45:00,560 --> 00:45:03,680
also and tcp is also on ip level

1304
00:45:03,680 --> 00:45:05,839
the

1305
00:45:06,400 --> 00:45:08,240
the udp part the reason that we need a

1306
00:45:08,240 --> 00:45:10,720
vpn for for the udp but the trick there

1307
00:45:10,720 --> 00:45:12,160
is

1308
00:45:12,160 --> 00:45:14,800
is that we don't have any applications

1309
00:45:14,800 --> 00:45:17,040
don't support any protocol that allow us

1310
00:45:17,040 --> 00:45:19,520
to proxy udp traffic

1311
00:45:19,520 --> 00:45:21,760
despite like i think sucks five has a

1312
00:45:21,760 --> 00:45:24,319
way to both do sort of service endpoints

1313
00:45:24,319 --> 00:45:27,040
and uh just like connectivity outwards

1314
00:45:27,040 --> 00:45:29,280
over udp but like none of the

1315
00:45:29,280 --> 00:45:31,119
applications seems to be using it okay

1316
00:45:31,119 --> 00:45:32,960
thank you no problem

1317
00:45:32,960 --> 00:45:34,560
and uh

1318
00:45:34,560 --> 00:45:37,599
back to the back mic

1319
00:45:38,880 --> 00:45:41,040
it's not on like on

1320
00:45:41,040 --> 00:45:43,359
now so the current version of taurus is

1321
00:45:43,359 --> 00:45:46,000
0.4.7

1322
00:45:46,000 --> 00:45:49,119
been wondering why it's not a one dot

1323
00:45:49,119 --> 00:45:51,359
etc version is there a specific reason

1324
00:45:51,359 --> 00:45:52,800
for that

1325
00:45:52,800 --> 00:45:54,480
there's so many free software projects

1326
00:45:54,480 --> 00:45:57,200
you could ask that question um

1327
00:45:57,200 --> 00:45:59,359
no no there's not um

1328
00:45:59,359 --> 00:46:00,560
like um

1329
00:46:00,560 --> 00:46:02,640
i i'm personally a big fan of these

1330
00:46:02,640 --> 00:46:05,119
identifiers where you use like a year

1331
00:46:05,119 --> 00:46:07,599
and a name but uh like my team is

1332
00:46:07,599 --> 00:46:08,800
probably if they're watching this will

1333
00:46:08,800 --> 00:46:10,160
probably say no we're never gonna do

1334
00:46:10,160 --> 00:46:12,880
that um we've just sort of continued

1335
00:46:12,880 --> 00:46:15,200
doing it we don't i don't even think we

1336
00:46:15,200 --> 00:46:18,240
bump it i think we went from 0.35 to oh

1337
00:46:18,240 --> 00:46:19,520
for

1338
00:46:19,520 --> 00:46:23,119
zero um so so there's not a great system

1339
00:46:23,119 --> 00:46:24,400
it's just like hey now we've done like

1340
00:46:24,400 --> 00:46:26,880
some nice features let's bump the

1341
00:46:26,880 --> 00:46:29,680
the middle identifier up um so now we

1342
00:46:29,680 --> 00:46:31,760
with rd we are probably going to quickly

1343
00:46:31,760 --> 00:46:33,920
try to get up to 1.0 and then start

1344
00:46:33,920 --> 00:46:35,839
doing like more aggressively in the in

1345
00:46:35,839 --> 00:46:37,839
the modern uh versioning scheme of

1346
00:46:37,839 --> 00:46:39,440
software

1347
00:46:39,440 --> 00:46:41,359
okay thanks no problem

1348
00:46:41,359 --> 00:46:45,920
um okay then one question from the front

1349
00:46:45,920 --> 00:46:47,440
mic and

1350
00:46:47,440 --> 00:46:48,720
uh

1351
00:46:48,720 --> 00:46:51,119
we have nothing from the internet if i

1352
00:46:51,119 --> 00:46:52,480
see correctly

1353
00:46:52,480 --> 00:46:55,359
and this would be the last question for

1354
00:46:55,359 --> 00:46:57,200
now

1355
00:46:57,200 --> 00:46:58,400
hi

1356
00:46:58,400 --> 00:47:00,160
i'm very excited about the rust

1357
00:47:00,160 --> 00:47:02,240
implementation

1358
00:47:02,240 --> 00:47:04,480
but i'm also a little bit worried about

1359
00:47:04,480 --> 00:47:07,040
putting all development effort this

1360
00:47:07,040 --> 00:47:09,599
early on to this specific implementation

1361
00:47:09,599 --> 00:47:11,920
because there is precedence of other

1362
00:47:11,920 --> 00:47:15,200
projects which just have a very well

1363
00:47:15,200 --> 00:47:17,040
maintained code base and they just want

1364
00:47:17,040 --> 00:47:19,040
to throw it all over and try to build

1365
00:47:19,040 --> 00:47:21,119
something new and then years later they

1366
00:47:21,119 --> 00:47:23,040
are still working on the old code base

1367
00:47:23,040 --> 00:47:26,880
and the new one didn't really catch on

1368
00:47:27,119 --> 00:47:29,200
it's a cost benefit right you need to

1369
00:47:29,200 --> 00:47:30,800
sit down and look at what are the risks

1370
00:47:30,800 --> 00:47:32,559
of doing this um

1371
00:47:32,559 --> 00:47:35,040
will we be able to in 10 years be able

1372
00:47:35,040 --> 00:47:37,359
as an ngo that is not paying sort of the

1373
00:47:37,359 --> 00:47:39,200
same kind of salaries that that like

1374
00:47:39,200 --> 00:47:40,559
these software engineering companies are

1375
00:47:40,559 --> 00:47:41,520
doing

1376
00:47:41,520 --> 00:47:43,520
will we be able to hire really good c

1377
00:47:43,520 --> 00:47:45,280
programmers that gives the guarantees

1378
00:47:45,280 --> 00:47:47,200
that we want to provide like will the

1379
00:47:47,200 --> 00:47:48,880
will the young and upcoming hackers will

1380
00:47:48,880 --> 00:47:51,280
they be sitting and reading knr books

1381
00:47:51,280 --> 00:47:53,599
about c or will they be doing rust or

1382
00:47:53,599 --> 00:47:55,839
python or haskell or something else so

1383
00:47:55,839 --> 00:47:57,280
there is a little bit of

1384
00:47:57,280 --> 00:47:59,280
a modernization

1385
00:47:59,280 --> 00:48:01,200
thought to it as well added with that

1386
00:48:01,200 --> 00:48:03,359
the team also had an interest with doing

1387
00:48:03,359 --> 00:48:04,640
that

1388
00:48:04,640 --> 00:48:07,040
i had a talk at shah where i was talking

1389
00:48:07,040 --> 00:48:09,200
about my pet project which was a tour

1390
00:48:09,200 --> 00:48:12,400
implementation in erlang um and i like

1391
00:48:12,400 --> 00:48:13,680
i've completely abandoned that because

1392
00:48:13,680 --> 00:48:15,760
now i'm spending all my time on on sea

1393
00:48:15,760 --> 00:48:18,720
tour right and and our new rust efforts

1394
00:48:18,720 --> 00:48:21,440
so yes there is absolutely a risk to

1395
00:48:21,440 --> 00:48:22,880
that um

1396
00:48:22,880 --> 00:48:25,200
we we hope we won't fail

1397
00:48:25,200 --> 00:48:27,359
that is uh that is the thing

1398
00:48:27,359 --> 00:48:28,640
and um

1399
00:48:28,640 --> 00:48:31,359
but there's a lot of momentum in the

1400
00:48:31,359 --> 00:48:33,040
in the organization and also from the

1401
00:48:33,040 --> 00:48:34,559
partners that we have

1402
00:48:34,559 --> 00:48:37,119
with solving some of these very holistic

1403
00:48:37,119 --> 00:48:39,200
issues with like tours not a library

1404
00:48:39,200 --> 00:48:41,040
right now is a freaking nightmare to

1405
00:48:41,040 --> 00:48:43,280
integrate into anything

1406
00:48:43,280 --> 00:48:44,720
and we hope that

1407
00:48:44,720 --> 00:48:46,720
we already see that people want to test

1408
00:48:46,720 --> 00:48:48,800
stuff even though we are not feeling

1409
00:48:48,800 --> 00:48:50,240
like ready you shouldn't be using this

1410
00:48:50,240 --> 00:48:53,200
yet um so we hope that will uh that we

1411
00:48:53,200 --> 00:48:54,640
will also be able to get some help also

1412
00:48:54,640 --> 00:48:56,960
from the greater communities

1413
00:48:56,960 --> 00:48:58,559
thank you

1414
00:48:58,559 --> 00:49:02,559
um yeah with that um i would kindly ask

1415
00:49:02,559 --> 00:49:06,079
you to give it up for alex

1416
00:49:12,319 --> 00:49:15,319
and

1417
00:49:18,800 --> 00:49:20,880
you