1
00:00:00,000 --> 00:00:16,300
Music
Herald: The next talk coming up is going
2
00:00:16,300 --> 00:00:20,770
to be "Practical mix network designs,
strong metadata protection for
3
00:00:20,770 --> 00:00:28,990
asynchronous messaging", held by by David,
who has done research on mix networks and
4
00:00:28,990 --> 00:00:35,530
is a contributor to Tor network, and by
Jeff, who has done contribution to the GNU
5
00:00:35,530 --> 00:00:40,420
network project, organized a couple of
sessions for this on last year's Congress
6
00:00:40,420 --> 00:00:46,280
and is basically a mathematician, trying
to get practical. they're going to talk
7
00:00:46,280 --> 00:00:54,879
about components on mix networks and
defenses that basically Tor can't do. And,
8
00:00:54,879 --> 00:01:03,010
yeah. Welcome with a big round of
applause, okay.
9
00:01:03,010 --> 00:01:12,229
applause
Jeff: Okay, so I'm Jeff, this is David,
10
00:01:12,229 --> 00:01:16,549
we're going to be telling you some, we're
going to be telling you some aspects about
11
00:01:16,549 --> 00:01:22,520
designing mix networks. The, I'm involved
with the I'm an academic involved with the
12
00:01:22,520 --> 00:01:30,820
GNUnet project, he's involved with the
Panoramix project. Okay, so first of all
13
00:01:30,820 --> 00:01:37,820
we, just to be clear, of course encryption
works, you know, if it's, you know,
14
00:01:37,820 --> 00:01:42,270
properly implemented and then, you know,
we have a huge amount of trust in it, we
15
00:01:42,270 --> 00:01:46,490
we even have, you know, sort of slides
showing that the most powerful adversaries
16
00:01:46,490 --> 00:01:51,240
in the world can't can't can't break these
things, so this is fine.
17
00:01:51,240 --> 00:01:57,100
However we have to worry about sort of
about the metadata leakage or and in this
18
00:01:57,100 --> 00:02:01,370
talk we're specifically going to be
worrying about traffic analysis of of
19
00:02:01,370 --> 00:02:08,650
connections. inhales So, yeah, it's time
to, it's time to actually start addressing
20
00:02:08,650 --> 00:02:14,610
these things. Okay. So existing solutions
to traffic analysis. So there's this
21
00:02:14,610 --> 00:02:22,420
wonderful Tor Tor program and project and
they we we know as of five years ago they
22
00:02:22,420 --> 00:02:29,030
consider the the even the NSA considered
considered Tor to be quite effective at
23
00:02:29,030 --> 00:02:35,510
preventing mass location tracking. So this
is, so Tor works for what it's designed to
24
00:02:35,510 --> 00:02:44,840
do, Tor does not protect against an
adversary who can see both ends of the Tor
25
00:02:44,840 --> 00:02:51,800
circuit, so this this is this is a
handicap in a number of situ- in a number
26
00:02:51,800 --> 00:02:59,400
of situation, so the first situation is if
if you have a website that is, if you if
27
00:02:59,400 --> 00:03:04,630
you have a website of course then somebody
can have fingerprinted this website in
28
00:03:04,630 --> 00:03:10,720
advance, have some, you know, description
of its of its traffic profile and they can
29
00:03:10,720 --> 00:03:15,080
and they can tell if you're just from
looking at your connection if you're if
30
00:03:15,080 --> 00:03:18,390
you're accessing that that website over
Tor.
31
00:03:18,390 --> 00:03:22,630
So okay, so let's admit defeat for the web
on the web for now, because we're not
32
00:03:22,630 --> 00:03:28,570
going to, you know, we're not going to be
able to provide that kind of, we're not
33
00:03:28,570 --> 00:03:33,510
going to be able to defeat that kind of
adversary very quickly. But okay, can we
34
00:03:33,510 --> 00:03:36,990
just message our friends over Tor? So
there's a few programs to do this: There's
35
00:03:36,990 --> 00:03:42,690
Ricochet there's Briar; the problem with
using Tor as a messaging as a messaging
36
00:03:42,690 --> 00:03:48,890
transport layer is that frequently, the
people you want to protect, are in the
37
00:03:48,890 --> 00:03:54,540
same country or even on the same ISP, so
the original property of, you know, the
38
00:03:54,540 --> 00:03:57,670
adversary being able to see both sides of
the connection comes comes through again
39
00:03:57,670 --> 00:04:01,270
and they can very quickly be - that
connection between them can very quickly
40
00:04:01,270 --> 00:04:07,630
be seen. So okay, how can we actually keep
our messaging metadata private? And the
41
00:04:07,630 --> 00:04:11,610
answer we're going to say sort of - we're
going to say the right one is a mixed
42
00:04:11,610 --> 00:04:13,850
network.
David: Oh yeah, so mixed networks are
43
00:04:13,850 --> 00:04:18,810
message oriented, as opposed to stream
oriented. They are essentially an
44
00:04:18,810 --> 00:04:27,340
unreliable packet switching network. And
also latency is added at each hop. This is
45
00:04:27,340 --> 00:04:35,060
called a mix strategy; there's a bunch of
different mix strategies. It's kind of an
46
00:04:35,060 --> 00:04:40,660
architectural diagram. Notice there's no
exit nodes, there's no talking to the web
47
00:04:40,660 --> 00:04:47,910
like with Tor, so the security model is
different, we do have a PKI, similar to
48
00:04:47,910 --> 00:04:57,150
Tor, we we can call it like a directory
authority system. So there's a bunch of
49
00:04:57,150 --> 00:05:04,480
differences between Tor and mix nets and
one of the important ones is that we can
50
00:05:04,480 --> 00:05:09,450
actually do decoy traffic everywhere in
this diagram, like we can do decoy traffic
51
00:05:09,450 --> 00:05:13,280
all the way to clients or to the
destination.
52
00:05:13,280 --> 00:05:20,810
J.: Yeah so one of the one of the issues
with Tor is of course you can't do you if
53
00:05:20,810 --> 00:05:26,570
even if you wanted to add decoy traffic
you couldn't hide the - you couldn't
54
00:05:26,570 --> 00:05:30,340
protect against this website
fingerprinting attack necessarily, because
55
00:05:30,340 --> 00:05:34,610
you're going to be or you're still seeing
the connection coming out the other side,
56
00:05:34,610 --> 00:05:39,430
so you're see there's still a lot of
analysis you can do. Okay so one thing,
57
00:05:39,430 --> 00:05:43,490
just some history here, mixed networks are
actually the the oldest anonymity system
58
00:05:43,490 --> 00:05:50,370
as far as far as I know from David Chaum's
1981 paper, then there's a few other tools
59
00:05:50,370 --> 00:05:54,750
that have been proposed; one of them is
private information retrieval, usually
60
00:05:54,750 --> 00:05:57,900
written PIR.
This works in sort of narrow situations,
61
00:05:57,900 --> 00:06:02,000
when you're trying to retrieve something
from some kind of database. The scaling
62
00:06:02,000 --> 00:06:08,380
isn't perfect on it but there's cool
things you can do. But there's another the
63
00:06:08,380 --> 00:06:12,140
other the other one that sort of is
generally proposed is the alternative to
64
00:06:12,140 --> 00:06:16,770
mix networks is dining cryptographers
networks. And the problem with them is
65
00:06:16,770 --> 00:06:24,560
that the bandwidth is really literally,
you know, each you're paying literally for
66
00:06:24,560 --> 00:06:31,150
the quadratic cost per user, so I mean
something like cubic. so the your
67
00:06:31,150 --> 00:06:37,770
anonymity set is is is really going to
wind up being very small and if you're
68
00:06:37,770 --> 00:06:42,580
talking about building something that has
inherently has a small anonymity set then
69
00:06:42,580 --> 00:06:49,389
you have to "ask who are we protecting?"
And, you know, if you're if - you're not
70
00:06:49,389 --> 00:06:53,220
protecting whistleblowers anymore, because
of whistle- if a whistleblower talks to,
71
00:06:53,220 --> 00:06:56,770
you know, journalists and it's unclear
which journalists, you know, Der Spiegel
72
00:06:56,770 --> 00:07:02,630
he's talking to, well he's still some-
he's still the guy with who knew this
73
00:07:02,630 --> 00:07:06,530
thing, who talked to somebody at Der
Spiegel. So and more as it does protect,
74
00:07:06,530 --> 00:07:11,730
you know, it doesn't, you know, it the
person that it does protect is somebody
75
00:07:11,730 --> 00:07:15,620
who already has a lot of power and who
it's gonna be hard to convict anyway be-
76
00:07:15,620 --> 00:07:20,639
so what we want to do, so we really want
to blow up the anonymity set as large as
77
00:07:20,639 --> 00:07:22,790
possible and that's why we like mix
networks.
78
00:07:22,790 --> 00:07:27,060
D.: All right so we're gonna talk about a
few attacks on mix networks and some
79
00:07:27,060 --> 00:07:33,180
defenses. Epistemic attacks are not one of
the attacks we're really going to focus on
80
00:07:33,180 --> 00:07:37,199
because it's it's really a specialized
area of research; there's actually a bunch
81
00:07:37,199 --> 00:07:44,840
a few papers, written on breaking
different public-key infrastructure
82
00:07:44,840 --> 00:07:49,680
systems for like things like point-to-
point networks and other other things like
83
00:07:49,680 --> 00:07:51,750
that.
J.: So, oh, so..
84
00:07:51,750 --> 00:07:58,960
D.: Oh, so, okay, but we can say I guess
we should mention that our PKI generally -
85
00:07:58,960 --> 00:08:06,199
mix literature assumes you have a PKI, it
assumes that the all the clients using it
86
00:08:06,199 --> 00:08:08,831
somehow know about the whole network.
J.: So
87
00:08:08,831 --> 00:08:13,110
D.: Yeah, g...
J.: So so usually when P - anonymity
88
00:08:13,110 --> 00:08:16,210
researchers talk about a PKI, they
generally assume something like the Tor
89
00:08:16,210 --> 00:08:19,470
directory authority system, where you have
some people, who can be very trusted, who
90
00:08:19,470 --> 00:08:23,080
run the thing. This actually presents a
scalability problem- it's what's goin- it's
91
00:08:23,080 --> 00:08:27,639
what's the cuts(?) and post-project(?) and
and ever- and Panoramix is doing; it does
92
00:08:27,639 --> 00:08:33,139
present a scalability problem, more
serious than the one for Tor. The there
93
00:08:33,139 --> 00:08:38,078
are other ideas you can do, there's there,
so on the try, on the idea
94
00:08:38,078 --> 00:08:42,399
of sort of making it more secure beyond
just these people, there's projects like
95
00:08:42,399 --> 00:08:46,970
(???)thority and things and on the - but
on trying to make it more scalable,
96
00:08:46,970 --> 00:08:50,689
there's other things, like we have we have
some people in the GNUnet project that are
97
00:08:50,689 --> 00:08:55,500
researching this. In past generally these
peer-to-peer networking projects to try
98
00:08:55,500 --> 00:09:01,290
and come up with, you know, distributed
PKI, had very serious attacks against
99
00:09:01,290 --> 00:09:05,369
them; these epistemic and especially these
epistemic attack types things, so and
100
00:09:05,369 --> 00:09:09,009
you're not gonna completely fix those, so
the way that you would have a distributed
101
00:09:09,009 --> 00:09:14,300
PKI is you would have to prove that you
really know how bad the attack is and then
102
00:09:14,300 --> 00:09:19,559
argue that this is better than some nine
people or whatever possibly being
103
00:09:19,559 --> 00:09:22,730
compromised. But we don't want to talk too
much about this, because this is not our
104
00:09:22,730 --> 00:09:26,240
area of work but we just want to mention
it's intr- it's a lot of interesting stuff
105
00:09:26,240 --> 00:09:32,379
there and right now - so since we were
leading from the epistemic attacks David's
106
00:09:32,379 --> 00:09:36,180
gonna tell you about sort of, since this
is sort of the sca- well, I'm sorry, he's
107
00:09:36,180 --> 00:09:39,620
gonna tell you about how the scalability
comes in.
108
00:09:39,620 --> 00:09:46,449
D.: Yeah, so Tor, oh, so, sorry, mix nets
can use cascade topologies where everyone
109
00:09:46,449 --> 00:09:52,009
uses the same route and this is quite a
different than tor where route
110
00:09:52,009 --> 00:09:58,659
unpredictability is used to achieve some
of it's anonymity properties. So in mixed
111
00:09:58,659 --> 00:10:04,209
nets you can use the same route as
everybody but this is a scalability
112
00:10:04,209 --> 00:10:12,949
problem. So we have other things like free
route and also stratified topology but
113
00:10:12,949 --> 00:10:18,139
free route actually has slightly worse
anonymity. Claudia Diaz has got an
114
00:10:18,139 --> 00:10:22,010
excellent paper and about this.
J.: Another kind of point about free route
115
00:10:22,010 --> 00:10:26,541
is that in practice, like the Tor network,
you visualize it as a free network and it
116
00:10:26,541 --> 00:10:31,509
grew away from that. Nodes are authorized
to be in specific positions and things
117
00:10:31,509 --> 00:10:36,339
like this. So it may be that free routes
aren't just... you wouldn't land there
118
00:10:36,339 --> 00:10:42,610
anyway even if you tried
D.: oh yeah. exit versus guard flags for
119
00:10:42,610 --> 00:10:50,990
tor. This is another diagram of the... any
layer, any mixin layer 0 can connect to
120
00:10:50,990 --> 00:10:58,609
any mix in layer 1 and and send a mix
packet. So this comes from the loop picks
121
00:10:58,609 --> 00:11:05,320
design, we're gonna be mentioning some
more designed from loop picks. The cool
122
00:11:05,320 --> 00:11:10,699
thing about this is, it's fairly easy to
calculate the entropy of each mix compared
123
00:11:10,699 --> 00:11:17,420
to say free route, which is pretty
complicated. This also scales pretty well,
124
00:11:17,420 --> 00:11:22,319
we can add mixes to each layer if we need
to scale up for more traffic and more
125
00:11:22,319 --> 00:11:26,389
users.
D.: So we're gonna mention a couple,
126
00:11:26,389 --> 00:11:31,050
sometimes we'll put some citations on the
slide. Don't take them.. they're not too
127
00:11:31,050 --> 00:11:35,899
critical, but the one on this one... yeah,
Claudia Diaz has a very nice paper for
128
00:11:35,899 --> 00:11:41,029
understanding the different ideologies.
J.: And I believe Roger has a paper on
129
00:11:41,029 --> 00:11:46,759
this topic as well.
D.: Ok, so why isn't this tor? Well, the
130
00:11:46,759 --> 00:11:50,759
main thing that we can say is that tor
doesn't actually mix. if the packets
131
00:11:50,759 --> 00:11:54,390
are... The packets coming in at a
particular point in time are basically the
132
00:11:54,390 --> 00:12:01,649
same packets going out. You pretty much
know within a very small number. So what a
133
00:12:01,649 --> 00:12:05,649
mixed strategy actually does. This is an
algorithm that's part of the software to
134
00:12:05,649 --> 00:12:10,989
do the thing. What a mixed strategy
actually does is it adds latency to reduce
135
00:12:10,989 --> 00:12:18,289
the correlation between packets.
And there's yeah ...
136
00:12:18,289 --> 00:12:25,959
J.: So David Chum in 1981 with this first
mix net paper describe this threshold mix.
137
00:12:25,959 --> 00:12:30,139
So say this mix had a threshold of four.
It would accumulate four input messages
138
00:12:30,139 --> 00:12:35,929
like this. And when it had enough for its
threshold, then it would shuffle them and
139
00:12:35,929 --> 00:12:40,820
send them out. Mixes are also unwrapping a
layer of encryption for each of these
140
00:12:40,820 --> 00:12:49,269
hops. So if I was an attacker and I wanted
to break this, what I could do is wait
141
00:12:49,269 --> 00:12:54,110
until the mix is empty, or I could make
that mix empty by sending my own messages
142
00:12:54,110 --> 00:12:59,110
into it. And then when a target message
enters this mix I could send my own
143
00:12:59,110 --> 00:13:03,999
messages and cause it to achieve its
threshold and shuffle and send all the
144
00:13:03,999 --> 00:13:09,110
messages out. So then I would recognize
all the cipher texts of my own messages
145
00:13:09,110 --> 00:13:11,360
and the one message
I don't recognize it's the
146
00:13:11,360 --> 00:13:15,629
target message. You can keep doing this
for each hop and this is called a
147
00:13:15,629 --> 00:13:21,110
n-minus-1 attack or blending attack.
There's a lot of variations on them. We
148
00:13:21,110 --> 00:13:26,700
have continuous-time mixes like the stop-
and-go mix and the poisson-mixed
149
00:13:26,700 --> 00:13:31,529
strategies. These mixed strategies allow
the client to select the delays for each
150
00:13:31,529 --> 00:13:41,139
hop. Usually they're from an exponential
distribution. If an attacker wants to
151
00:13:41,139 --> 00:13:47,799
break this using a blending attack, first
they need to empty the mix queue by
152
00:13:47,799 --> 00:13:52,389
blocking all input messages from the mix
and waiting some period of time where it's
153
00:13:52,389 --> 00:13:57,949
highly probable that the mix queue would
then be empty. Then they would allow their
154
00:13:57,949 --> 00:14:03,199
one target message to enter the mix and
continue to block other input messages and
155
00:14:03,199 --> 00:14:11,290
then simply wait for that message to be
outputted. Now these attacks we have some
156
00:14:11,290 --> 00:14:17,059
defense for them, like say a heartbeat
protocol from, George wrote a paper about
157
00:14:17,059 --> 00:14:22,779
ten years ago, George Danezis. It's also
in the Loopix paper as well, it's
158
00:14:22,779 --> 00:14:31,600
mentioned. So we would have mixes with a
kind of decoy traffic, we refer to him as
159
00:14:31,600 --> 00:14:35,580
mixed loops or heartbeat traffic, where a
mix is sending itself a message. It's like
160
00:14:35,580 --> 00:14:38,920
a self-addressed stamped envelope. It's
going through the mix network and coming
161
00:14:38,920 --> 00:14:46,299
back. And if it doesn't receive its
heartbeat in some time out, it knows it
162
00:14:46,299 --> 00:14:50,040
could be under attack or of course there
could be other problems in the network as
163
00:14:50,040 --> 00:14:57,429
well. So you would want to maybe correlate
a attack with several failures to receive
164
00:14:57,429 --> 00:15:03,110
a heartbeat message.
There's other defenses for blending
165
00:15:03,110 --> 00:15:06,370
attacks as well. There was a recent paper
published, but we're not going to talk
166
00:15:06,370 --> 00:15:14,800
about that right now. The next category of
attack is statistical disclosure attacks.
167
00:15:14,800 --> 00:15:20,320
This is essentially, I like to think of it
as the adversary is abstracting the entire
168
00:15:20,320 --> 00:15:25,760
mix network as if it's one mix. They're
looking at messages go in and messages
169
00:15:25,760 --> 00:15:31,559
come out. A lot of this literature is
written from the perspective of like
170
00:15:31,559 --> 00:15:36,359
point-to-point networks. Like when Alice
and Bob were receiving messages from the
171
00:15:36,359 --> 00:15:40,300
mixed network they're receiving it at
their home IP addresses, as if we had
172
00:15:40,300 --> 00:15:45,589
publicly routable IP addresses and no NAT
devices to get in the way. Maybe a more
173
00:15:45,589 --> 00:15:52,670
modern sort of architecture might involve
queuing messages. This is a concept used
174
00:15:52,670 --> 00:15:58,629
in Loopix design as well.
Loopix has got a bunch of different decoy
175
00:15:58,629 --> 00:16:05,819
traffic types in order to add noise to the
signal at various locations in the
176
00:16:05,819 --> 00:16:13,980
network. So there's drop decoy traffic,
where a client would select a random
177
00:16:13,980 --> 00:16:18,820
destination provider to send a message to.
So it traverses the mix net and then gets
178
00:16:18,820 --> 00:16:26,920
dropped by the provider. And there's also
client loops, and actually I should
179
00:16:26,920 --> 00:16:32,619
mention, if we're doing these kind of
statistical disclosure attacks, a lot of
180
00:16:32,619 --> 00:16:36,980
this stuff we don't know how well it will
work in the real world. Because, it really
181
00:16:36,980 --> 00:16:42,490
depends on a specific application and the
adversaries ability to predict users
182
00:16:42,490 --> 00:16:47,990
behavior and that behavior should be
repetitive. I mean this depends on how
183
00:16:47,990 --> 00:16:53,420
much information is leaked by the system.
But mix networks always leak information,
184
00:16:53,420 --> 00:16:59,980
so it's it's about measuring the leakage
and understanding if the user behavior is
185
00:16:59,980 --> 00:17:06,859
dynamic enough.
These attacks cannot always converge on
186
00:17:06,859 --> 00:17:14,309
success. So it depends on the particular
system and how it's tuned. In this
187
00:17:14,309 --> 00:17:20,359
particular case for queuing messages in
this style mixed network the adversary
188
00:17:20,359 --> 00:17:27,880
would have to compromise the destination
providers. So previously here in this
189
00:17:27,880 --> 00:17:32,210
situation it would be, in this point-to-
point network situation where people are
190
00:17:32,210 --> 00:17:37,570
actually receiving messages from the mixed
network to their mailbox directly or to
191
00:17:37,570 --> 00:17:44,740
their home IP, the adversary is a passive
adversary. In the more modern architecture
192
00:17:44,740 --> 00:17:50,120
where messages are queued, I mean it's not
more modern, but it's the Loopix design
193
00:17:50,120 --> 00:17:57,059
which is a recent paper, so this attack
becomes an active attack. And there's some
194
00:17:57,059 --> 00:18:01,960
padding to the clients so we have some
amount of receiver unobservability, so
195
00:18:01,960 --> 00:18:07,419
clients received the same amount of
information when they received messages.
196
00:18:07,419 --> 00:18:10,760
D.: So okay, so there's a question that's
natural. So we've talked about adding
197
00:18:10,760 --> 00:18:14,559
latency and we are also talking about
adding cover traffic. So you might ask "Is
198
00:18:14,559 --> 00:18:21,880
this enough?" and "Could I get away with
less?". And the answer to "Could I get
199
00:18:21,880 --> 00:18:32,820
away with less?" seems to be no. At least
by some artificial measures your anonymity
200
00:18:32,820 --> 00:18:39,019
can't really scale better than the cover
traffic times the latency. So one takeaway
201
00:18:39,019 --> 00:18:45,669
from this is in the Tor, in what is Tor's
situation, so I mean Roger always tells
202
00:18:45,669 --> 00:18:51,539
people that they don't know, if adding
cover traffic to Tor would help. And one
203
00:18:51,539 --> 00:18:55,450
sort of extreme version of this is of
course, whatever cover traffic you add
204
00:18:55,450 --> 00:19:03,500
times something very small is still
something rather relatively small. Now
205
00:19:03,500 --> 00:19:07,039
you'll notice here of course the anonymity
still looks quadratic in something but
206
00:19:07,039 --> 00:19:10,909
it's still longer in the number of users.
So what we're talking about is paying some
207
00:19:10,909 --> 00:19:15,500
sort of fixed upfront cost. It may be
somewhat large, part of it is in terms of
208
00:19:15,500 --> 00:19:19,580
the users experience with the latency and
part of it is in terms of the actual sort
209
00:19:19,580 --> 00:19:27,539
of cost of their you know of their network
connection, but you know, it's doable. So
210
00:19:27,539 --> 00:19:31,440
one thing, so sometimes people have made
these just to sort of wrap up this section
211
00:19:31,440 --> 00:19:36,340
about topologies and whatever and
strategies and things, so people have made
212
00:19:36,340 --> 00:19:40,980
these sort of quasi religious statements
about encryption from time to time. To
213
00:19:40,980 --> 00:19:45,960
sort of boil that down to something
concrete encryption is basically free in
214
00:19:45,960 --> 00:19:50,750
general and but for the mixed network
we're going to have to actually pay some
215
00:19:50,750 --> 00:19:56,160
kind of real costs.
Okay, so one thing about mix networks, you
216
00:19:56,160 --> 00:20:01,200
don't want to roll your own packet format.
There's this wonderful, first to know a
217
00:20:01,200 --> 00:20:05,910
very reasonable one, it's sort of the one
that has stopped much of the development
218
00:20:05,910 --> 00:20:11,460
in this area, is Sphinx. It's quite
compact, and it has a very nice security
219
00:20:11,460 --> 00:20:16,990
proof, it's by George Danezis and Ian
Goldberg. So just to comment on the name,
220
00:20:16,990 --> 00:20:20,769
so the packet format has a header and a
body and at the time that it was
221
00:20:20,769 --> 00:20:24,820
developed, so the body has to be encrypted
with what's called a wide block cipher. At
222
00:20:24,820 --> 00:20:28,500
the time that was developed the only wide
block cipher the people were thinking
223
00:20:28,500 --> 00:20:35,720
about was lioness. There's now some other
wide block ciphers like AEZ by Rogaway and
224
00:20:35,720 --> 00:20:42,350
supposedly DJB has one on the way. So I'm
gonna say a little few things about the
225
00:20:42,350 --> 00:20:47,370
packet format. So the header has three
parts, but one of them, the first part is
226
00:20:47,370 --> 00:20:53,139
a public key this elliptic curve point,
and then there's this body, which is
227
00:20:53,139 --> 00:20:57,510
encrypted with a wide box cipher. So the
way you think about this mix node n
228
00:20:57,510 --> 00:21:04,840
operating is, Alice, you know there's this
key exchange between the mix node and
229
00:21:04,840 --> 00:21:10,710
Alice, that Alice first does it. She
thinks up this is key for her packet and
230
00:21:10,710 --> 00:21:16,029
does the exchange and then the mix node
computes the other side of the Diffie-
231
00:21:16,029 --> 00:21:21,140
Hellman. From that the mix node extracts
the next hop and he has to mutate all of
232
00:21:21,140 --> 00:21:27,981
the different things. So what Sphinx is,
is the rules for how to mutate those. Okay
233
00:21:27,981 --> 00:21:32,760
so let's say one thing, that's kind of
important is: "Why are we using...", you
234
00:21:32,760 --> 00:21:37,539
know "Why is this Delta...". I didn't make
a comment on this too much, but the header
235
00:21:37,539 --> 00:21:42,340
part was MACed and Delta was not. So why
do we not put a MAC on Delta?
236
00:21:42,340 --> 00:21:46,309
This seems very very dangerous. Of course
if you know, if we had, if we were just
237
00:21:46,309 --> 00:21:52,590
using an unMACed stream cipher than some
adversary who controls a mix node next to
238
00:21:52,590 --> 00:21:58,030
the sender and someplace where the message
is going, could just XOR an arbitrary
239
00:21:58,030 --> 00:22:05,120
message into the packet and then check for
it when it arrives. But we don't use a
240
00:22:05,120 --> 00:22:10,860
stream cipher, we use a wide block cipher.
So what this means is, an attacker doing
241
00:22:10,860 --> 00:22:18,460
the same sort of thing will get at most a
one bit tagging attack. Okay, that's still
242
00:22:18,460 --> 00:22:24,650
an attack. Why would we tolerate even a
one bit tagging attack? And the answer is
243
00:22:24,650 --> 00:22:34,280
that anonymous receivers really matter. So
there's a few things, so of course a
244
00:22:34,280 --> 00:22:38,230
journalistic source, some sort of
whistleblower or whatever, but also any
245
00:22:38,230 --> 00:22:41,970
kind of service, like if you want to talk
to some crypto currency network, or you
246
00:22:41,970 --> 00:22:46,071
want to talk to or download some file, or
anything like this, anything where you
247
00:22:46,071 --> 00:22:52,139
interact with a service or you need some
kind of acknowledgment back of it. And in
248
00:22:52,139 --> 00:22:59,640
fact even just the basic protocol acts for
a messaging system need some sort of
249
00:22:59,640 --> 00:23:05,260
reply. Okay, so what is this? So how do we
do anonymous receivers? We create what's
250
00:23:05,260 --> 00:23:12,570
called a single-use reply block, so that's
a first node where it goes to, expiration
251
00:23:12,570 --> 00:23:20,919
date, and then the header and one
cryptographic key for one layer of it. And
252
00:23:20,919 --> 00:23:28,710
so the recipient makes up this SURB and
supplies it to the sender at some point in
253
00:23:28,710 --> 00:23:34,330
the past. the sender attaches their Delta
and they can send to the recipient.
254
00:23:34,330 --> 00:23:45,429
Okay so great, now okay, now let's get
into something tricky. We have these
255
00:23:45,429 --> 00:23:51,879
common... Okay we might worry, so if you
looked at the key exchange that I did,
256
00:23:51,879 --> 00:23:59,480
Alice the sender just made up her alpha on
the spot. So her key is ephemeral but the
257
00:23:59,480 --> 00:24:07,289
mix node he wasn't. It was supplied by
this PKI. So that means, so we want our
258
00:24:07,289 --> 00:24:10,660
protocols to be forward secure and you
know TOR is forward secure. It doesn't
259
00:24:10,660 --> 00:24:16,480
negotiate, live negotiation with the top
which is great. But we need some kind of
260
00:24:16,480 --> 00:24:23,509
forward security and we don't have it, a
priori. So what we have to do is well
261
00:24:23,509 --> 00:24:30,129
first of all a mixed net, we need some
kind of replay attack protection anyway.
262
00:24:30,129 --> 00:24:38,450
So what this requires, some sort of data
structure that will eventually fill up or
263
00:24:38,450 --> 00:24:43,569
overflow or something like this. So to
prevent that we have to do key rotation
264
00:24:43,569 --> 00:24:47,870
anyway. So one option is to just rotate
the mix node keys faster. The problem with
265
00:24:47,870 --> 00:24:52,320
that is that you don't want to stress the
PKI too much. Because the PKI is already a
266
00:24:52,320 --> 00:24:58,600
scaling pain. So, okay. But another
problem with that is that these SURB
267
00:24:58,600 --> 00:25:04,270
lifetimes are equal to the node key life,
they can't exceed the node key lifetimes.
268
00:25:04,270 --> 00:25:09,789
So that means that we, if we want to be
able to have our forward, have our key
269
00:25:09,789 --> 00:25:15,090
compromise window smaller than the node
key lifetimes or then we have to do, or -
270
00:25:15,090 --> 00:25:19,559
you know smaller than the server lifetimes
- and we have to do something else. So
271
00:25:19,559 --> 00:25:25,110
there's a couple ideas. So George, back in
two thousand th- so, okay the idea is;
272
00:25:25,110 --> 00:25:29,910
Okay, maybe we can be like, a little like
Tor and use more packets per for the
273
00:25:29,910 --> 00:25:35,210
packet we want to send but not do it in
the way Tor does it. So George proposed
274
00:25:35,210 --> 00:25:40,710
using two packets in different key epochs.
That's pretty good, that that gives you,
275
00:25:40,710 --> 00:25:46,270
that gives you a lot of nice properties.
So there's another thing you can do that
276
00:25:46,270 --> 00:25:51,429
I'm sort of, that I've been working on,
which is you can you can use a loop to the
277
00:25:51,429 --> 00:25:58,470
mix, to a mix node to actually do a key
exchange and then on the mix node you can
278
00:25:58,470 --> 00:26:04,691
you can use a double ratchet construction
for some hops. And that the this, problem
279
00:26:04,691 --> 00:26:11,169
with this is it's cheating, these two
these two things. and you wouldn't want to
280
00:26:11,169 --> 00:26:17,250
do them at all hops, because they create
some correlations between packets. So,
281
00:26:17,250 --> 00:26:23,409
okay, so we can so we can, in general we
can ask what is what do we want the key
282
00:26:23,409 --> 00:26:28,559
exchange that our mix node - what do we
want, how do we make this mix node forward
283
00:26:28,559 --> 00:26:33,360
secure, so I don't want to say too much
about this but in general we can talk
284
00:26:33,360 --> 00:26:39,519
about the different stra- different sort
of basic technologies for key exchanges
285
00:26:39,519 --> 00:26:43,960
and the properties we can get out of them
in the context of Sphinx.
286
00:26:43,960 --> 00:26:48,139
And, you know, anything that's based on
elliptic curves is not going to be post
287
00:26:48,139 --> 00:26:52,809
quantum, so if we want something based on,
you know, if we want that then we need to
288
00:26:52,809 --> 00:26:55,950
something else so there was a blinding
operations in Sphinx I didn't tell you
289
00:26:55,950 --> 00:27:00,039
about, doing that in the post quantum
context is tricky. Probably it works for
290
00:27:00,039 --> 00:27:05,720
SIDH. We don't know if it works for LWE.
We certainly have no idea how to do it
291
00:27:05,720 --> 00:27:10,909
efficiently, maybe it can be done. Our
cheating strategy gives us nice key
292
00:27:10,909 --> 00:27:16,059
erasure properties, it gives us post
quantum, if the loop if the loop did a
293
00:27:16,059 --> 00:27:20,710
post quantum key exchange and there's
another nice property that it gives, that
294
00:27:20,710 --> 00:27:24,700
you can't really get any other way, which
is that it the the blinding thing is
295
00:27:24,700 --> 00:27:29,809
hybrid - you can actually have a hybrid
post quantum property, and that means that
296
00:27:29,809 --> 00:27:33,759
you can use both an elliptic curve and
this post quantum key exchange and if
297
00:27:33,759 --> 00:27:39,010
either one of them is good then you can't
break then you can't break it. If you try
298
00:27:39,010 --> 00:27:43,570
and do this construction with something
like LWE you're probably not going to be
299
00:27:43,570 --> 00:27:47,111
able to get that hybrid post quantum
property, 'cause the blinding operation
300
00:27:47,111 --> 00:27:51,080
itself will depend on the LWE
cryptographic assumptions.
301
00:27:51,080 --> 00:27:58,240
So nevertheless I want to conjecture that
LWE (?????????) LWE means "learning with
302
00:27:58,240 --> 00:28:03,899
errors", may be the eventual sort of post
quantum key exchange we want to use and so
303
00:28:03,899 --> 00:28:07,630
mathematicians love conjectures, so I
don't think there's one with blinding but
304
00:28:07,630 --> 00:28:14,590
I think we can probably come up with
something that eventually, where we have
305
00:28:14,590 --> 00:28:19,750
some kind of nice blinding for the an LWE
scheme and it even has puncturing.
306
00:28:19,750 --> 00:28:23,499
Punctured encryption is something that you
can currently do with pairing based crypto
307
00:28:23,499 --> 00:28:30,639
and it's excruciatingly slow but I think
it could, I suspect it could be done much
308
00:28:30,639 --> 00:28:37,450
faster with LWE. Okay
D.: Okay, so mix networks: they're
309
00:28:37,450 --> 00:28:43,770
unreliable, they're packet switching, so
in that case some classical Network
310
00:28:43,770 --> 00:28:51,831
literature can can be applied. Now an
automatic repeat request protocol scheme
311
00:28:51,831 --> 00:28:56,820
is one of those protocol schemes that has
protocol acknowledgments and retransmits
312
00:28:56,820 --> 00:29:01,870
and we can do this over mix networks but
it leaks extra information. Every ACK you
313
00:29:01,870 --> 00:29:07,699
send could potentially be used as in a
correlation attack, for instance if the
314
00:29:07,699 --> 00:29:12,909
adversary causes the ACK packet to be
dropped. And in a stopping way ARQ(?) the
315
00:29:12,909 --> 00:29:18,370
simplest variety of these protocols, would
leak the least amount of information, so
316
00:29:18,370 --> 00:29:26,960
that's what we're using and we have three
cryptographic layers in our stack right
317
00:29:26,960 --> 00:29:35,210
now in this Loopix Katzenpost project
we're working on. Yawning(?) angel wrote a
318
00:29:35,210 --> 00:29:42,029
cryptographic link layer based on the
noise cryptographic framework. He's mixing
319
00:29:42,029 --> 00:29:49,509
new hope simple(?) with x25509 and the key
exchange and we also have a Sphinx
320
00:29:49,509 --> 00:29:55,900
cryptographic layer. Sphinx is what Jeff
talked about earlier, the cryptographic
321
00:29:55,900 --> 00:30:02,249
packet format and we also have an end-to-
end cryptographic messaging. And this is
322
00:30:02,249 --> 00:30:08,519
another sort of Loopix style diagram:
Alice sends message to Bob's provider, so
323
00:30:08,519 --> 00:30:14,870
it goes through the mix network to Bob and
Bob can retrieve his message later and
324
00:30:14,870 --> 00:30:20,820
with some relatively simple changes from
this Loopix design, we can, to have
325
00:30:20,820 --> 00:30:26,820
stronger location hiding properties, where
Alice and Bob don't talk directly to the
326
00:30:26,820 --> 00:30:32,010
provider that they're retrieving messages
from. They can send single-use reply
327
00:30:32,010 --> 00:30:37,520
blocks to retrieve messages this would
increase latency.
328
00:30:37,520 --> 00:30:40,240
J.: So one thing that's nice there's a
comment to make here, is that a lot of
329
00:30:40,240 --> 00:30:46,240
time certain schemes in academia tend to
use, want to use PIR for this retrieving,
330
00:30:46,240 --> 00:30:52,950
the the thing I thought from your from
your provider and then the - one of the
331
00:30:52,950 --> 00:30:58,309
problems with using a PIR scheme here is
that you're gonna have very different very
332
00:30:58,309 --> 00:31:03,070
different sort of assumptions at play
there and the way even what you model it
333
00:31:03,070 --> 00:31:07,860
is going to be necessary necessarily quite
complex. It's probably fun if you're a
334
00:31:07,860 --> 00:31:11,480
graduate student, you know, doing, playing
with all this stuff but it's actually
335
00:31:11,480 --> 00:31:17,450
giving all of everything to match up will
be complicated. So this is why, so in the
336
00:31:17,450 --> 00:31:21,220
scheme they were talking about here you
actually, you're your mix net is giving
337
00:31:21,220 --> 00:31:24,890
you your location hiding property so you
can you can extract some similar things.
338
00:31:24,890 --> 00:31:29,620
D.: Well, right and also, whereas in this
situation, with a Loopix design it doesn't
339
00:31:29,620 --> 00:31:36,330
have strong location hiding properties, in
particular if Alice really wanted to
340
00:31:36,330 --> 00:31:42,429
figure figure out where Bob is she would
hack his provider and then stake it out
341
00:31:42,429 --> 00:31:46,780
until his IP address showed up again or so
-
342
00:31:46,780 --> 00:31:52,070
J.: One problem with this, with these
provider models, is that, like David just
343
00:31:52,070 --> 00:32:00,620
said, you can get your provider hacked and
there's a way to fix that. It requires
344
00:32:00,620 --> 00:32:03,830
modifying Sphinx a bit, I said, I know
that we just said don't roll your own
345
00:32:03,830 --> 00:32:07,990
packet format but it's a good idea to go
through the security proof again anyway
346
00:32:07,990 --> 00:32:14,590
and it's a small change. But, so, the idea
is that we have, in this middle, this
347
00:32:14,590 --> 00:32:21,210
harddrive picture, is is some sort of of
mailbox server or cumulation thing, that
348
00:32:21,210 --> 00:32:27,249
the receiver here can move whenever he
wants without telling his contacts. And
349
00:32:27,249 --> 00:32:31,580
his contacts actually reach him in other
ways; either he gives them SURBs or he
350
00:32:31,580 --> 00:32:35,139
sub- puts the SURBs at this thing called a
crossover point, which I didn't want to
351
00:32:35,139 --> 00:32:42,519
tell you too much about. So, but the the
idea is that this guy can, our receiver
352
00:32:42,519 --> 00:32:49,429
can supply the - he can send some SURBs to
this point in the middle and then the
353
00:32:49,429 --> 00:32:55,640
pack- and when he goes online - and then
it will send him messages, so the you can
354
00:32:55,640 --> 00:33:00,419
have this ver- this decoupling and one of
the nice things - so at the end of the day
355
00:33:00,419 --> 00:33:03,929
what the proof, what's your like security
result for the mix net's going to be, is
356
00:33:03,929 --> 00:33:08,100
like, okay well, in three months - you
know they're not going to be able to
357
00:33:08,100 --> 00:33:12,880
deanonymise you in three months. So we may
be able to do a bit more if we can move
358
00:33:12,880 --> 00:33:19,809
this guy in the middle periodically.
Okay, so but this is work, very much work
359
00:33:19,809 --> 00:33:22,780
in progress, it's not at all in the cuts
and post thing and it requires modifying
360
00:33:22,780 --> 00:33:28,690
Sphinx and doing doing some redoing a
number of proofs. So, okay, we've been
361
00:33:28,690 --> 00:33:35,690
talking about applications with the idea
being messaging. There's other
362
00:33:35,690 --> 00:33:41,150
applications and - where you're still
sending messages but to give you a bit
363
00:33:41,150 --> 00:33:46,850
more, something a bit more concrete:
There's a there's a few schemes for doing
364
00:33:46,850 --> 00:33:49,340
anonymous money, well right now there's a
lot of schemes for doing anonymous money
365
00:33:49,340 --> 00:33:52,490
and mostly they suck but there's a few
that are actually quite good and have
366
00:33:52,490 --> 00:33:58,289
extremely strong cryptographic assurances
on their anonymity: Zcash you basically
367
00:33:58,289 --> 00:34:01,049
would have to invert a hash function or
something to break it, I'm not completely
368
00:34:01,049 --> 00:34:07,799
sure, Taler, well in in the RSA blind
signatures have information theoretically
369
00:34:07,799 --> 00:34:10,460
secure blinding, which means they are
absolutely unbreakable.
370
00:34:10,460 --> 00:34:11,750
There's a point in Taler where it's weaker
371
00:34:11,750 --> 00:34:18,860
than that, but another thing you might ask
is, you know, can we do anything web-like.
372
00:34:18,860 --> 00:34:23,840
Well, there's a project that wants to like
package up web pages and ship them over
373
00:34:23,840 --> 00:34:30,449
free nets, so you could use it to ship
things over a mix network. But,
374
00:34:30,449 --> 00:34:33,980
fundamentally, if you imagine what we want
to do is like build build some application
375
00:34:33,980 --> 00:34:36,860
that does some collaborative thing like
run something like Google Wave or have a
376
00:34:36,860 --> 00:34:42,460
have just an etherpad over a mix network,
you're gonna have the interesting issues
377
00:34:42,460 --> 00:34:48,400
that pop up with like the merges and other
thing and, and anyway the latency is gonna
378
00:34:48,400 --> 00:34:53,370
have other impacts on the users. And one
things we're not really thinking about but
379
00:34:53,370 --> 00:34:59,230
we would really like other people to think
about is sort of how to make how to make
380
00:34:59,230 --> 00:35:08,420
people happy with higher latency
applications. And this sounds hard, but
381
00:35:08,420 --> 00:35:11,670
actually a lot of times, like, you know
when you look at people who are developing
382
00:35:11,670 --> 00:35:16,440
more modern web frameworks, actually they
are doing you know more of the abstract
383
00:35:16,440 --> 00:35:23,000
alike something like couch TV is doing;
it's not literally, you know, supporting
384
00:35:23,000 --> 00:35:27,110
latency, but it's it's decoupling things
in a way that it is quite relevant to what
385
00:35:27,110 --> 00:35:30,060
we want to do.
D: So, but it wouldn't be fair for us to
386
00:35:30,060 --> 00:35:35,150
say, like, "hey, use this cool messaging
app - it's unreliable, so I'm gonna send
387
00:35:35,150 --> 00:35:40,980
you a message, but you might not get it."
So we want to definitely build in some
388
00:35:40,980 --> 00:35:47,230
reliability, and and you and you pay for
that in in retransmission some times and
389
00:35:47,230 --> 00:35:51,290
and some extra leaked information for
which we need to compensate with more
390
00:35:51,290 --> 00:35:56,050
decoy traffic. We can actually -- the
Loopix paper explores this trade-off where
391
00:35:56,050 --> 00:36:00,040
you can make the latency lower in a mixed
network if you are willing to send more
392
00:36:00,040 --> 00:36:05,760
decoy traffic. And so that should help.
J: Yeah
393
00:36:05,760 --> 00:36:11,190
D: It's it would still it still doesn't
make mix networks, I don't think as low
394
00:36:11,190 --> 00:36:18,840
latency as tor or even close. But this is
a matter of tuning, and we can at least
395
00:36:18,840 --> 00:36:22,660
have lower latency mix networks than say,
10 years ago.
396
00:36:22,660 --> 00:36:25,300
J: One of the nice things about certainly
the nice things about the stuff that
397
00:36:25,300 --> 00:36:28,590
David and Yawning have been doing is that
they're they're active really trying to
398
00:36:28,590 --> 00:36:39,840
make the - the the, sorry, the reliability
measures work in the mixed work in the --
399
00:36:39,840 --> 00:36:43,320
or just just above the mix network. And
this is really essential if you want to
400
00:36:43,320 --> 00:36:48,030
build something that application
developers can use because one it is
401
00:36:48,030 --> 00:36:53,650
actually common in anonymity systems for
the sort of reliability measures to create
402
00:36:53,650 --> 00:36:59,420
to possibly compromise other things. So
having being able to do the reliability
403
00:36:59,420 --> 00:37:03,910
stuff in a way that you can still have
your security properties for it is
404
00:37:03,910 --> 00:37:09,100
important. Okay.
D: Oh yeah, we'd like to say thanks to the
405
00:37:09,100 --> 00:37:14,240
researchers we've been working with. And I
like to thank Yawning Angel for all the
406
00:37:14,240 --> 00:37:19,540
good design advice and work on the
specifications. And and for George for his
407
00:37:19,540 --> 00:37:21,810
advice.
J: George and Claudia are always one
408
00:37:21,810 --> 00:37:24,910
D: For their excellent paper. Anya for her
Loopix paper.
409
00:37:24,910 --> 00:37:27,452
J: Christian I've - everything that I've
been working on our talk to Christian
410
00:37:27,452 --> 00:37:29,550
about all the time
D: Nick Matheson from the Tor project
411
00:37:29,550 --> 00:37:35,210
helped me out a lot with the with our PKI
specification because, well, I mean he
412
00:37:35,210 --> 00:37:39,240
wrote the directory authority system for
mix minion, and for tor, and
413
00:37:39,240 --> 00:37:43,440
J: And also to Trevor Perrin for running
this wonderful mailing list which where we
414
00:37:43,440 --> 00:37:45,950
get all where we get numbers
of important ideas.
415
00:37:45,950 --> 00:37:52,030
D: Ah yeah and Trevor also helped with our
PKI sense so that was really great; with
416
00:37:52,030 --> 00:37:58,210
our wire protocol using noise, I mean.
Anyway and that's that's the this new sort
417
00:37:58,210 --> 00:38:03,000
of project. Alright, that's it.
418
00:38:03,000 --> 00:38:12,960
Applause
419
00:38:12,960 --> 00:38:17,590
Herald: Thank you so much, if you have any
questions here in the room, please line up
420
00:38:17,590 --> 00:38:25,470
at the microphones. Do we have questions
from the internet? From the IRC Network?
421
00:38:25,470 --> 00:38:31,220
No questions from the IRC. There's one
question microphone one
422
00:38:31,220 --> 00:38:35,720
Mic 1: You mentioned latency will be
higher than tor - should we be thinking
423
00:38:35,720 --> 00:38:41,450
sort of seconds, minutes,
what's the sort of order of
424
00:38:41,450 --> 00:38:44,000
J: We don't know
D: Oh yes so the question is, the latency
425
00:38:44,000 --> 00:38:49,260
will be higher than tor, how how high will
it be? We don't really know until we tune
426
00:38:49,260 --> 00:38:52,990
the mix Network and we're not
J: George has claimed seconds so I don't
427
00:38:52,990 --> 00:38:55,500
know if I believe him
D: I should start off by saying that mix
428
00:38:55,500 --> 00:38:59,081
networks aren't trying to be a general-
purpose anonymity system like tor. We're
429
00:38:59,081 --> 00:39:03,850
trying to make customized networks for
specific applications, and so each
430
00:39:03,850 --> 00:39:09,480
application has different traffic patterns
in different ways they're used. So the
431
00:39:09,480 --> 00:39:17,390
latency would would necessarily come after
tuning. Now, some, we have some idea that
432
00:39:17,390 --> 00:39:22,700
maybe a few minutes, let's say. But it;
really I can't answer the question yet.
433
00:39:22,700 --> 00:39:27,620
Actually the researchers were working with
are about to publish a new paper about how
434
00:39:27,620 --> 00:39:36,470
to tune decoy traffic and latency for the
desired entropy you want in each mix,
435
00:39:36,470 --> 00:39:41,200
yeah.
Herald: Microphone number two, your
436
00:39:41,200 --> 00:39:45,060
question?
Mic 2: You have mentioned that the in
437
00:39:45,060 --> 00:39:50,510
mixed networks PKI's have higher
scalability problems than in Tor - why is
438
00:39:50,510 --> 00:39:54,890
that? It looks like the mix Network will
have less nodes because the you don't need
439
00:39:54,890 --> 00:39:59,400
route unpredictability, so
J: I mean if you're trying to build a
440
00:39:59,400 --> 00:40:03,230
replacement for email and you want
everyone in the world to use it, if you
441
00:40:03,230 --> 00:40:10,060
work through like, a sort of very bullshit
back of the envelope computation -
442
00:40:10,060 --> 00:40:17,810
there's an argument that your that if you
have a central that a centralized PKI plus
443
00:40:17,810 --> 00:40:22,610
whatever other anonymity system is only
about 10 million times better than just
444
00:40:22,610 --> 00:40:27,790
sending every message to everybody.
Something, you know, that's very back of
445
00:40:27,790 --> 00:40:37,090
the envelope you can try and work. So you
need; yeah well okay so there's that, and
446
00:40:37,090 --> 00:40:41,600
and the the specific seeing when I said
it's less of a problem for tor, is that
447
00:40:41,600 --> 00:40:44,020
tor can do certain clever
things like there's a,
448
00:40:44,020 --> 00:40:47,070
there's one of their proposals I think is
actually not taking that seriously at the
449
00:40:47,070 --> 00:40:52,150
moment is where they published this big
list - they published the PKI or sorry,
450
00:40:52,150 --> 00:40:57,890
the big the the thing and nodes don't
actually download the whole, the the whole
451
00:40:57,890 --> 00:41:02,290
consensus at all. They just point to a
place in the consensus and they get back a
452
00:41:02,290 --> 00:41:06,170
proof that they were given the correct
that they were forwarded to the correct
453
00:41:06,170 --> 00:41:10,240
node. So this might this then gives you
another order of magnitude or two on that
454
00:41:10,240 --> 00:41:16,370
fat on that you know 10 million
I just quoted you.
455
00:41:16,370 --> 00:41:22,090
Herald: Okay, microphone number three
Mic 3: Hi, this is looks like really good
456
00:41:22,090 --> 00:41:26,980
work and I'm happy to see it - now my
question is if there are multiple
457
00:41:26,980 --> 00:41:30,530
applications which have different tuning
requirements, can they share the same
458
00:41:30,530 --> 00:41:34,160
network and help each others anonymity
set, or do we have to have multiple
459
00:41:34,160 --> 00:41:38,610
networks?
D: Ah, so we agree it would be best if
460
00:41:38,610 --> 00:41:43,130
they could help each other by increasing
each other's anonymity set. But we're
461
00:41:43,130 --> 00:41:48,720
concerned that the specific tuning for the
decoy traffic might prohibit this in some
462
00:41:48,720 --> 00:41:54,110
cases. For -- actually, and there's some
other considerations as well, so since
463
00:41:54,110 --> 00:41:59,510
we're not stream oriented, all the data
has to fit in one packet. And so if we
464
00:41:59,510 --> 00:42:04,490
have like an email use case, we probably
are gonna get around 50 K average size
465
00:42:04,490 --> 00:42:10,430
emails, let's say. And if we want to make
like mix chat or Katzen chat application,
466
00:42:10,430 --> 00:42:15,650
I might send really short messages like,
"yo what's up", and now we're sending that
467
00:42:15,650 --> 00:42:19,570
in a big 50 K a packet.
J: So, one thing that is clear - if you
468
00:42:19,570 --> 00:42:23,320
wouldn't do it for all, think you wouldn't
have a new thing for every application.
469
00:42:23,320 --> 00:42:26,210
Obviously if you have something that's
gonna be quite infrequent like a payment
470
00:42:26,210 --> 00:42:32,070
thing, then it needs then you should be
using a network with with much more
471
00:42:32,070 --> 00:42:36,480
frequent packets and just accept that
you're gonna be you -- accept though the
472
00:42:36,480 --> 00:42:40,560
inefficiency. D: And there's another
consideration too - it, which is,
473
00:42:40,560 --> 00:42:45,320
sometimes in these chat applications,
communication partnerships might be
474
00:42:45,320 --> 00:42:48,510
symmetrical in that we
might send each other roughly the same
475
00:42:48,510 --> 00:42:53,560
amount of data. And and stuff that, like
not that I don't think mix Nets are good
476
00:42:53,560 --> 00:42:58,230
for web browsing, but in stuff like the
web it's more like "get to page" and then
477
00:42:58,230 --> 00:43:02,490
you get a bunch of information back. So
there's a lot of different; so what would
478
00:43:02,490 --> 00:43:08,470
the decoy traffic look like that versus a
symmetrical communication partnership. So
479
00:43:08,470 --> 00:43:13,140
that's what I meant by some applications
might not be compatible with each other to
480
00:43:13,140 --> 00:43:17,250
tune this decoy traffic
J: Yeah we certainly would hope that most
481
00:43:17,250 --> 00:43:21,550
sort of like peer-to-peer, that, you know
most sort of peer-to-peer like all of your
482
00:43:21,550 --> 00:43:25,630
etherpad, your other sort of collaborative
applications, your email, your payment
483
00:43:25,630 --> 00:43:28,611
network - we'd certainly hope that all
that stuff could be bundled onto one thing
484
00:43:28,611 --> 00:43:33,750
that was sort of optimized for this email-
like use case. And then whether if you
485
00:43:33,750 --> 00:43:40,570
actually need the instant messaging
network at all is another question.
486
00:43:40,570 --> 00:43:44,580
Herald: All right, microphone number one
what's your question?
487
00:43:44,580 --> 00:43:49,280
Mic 1: Um, can you give well can you give
more concrete examples of software to try
488
00:43:49,280 --> 00:43:54,610
out or like, so like like papers are
great, like is there anything to touch to
489
00:43:54,610 --> 00:43:57,850
act to, whatever
D: Well well, I mean, actually right now
490
00:43:57,850 --> 00:44:03,250
we're running a test mix Network on
several machines that we had lying around,
491
00:44:03,250 --> 00:44:08,240
and it works great - thanks for (meskhi
oh) and (kali) for their help for that.
492
00:44:08,240 --> 00:44:14,460
But, we don't really have any anything
near production-ready, like
493
00:44:14,460 --> 00:44:21,300
J: Yeah the stuff I was talking about
doesn't even work.
494
00:44:21,300 --> 00:44:27,590
D: So the answer to question is: no, we
got nothing. But but we hope we hope soon.
495
00:44:27,590 --> 00:44:31,510
Like, I'm not sure how soon, but
J: Depends on funding, depends on other
496
00:44:31,510 --> 00:44:37,750
things: we're working on it.
Herald: Thank you, microphone two: what is
497
00:44:37,750 --> 00:44:41,420
your question?
Mic 2: I was thinking about this in the
498
00:44:41,420 --> 00:44:47,380
real world - you're envisioning an app
where people can communicate, and I worry
499
00:44:47,380 --> 00:44:54,930
about mobile telephones because; let's
envision two users using this app to
500
00:44:54,930 --> 00:44:58,950
communicate with each other. The idea
would be that one person sends a message
501
00:44:58,950 --> 00:45:02,260
and then sometime later this
other person takes their phone out
502
00:45:02,260 --> 00:45:06,180
of their pocket. There is so much going
on when a phone comes out of a pocket and
503
00:45:06,180 --> 00:45:12,270
as the screen is turned on. WhatsApp is
talked to; there's so much that that you
504
00:45:12,270 --> 00:45:17,190
can look at outside of this whole mix
Network that if you, over a month of time,
505
00:45:17,190 --> 00:45:22,220
can correlate who picks their phone out of
their pockets every time when, when person
506
00:45:22,220 --> 00:45:25,680
sends a message. So can't you correlate
that way and isn't that a huge problem
507
00:45:25,680 --> 00:45:29,940
that, that sort of is completely outside
of the world of the of the problems you're
508
00:45:29,940 --> 00:45:34,780
thinking about.
J: My, in my ideal; I have no idea. In my
509
00:45:34,780 --> 00:45:40,480
ideal world the part of the solution to
making the users happier with latency is
510
00:45:40,480 --> 00:45:45,340
the phone doesn't ding anymore. You don't
get notifications - you check your phone
511
00:45:45,340 --> 00:45:51,720
when you check your phone.
Mic 2: Sorry, I think that would be an
512
00:45:51,720 --> 00:45:55,690
important security property as well.
J: But I would actually like it there's a
513
00:45:55,690 --> 00:45:59,960
question here is: would that make people
actually happier with latency? What can
514
00:45:59,960 --> 00:46:03,330
you, I mean, you you know all of these
things that are being built now are being
515
00:46:03,330 --> 00:46:07,530
built to sort of maximize engagement. And
you want to actually, you actually don't
516
00:46:07,530 --> 00:46:10,670
want to do that anymore. You want people
to only use it when they want to you know
517
00:46:10,670 --> 00:46:19,490
when they want to use it.
Herald: All right, thank you. Seems there
518
00:46:19,490 --> 00:46:24,480
are no further questions, so thanks a lot
to Jeff, thanks a lot to David
519
00:46:24,480 --> 00:46:34,655
Applause
520
00:46:34,655 --> 00:46:39,637
Music
521
00:46:39,637 --> 00:46:52,000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!