WEBVTT
00:00:00.000 --> 00:00:16.300
Music
Herald: The next talk coming up is going
00:00:16.300 --> 00:00:20.770
to be "Practical mix network designs,
strong metadata protection for
00:00:20.770 --> 00:00:28.990
asynchronous messaging", held by by David,
who has done research on mix networks and
00:00:28.990 --> 00:00:35.530
is a contributor to Tor network, and by
Jeff, who has done contribution to the GNU
00:00:35.530 --> 00:00:40.420
network project, organized a couple of
sessions for this on last year's Congress
00:00:40.420 --> 00:00:46.280
and is basically a mathematician, trying
to get practical. they're going to talk
00:00:46.280 --> 00:00:54.879
about components on mix networks and
defenses that basically Tor can't do. And,
00:00:54.879 --> 00:01:03.010
yeah. Welcome with a big round of
applause, okay.
00:01:03.010 --> 00:01:12.229
applause
Jeff: Okay, so I'm Jeff, this is David,
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
00:01:16.549 --> 00:01:22.520
designing mix networks. The, I'm involved
with the I'm an academic involved with the
00:01:22.520 --> 00:01:30.820
GNUnet project, he's involved with the
Panoramix project. Okay, so first of all
00:01:30.820 --> 00:01:37.820
we, just to be clear, of course encryption
works, you know, if it's, you know,
00:01:37.820 --> 00:01:42.270
properly implemented and then, you know,
we have a huge amount of trust in it, we
00:01:42.270 --> 00:01:46.490
we even have, you know, sort of slides
showing that the most powerful adversaries
00:01:46.490 --> 00:01:51.240
in the world can't can't can't break these
things, so this is fine.
00:01:51.240 --> 00:01:57.100
However we have to worry about sort of
about the metadata leakage or and in this
00:01:57.100 --> 00:02:01.370
talk we're specifically going to be
worrying about traffic analysis of of
00:02:01.370 --> 00:02:08.650
connections. inhales So, yeah, it's time
to, it's time to actually start addressing
00:02:08.650 --> 00:02:14.610
these things. Okay. So existing solutions
to traffic analysis. So there's this
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
00:02:22.420 --> 00:02:29.030
consider the the even the NSA considered
considered Tor to be quite effective at
00:02:29.030 --> 00:02:35.510
preventing mass location tracking. So this
is, so Tor works for what it's designed to
00:02:35.510 --> 00:02:44.840
do, Tor does not protect against an
adversary who can see both ends of the Tor
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
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
00:02:59.400 --> 00:03:04.630
you have a website of course then somebody
can have fingerprinted this website in
00:03:04.630 --> 00:03:10.720
advance, have some, you know, description
of its of its traffic profile and they can
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
00:03:15.080 --> 00:03:18.390
you're accessing that that website over
Tor.
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
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
00:03:28.570 --> 00:03:33.510
going to be able to defeat that kind of
adversary very quickly. But okay, can we
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
00:03:36.990 --> 00:03:42.690
Ricochet there's Briar; the problem with
using Tor as a messaging as a messaging
00:03:42.690 --> 00:03:48.890
transport layer is that frequently, the
people you want to protect, are in the
00:03:48.890 --> 00:03:54.540
same country or even on the same ISP, so
the original property of, you know, the
00:03:54.540 --> 00:03:57.670
adversary being able to see both sides of
the connection comes comes through again
00:03:57.670 --> 00:04:01.270
and they can very quickly be - that
connection between them can very quickly
00:04:01.270 --> 00:04:07.630
be seen. So okay, how can we actually keep
our messaging metadata private? And the
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
00:04:11.610 --> 00:04:13.850
network.
David: Oh yeah, so mixed networks are
00:04:13.850 --> 00:04:18.810
message oriented, as opposed to stream
oriented. They are essentially an
00:04:18.810 --> 00:04:27.340
unreliable packet switching network. And
also latency is added at each hop. This is
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
00:04:35.060 --> 00:04:40.660
architectural diagram. Notice there's no
exit nodes, there's no talking to the web
00:04:40.660 --> 00:04:47.910
like with Tor, so the security model is
different, we do have a PKI, similar to
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
00:04:57.150 --> 00:05:04.480
differences between Tor and mix nets and
one of the important ones is that we can
00:05:04.480 --> 00:05:09.450
actually do decoy traffic everywhere in
this diagram, like we can do decoy traffic
00:05:09.450 --> 00:05:13.280
all the way to clients or to the
destination.
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
00:05:20.810 --> 00:05:26.570
even if you wanted to add decoy traffic
you couldn't hide the - you couldn't
00:05:26.570 --> 00:05:30.340
protect against this website
fingerprinting attack necessarily, because
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,
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,
00:05:39.430 --> 00:05:43.490
just some history here, mixed networks are
actually the the oldest anonymity system
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
00:05:50.370 --> 00:05:54.750
that have been proposed; one of them is
private information retrieval, usually
00:05:54.750 --> 00:05:57.900
written PIR.
This works in sort of narrow situations,
00:05:57.900 --> 00:06:02.000
when you're trying to retrieve something
from some kind of database. The scaling
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
00:06:08.380 --> 00:06:12.140
other the other one that sort of is
generally proposed is the alternative to
00:06:12.140 --> 00:06:16.770
mix networks is dining cryptographers
networks. And the problem with them is
00:06:16.770 --> 00:06:24.560
that the bandwidth is really literally,
you know, each you're paying literally for
00:06:24.560 --> 00:06:31.150
the quadratic cost per user, so I mean
something like cubic. so the your
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
00:06:37.770 --> 00:06:42.580
talking about building something that has
inherently has a small anonymity set then
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
00:06:49.389 --> 00:06:53.220
protecting whistleblowers anymore, because
of whistle- if a whistleblower talks to,
00:06:53.220 --> 00:06:56.770
you know, journalists and it's unclear
which journalists, you know, Der Spiegel
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
00:07:02.630 --> 00:07:06.530
thing, who talked to somebody at Der
Spiegel. So and more as it does protect,
00:07:06.530 --> 00:07:11.730
you know, it doesn't, you know, it the
person that it does protect is somebody
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-
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
00:07:20.639 --> 00:07:22.790
possible and that's why we like mix
networks.
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
00:07:27.060 --> 00:07:33.180
defenses. Epistemic attacks are not one of
the attacks we're really going to focus on
00:07:33.180 --> 00:07:37.199
because it's it's really a specialized
area of research; there's actually a bunch
00:07:37.199 --> 00:07:44.840
a few papers, written on breaking
different public-key infrastructure
00:07:44.840 --> 00:07:49.680
systems for like things like point-to-
point networks and other other things like
00:07:49.680 --> 00:07:51.750
that.
J.: So, oh, so..
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 -
00:07:58.960 --> 00:08:06.199
mix literature assumes you have a PKI, it
assumes that the all the clients using it
00:08:06.199 --> 00:08:08.831
somehow know about the whole network.
J.: So
00:08:08.831 --> 00:08:13.110
D.: Yeah, g...
J.: So so usually when P - anonymity
00:08:13.110 --> 00:08:16.210
researchers talk about a PKI, they
generally assume something like the Tor
00:08:16.210 --> 00:08:19.470
directory authority system, where you have
some people, who can be very trusted, who
00:08:19.470 --> 00:08:23.080
run the thing. This actually presents a
scalability problem- it's what's goin- it's
00:08:23.080 --> 00:08:27.639
what's the cuts(?) and post-project(?) and
and ever- and Panoramix is doing; it does
00:08:27.639 --> 00:08:33.139
present a scalability problem, more
serious than the one for Tor. The there
00:08:33.139 --> 00:08:38.078
are other ideas you can do, there's there,
so on the try, on the idea
00:08:38.078 --> 00:08:42.399
of sort of making it more secure beyond
just these people, there's projects like
00:08:42.399 --> 00:08:46.970
(???)thority and things and on the - but
on trying to make it more scalable,
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
00:08:50.689 --> 00:08:55.500
researching this. In past generally these
peer-to-peer networking projects to try
00:08:55.500 --> 00:09:01.290
and come up with, you know, distributed
PKI, had very serious attacks against
00:09:01.290 --> 00:09:05.369
them; these epistemic and especially these
epistemic attack types things, so and
00:09:05.369 --> 00:09:09.009
you're not gonna completely fix those, so
the way that you would have a distributed
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
00:09:14.300 --> 00:09:19.559
argue that this is better than some nine
people or whatever possibly being
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
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
00:09:26.240 --> 00:09:32.379
there and right now - so since we were
leading from the epistemic attacks David's
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
00:09:36.180 --> 00:09:39.620
gonna tell you about how the scalability
comes in.
00:09:39.620 --> 00:09:46.449
D.: Yeah, so Tor, oh, so, sorry, mix nets
can use cascade topologies where everyone
00:09:46.449 --> 00:09:52.009
uses the same route and this is quite a
different than tor where route
00:09:52.009 --> 00:09:58.659
unpredictability is used to achieve some
of it's anonymity properties. So in mixed
00:09:58.659 --> 00:10:04.209
nets you can use the same route as
everybody but this is a scalability
00:10:04.209 --> 00:10:12.949
problem. So we have other things like free
route and also stratified topology but
00:10:12.949 --> 00:10:18.139
free route actually has slightly worse
anonymity. Claudia Diaz has got an
00:10:18.139 --> 00:10:22.010
excellent paper and about this.
J.: Another kind of point about free route
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
00:10:26.541 --> 00:10:31.509
grew away from that. Nodes are authorized
to be in specific positions and things
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
00:10:36.339 --> 00:10:42.610
anyway even if you tried
D.: oh yeah. exit versus guard flags for
00:10:42.610 --> 00:10:50.990
tor. This is another diagram of the... any
layer, any mixin layer 0 can connect to
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
00:10:58.609 --> 00:11:05.320
design, we're gonna be mentioning some
more designed from loop picks. The cool
00:11:05.320 --> 00:11:10.699
thing about this is, it's fairly easy to
calculate the entropy of each mix compared
00:11:10.699 --> 00:11:17.420
to say free route, which is pretty
complicated. This also scales pretty well,
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
00:11:22.319 --> 00:11:26.389
users.
D.: So we're gonna mention a couple,
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
00:11:31.050 --> 00:11:35.899
critical, but the one on this one... yeah,
Claudia Diaz has a very nice paper for
00:11:35.899 --> 00:11:41.029
understanding the different ideologies.
J.: And I believe Roger has a paper on
00:11:41.029 --> 00:11:46.759
this topic as well.
D.: Ok, so why isn't this tor? Well, the
00:11:46.759 --> 00:11:50.759
main thing that we can say is that tor
doesn't actually mix. if the packets
00:11:50.759 --> 00:11:54.390
are... The packets coming in at a
particular point in time are basically the
00:11:54.390 --> 00:12:01.649
same packets going out. You pretty much
know within a very small number. So what a
00:12:01.649 --> 00:12:05.649
mixed strategy actually does. This is an
algorithm that's part of the software to
00:12:05.649 --> 00:12:10.989
do the thing. What a mixed strategy
actually does is it adds latency to reduce
00:12:10.989 --> 00:12:18.289
the correlation between packets.
And there's yeah ...
00:12:18.289 --> 00:12:25.959
J.: So David Chum in 1981 with this first
mix net paper describe this threshold mix.
00:12:25.959 --> 00:12:30.139
So say this mix had a threshold of four.
It would accumulate four input messages
00:12:30.139 --> 00:12:35.929
like this. And when it had enough for its
threshold, then it would shuffle them and
00:12:35.929 --> 00:12:40.820
send them out. Mixes are also unwrapping a
layer of encryption for each of these
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
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
00:12:54.110 --> 00:12:59.110
into it. And then when a target message
enters this mix I could send my own
00:12:59.110 --> 00:13:03.999
messages and cause it to achieve its
threshold and shuffle and send all the
00:13:03.999 --> 00:13:09.110
messages out. So then I would recognize
all the cipher texts of my own messages
00:13:09.110 --> 00:13:11.360
and the one message
I don't recognize it's the
00:13:11.360 --> 00:13:15.629
target message. You can keep doing this
for each hop and this is called a
00:13:15.629 --> 00:13:21.110
n-minus-1 attack or blending attack.
There's a lot of variations on them. We
00:13:21.110 --> 00:13:26.700
have continuous-time mixes like the stop-
and-go mix and the poisson-mixed
00:13:26.700 --> 00:13:31.529
strategies. These mixed strategies allow
the client to select the delays for each
00:13:31.529 --> 00:13:41.139
hop. Usually they're from an exponential
distribution. If an attacker wants to
00:13:41.139 --> 00:13:47.799
break this using a blending attack, first
they need to empty the mix queue by
00:13:47.799 --> 00:13:52.389
blocking all input messages from the mix
and waiting some period of time where it's
00:13:52.389 --> 00:13:57.949
highly probable that the mix queue would
then be empty. Then they would allow their
00:13:57.949 --> 00:14:03.199
one target message to enter the mix and
continue to block other input messages and
00:14:03.199 --> 00:14:11.290
then simply wait for that message to be
outputted. Now these attacks we have some
00:14:11.290 --> 00:14:17.059
defense for them, like say a heartbeat
protocol from, George wrote a paper about
00:14:17.059 --> 00:14:22.779
ten years ago, George Danezis. It's also
in the Loopix paper as well, it's
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
00:14:31.600 --> 00:14:35.580
mixed loops or heartbeat traffic, where a
mix is sending itself a message. It's like
00:14:35.580 --> 00:14:38.920
a self-addressed stamped envelope. It's
going through the mix network and coming
00:14:38.920 --> 00:14:46.299
back. And if it doesn't receive its
heartbeat in some time out, it knows it
00:14:46.299 --> 00:14:50.040
could be under attack or of course there
could be other problems in the network as
00:14:50.040 --> 00:14:57.429
well. So you would want to maybe correlate
a attack with several failures to receive
00:14:57.429 --> 00:15:03.110
a heartbeat message.
There's other defenses for blending
00:15:03.110 --> 00:15:06.370
attacks as well. There was a recent paper
published, but we're not going to talk
00:15:06.370 --> 00:15:14.800
about that right now. The next category of
attack is statistical disclosure attacks.
00:15:14.800 --> 00:15:20.320
This is essentially, I like to think of it
as the adversary is abstracting the entire
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
00:15:25.760 --> 00:15:31.559
come out. A lot of this literature is
written from the perspective of like
00:15:31.559 --> 00:15:36.359
point-to-point networks. Like when Alice
and Bob were receiving messages from the
00:15:36.359 --> 00:15:40.300
mixed network they're receiving it at
their home IP addresses, as if we had
00:15:40.300 --> 00:15:45.589
publicly routable IP addresses and no NAT
devices to get in the way. Maybe a more
00:15:45.589 --> 00:15:52.670
modern sort of architecture might involve
queuing messages. This is a concept used
00:15:52.670 --> 00:15:58.629
in Loopix design as well.
Loopix has got a bunch of different decoy
00:15:58.629 --> 00:16:05.819
traffic types in order to add noise to the
signal at various locations in the
00:16:05.819 --> 00:16:13.980
network. So there's drop decoy traffic,
where a client would select a random
00:16:13.980 --> 00:16:18.820
destination provider to send a message to.
So it traverses the mix net and then gets
00:16:18.820 --> 00:16:26.920
dropped by the provider. And there's also
client loops, and actually I should
00:16:26.920 --> 00:16:32.619
mention, if we're doing these kind of
statistical disclosure attacks, a lot of
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
00:16:36.980 --> 00:16:42.490
depends on a specific application and the
adversaries ability to predict users
00:16:42.490 --> 00:16:47.990
behavior and that behavior should be
repetitive. I mean this depends on how
00:16:47.990 --> 00:16:53.420
much information is leaked by the system.
But mix networks always leak information,
00:16:53.420 --> 00:16:59.980
so it's it's about measuring the leakage
and understanding if the user behavior is
00:16:59.980 --> 00:17:06.859
dynamic enough.
These attacks cannot always converge on
00:17:06.859 --> 00:17:14.309
success. So it depends on the particular
system and how it's tuned. In this
00:17:14.309 --> 00:17:20.359
particular case for queuing messages in
this style mixed network the adversary
00:17:20.359 --> 00:17:27.880
would have to compromise the destination
providers. So previously here in this
00:17:27.880 --> 00:17:32.210
situation it would be, in this point-to-
point network situation where people are
00:17:32.210 --> 00:17:37.570
actually receiving messages from the mixed
network to their mailbox directly or to
00:17:37.570 --> 00:17:44.740
their home IP, the adversary is a passive
adversary. In the more modern architecture
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
00:17:50.120 --> 00:17:57.059
which is a recent paper, so this attack
becomes an active attack. And there's some
00:17:57.059 --> 00:18:01.960
padding to the clients so we have some
amount of receiver unobservability, so
00:18:01.960 --> 00:18:07.419
clients received the same amount of
information when they received messages.
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
00:18:10.760 --> 00:18:14.559
latency and we are also talking about
adding cover traffic. So you might ask "Is
00:18:14.559 --> 00:18:21.880
this enough?" and "Could I get away with
less?". And the answer to "Could I get
00:18:21.880 --> 00:18:32.820
away with less?" seems to be no. At least
by some artificial measures your anonymity
00:18:32.820 --> 00:18:39.019
can't really scale better than the cover
traffic times the latency. So one takeaway
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
00:18:45.669 --> 00:18:51.539
people that they don't know, if adding
cover traffic to Tor would help. And one
00:18:51.539 --> 00:18:55.450
sort of extreme version of this is of
course, whatever cover traffic you add
00:18:55.450 --> 00:19:03.500
times something very small is still
something rather relatively small. Now
00:19:03.500 --> 00:19:07.039
you'll notice here of course the anonymity
still looks quadratic in something but
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
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
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
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
00:19:27.539 --> 00:19:31.440
one thing, so sometimes people have made
these just to sort of wrap up this section
00:19:31.440 --> 00:19:36.340
about topologies and whatever and
strategies and things, so people have made
00:19:36.340 --> 00:19:40.980
these sort of quasi religious statements
about encryption from time to time. To
00:19:40.980 --> 00:19:45.960
sort of boil that down to something
concrete encryption is basically free in
00:19:45.960 --> 00:19:50.750
general and but for the mixed network
we're going to have to actually pay some
00:19:50.750 --> 00:19:56.160
kind of real costs.
Okay, so one thing about mix networks, you
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
00:20:01.200 --> 00:20:05.910
very reasonable one, it's sort of the one
that has stopped much of the development
00:20:05.910 --> 00:20:11.460
in this area, is Sphinx. It's quite
compact, and it has a very nice security
00:20:11.460 --> 00:20:16.990
proof, it's by George Danezis and Ian
Goldberg. So just to comment on the name,
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
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
00:20:24.820 --> 00:20:28.500
the time that was developed the only wide
block cipher the people were thinking
00:20:28.500 --> 00:20:35.720
about was lioness. There's now some other
wide block ciphers like AEZ by Rogaway and
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
00:20:42.350 --> 00:20:47.370
packet format. So the header has three
parts, but one of them, the first part is
00:20:47.370 --> 00:20:53.139
a public key this elliptic curve point,
and then there's this body, which is
00:20:53.139 --> 00:20:57.510
encrypted with a wide box cipher. So the
way you think about this mix node n
00:20:57.510 --> 00:21:04.840
operating is, Alice, you know there's this
key exchange between the mix node and
00:21:04.840 --> 00:21:10.710
Alice, that Alice first does it. She
thinks up this is key for her packet and
00:21:10.710 --> 00:21:16.029
does the exchange and then the mix node
computes the other side of the Diffie-
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
00:21:21.140 --> 00:21:27.981
the different things. So what Sphinx is,
is the rules for how to mutate those. Okay
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
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
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?
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
00:21:46.309 --> 00:21:52.590
using an unMACed stream cipher than some
adversary who controls a mix node next to
00:21:52.590 --> 00:21:58.030
the sender and someplace where the message
is going, could just XOR an arbitrary
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
00:22:05.120 --> 00:22:10.860
stream cipher, we use a wide block cipher.
So what this means is, an attacker doing
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
00:22:18.460 --> 00:22:24.650
an attack. Why would we tolerate even a
one bit tagging attack? And the answer is
00:22:24.650 --> 00:22:34.280
that anonymous receivers really matter. So
there's a few things, so of course a
00:22:34.280 --> 00:22:38.230
journalistic source, some sort of
whistleblower or whatever, but also any
00:22:38.230 --> 00:22:41.970
kind of service, like if you want to talk
to some crypto currency network, or you
00:22:41.970 --> 00:22:46.071
want to talk to or download some file, or
anything like this, anything where you
00:22:46.071 --> 00:22:52.139
interact with a service or you need some
kind of acknowledgment back of it. And in
00:22:52.139 --> 00:22:59.640
fact even just the basic protocol acts for
a messaging system need some sort of
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
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
00:23:12.570 --> 00:23:20.919
date, and then the header and one
cryptographic key for one layer of it. And
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
00:23:28.710 --> 00:23:34.330
the past. the sender attaches their Delta
and they can send to the recipient.
00:23:34.330 --> 00:23:45.429
Okay so great, now okay, now let's get
into something tricky. We have these
00:23:45.429 --> 00:23:51.879
common... Okay we might worry, so if you
looked at the key exchange that I did,
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
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
00:24:07.289 --> 00:24:10.660
protocols to be forward secure and you
know TOR is forward secure. It doesn't
00:24:10.660 --> 00:24:16.480
negotiate, live negotiation with the top
which is great. But we need some kind of
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
00:24:23.509 --> 00:24:30.129
first of all a mixed net, we need some
kind of replay attack protection anyway.
00:24:30.129 --> 00:24:38.450
So what this requires, some sort of data
structure that will eventually fill up or
00:24:38.450 --> 00:24:43.569
overflow or something like this. So to
prevent that we have to do key rotation
00:24:43.569 --> 00:24:47.870
anyway. So one option is to just rotate
the mix node keys faster. The problem with
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
00:24:52.320 --> 00:24:58.600
scaling pain. So, okay. But another
problem with that is that these SURB
00:24:58.600 --> 00:25:04.270
lifetimes are equal to the node key life,
they can't exceed the node key lifetimes.
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
00:25:09.789 --> 00:25:15.090
compromise window smaller than the node
key lifetimes or then we have to do, or -
00:25:15.090 --> 00:25:19.559
you know smaller than the server lifetimes
- and we have to do something else. So
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;
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
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
00:25:35.210 --> 00:25:40.710
using two packets in different key epochs.
That's pretty good, that that gives you,
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
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
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
00:25:58.470 --> 00:26:04.691
you can use a double ratchet construction
for some hops. And that the this, problem
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
00:26:11.169 --> 00:26:17.250
do them at all hops, because they create
some correlations between packets. So,
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
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
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
00:26:33.360 --> 00:26:39.519
about the different stra- different sort
of basic technologies for key exchanges
00:26:39.519 --> 00:26:43.960
and the properties we can get out of them
in the context of Sphinx.
00:26:43.960 --> 00:26:48.139
And, you know, anything that's based on
elliptic curves is not going to be post
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
00:26:52.809 --> 00:26:55.950
something else so there was a blinding
operations in Sphinx I didn't tell you
00:26:55.950 --> 00:27:00.039
about, doing that in the post quantum
context is tricky. Probably it works for
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
00:27:05.720 --> 00:27:10.909
efficiently, maybe it can be done. Our
cheating strategy gives us nice key
00:27:10.909 --> 00:27:16.059
erasure properties, it gives us post
quantum, if the loop if the loop did a
00:27:16.059 --> 00:27:20.710
post quantum key exchange and there's
another nice property that it gives, that
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
00:27:24.700 --> 00:27:29.809
hybrid - you can actually have a hybrid
post quantum property, and that means that
00:27:29.809 --> 00:27:33.759
you can use both an elliptic curve and
this post quantum key exchange and if
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
00:27:39.010 --> 00:27:43.570
and do this construction with something
like LWE you're probably not going to be
00:27:43.570 --> 00:27:47.111
able to get that hybrid post quantum
property, 'cause the blinding operation
00:27:47.111 --> 00:27:51.080
itself will depend on the LWE
cryptographic assumptions.
00:27:51.080 --> 00:27:58.240
So nevertheless I want to conjecture that
LWE (?????????) LWE means "learning with
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
00:28:03.899 --> 00:28:07.630
mathematicians love conjectures, so I
don't think there's one with blinding but
00:28:07.630 --> 00:28:14.590
I think we can probably come up with
something that eventually, where we have
00:28:14.590 --> 00:28:19.750
some kind of nice blinding for the an LWE
scheme and it even has puncturing.
00:28:19.750 --> 00:28:23.499
Punctured encryption is something that you
can currently do with pairing based crypto
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
00:28:30.639 --> 00:28:37.450
faster with LWE. Okay
D.: Okay, so mix networks: they're
00:28:37.450 --> 00:28:43.770
unreliable, they're packet switching, so
in that case some classical Network
00:28:43.770 --> 00:28:51.831
literature can can be applied. Now an
automatic repeat request protocol scheme
00:28:51.831 --> 00:28:56.820
is one of those protocol schemes that has
protocol acknowledgments and retransmits
00:28:56.820 --> 00:29:01.870
and we can do this over mix networks but
it leaks extra information. Every ACK you
00:29:01.870 --> 00:29:07.699
send could potentially be used as in a
correlation attack, for instance if the
00:29:07.699 --> 00:29:12.909
adversary causes the ACK packet to be
dropped. And in a stopping way ARQ(?) the
00:29:12.909 --> 00:29:18.370
simplest variety of these protocols, would
leak the least amount of information, so
00:29:18.370 --> 00:29:26.960
that's what we're using and we have three
cryptographic layers in our stack right
00:29:26.960 --> 00:29:35.210
now in this Loopix Katzenpost project
we're working on. Yawning(?) angel wrote a
00:29:35.210 --> 00:29:42.029
cryptographic link layer based on the
noise cryptographic framework. He's mixing
00:29:42.029 --> 00:29:49.509
new hope simple(?) with x25509 and the key
exchange and we also have a Sphinx
00:29:49.509 --> 00:29:55.900
cryptographic layer. Sphinx is what Jeff
talked about earlier, the cryptographic
00:29:55.900 --> 00:30:02.249
packet format and we also have an end-to-
end cryptographic messaging. And this is
00:30:02.249 --> 00:30:08.519
another sort of Loopix style diagram:
Alice sends message to Bob's provider, so
00:30:08.519 --> 00:30:14.870
it goes through the mix network to Bob and
Bob can retrieve his message later and
00:30:14.870 --> 00:30:20.820
with some relatively simple changes from
this Loopix design, we can, to have
00:30:20.820 --> 00:30:26.820
stronger location hiding properties, where
Alice and Bob don't talk directly to the
00:30:26.820 --> 00:30:32.010
provider that they're retrieving messages
from. They can send single-use reply
00:30:32.010 --> 00:30:37.520
blocks to retrieve messages this would
increase latency.
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
00:30:40.240 --> 00:30:46.240
time certain schemes in academia tend to
use, want to use PIR for this retrieving,
00:30:46.240 --> 00:30:52.950
the the thing I thought from your from
your provider and then the - one of the
00:30:52.950 --> 00:30:58.309
problems with using a PIR scheme here is
that you're gonna have very different very
00:30:58.309 --> 00:31:03.070
different sort of assumptions at play
there and the way even what you model it
00:31:03.070 --> 00:31:07.860
is going to be necessary necessarily quite
complex. It's probably fun if you're a
00:31:07.860 --> 00:31:11.480
graduate student, you know, doing, playing
with all this stuff but it's actually
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
00:31:17.450 --> 00:31:21.220
scheme they were talking about here you
actually, you're your mix net is giving
00:31:21.220 --> 00:31:24.890
you your location hiding property so you
can you can extract some similar things.
00:31:24.890 --> 00:31:29.620
D.: Well, right and also, whereas in this
situation, with a Loopix design it doesn't
00:31:29.620 --> 00:31:36.330
have strong location hiding properties, in
particular if Alice really wanted to
00:31:36.330 --> 00:31:42.429
figure figure out where Bob is she would
hack his provider and then stake it out
00:31:42.429 --> 00:31:46.780
until his IP address showed up again or so
-
00:31:46.780 --> 00:31:52.070
J.: One problem with this, with these
provider models, is that, like David just
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
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
00:32:03.830 --> 00:32:07.990
packet format but it's a good idea to go
through the security proof again anyway
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
00:32:14.590 --> 00:32:21.210
harddrive picture, is is some sort of of
mailbox server or cumulation thing, that
00:32:21.210 --> 00:32:27.249
the receiver here can move whenever he
wants without telling his contacts. And
00:32:27.249 --> 00:32:31.580
his contacts actually reach him in other
ways; either he gives them SURBs or he
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
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
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
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
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
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
00:33:03.929 --> 00:33:08.100
like, okay well, in three months - you
know they're not going to be able to
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
00:33:12.880 --> 00:33:19.809
this guy in the middle periodically.
Okay, so but this is work, very much work
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
00:33:22.780 --> 00:33:28.690
Sphinx and doing doing some redoing a
number of proofs. So, okay, we've been
00:33:28.690 --> 00:33:35.690
talking about applications with the idea
being messaging. There's other
00:33:35.690 --> 00:33:41.150
applications and - where you're still
sending messages but to give you a bit
00:33:41.150 --> 00:33:46.850
more, something a bit more concrete:
There's a there's a few schemes for doing
00:33:46.850 --> 00:33:49.340
anonymous money, well right now there's a
lot of schemes for doing anonymous money
00:33:49.340 --> 00:33:52.490
and mostly they suck but there's a few
that are actually quite good and have
00:33:52.490 --> 00:33:58.289
extremely strong cryptographic assurances
on their anonymity: Zcash you basically
00:33:58.289 --> 00:34:01.049
would have to invert a hash function or
something to break it, I'm not completely
00:34:01.049 --> 00:34:07.799
sure, Taler, well in in the RSA blind
signatures have information theoretically
00:34:07.799 --> 00:34:10.460
secure blinding, which means they are
absolutely unbreakable.
00:34:10.460 --> 00:34:11.750
There's a point in Taler where it's weaker
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.
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
00:34:23.840 --> 00:34:30.449
free nets, so you could use it to ship
things over a mix network. But,
00:34:30.449 --> 00:34:33.980
fundamentally, if you imagine what we want
to do is like build build some application
00:34:33.980 --> 00:34:36.860
that does some collaborative thing like
run something like Google Wave or have a
00:34:36.860 --> 00:34:42.460
have just an etherpad over a mix network,
you're gonna have the interesting issues
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
00:34:48.400 --> 00:34:53.370
have other impacts on the users. And one
things we're not really thinking about but
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
00:34:59.230 --> 00:35:08.420
people happy with higher latency
applications. And this sounds hard, but
00:35:08.420 --> 00:35:11.670
actually a lot of times, like, you know
when you look at people who are developing
00:35:11.670 --> 00:35:16.440
more modern web frameworks, actually they
are doing you know more of the abstract
00:35:16.440 --> 00:35:23.000
alike something like couch TV is doing;
it's not literally, you know, supporting
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
00:35:27.110 --> 00:35:30.060
we want to do.
D: So, but it wouldn't be fair for us to
00:35:30.060 --> 00:35:35.150
say, like, "hey, use this cool messaging
app - it's unreliable, so I'm gonna send
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
00:35:40.980 --> 00:35:47.230
reliability, and and you and you pay for
that in in retransmission some times and
00:35:47.230 --> 00:35:51.290
and some extra leaked information for
which we need to compensate with more
00:35:51.290 --> 00:35:56.050
decoy traffic. We can actually -- the
Loopix paper explores this trade-off where
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
00:36:00.040 --> 00:36:05.760
decoy traffic. And so that should help.
J: Yeah
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
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
00:36:18.840 --> 00:36:22.660
have lower latency mix networks than say,
10 years ago.
00:36:22.660 --> 00:36:25.300
J: One of the nice things about certainly
the nice things about the stuff that
00:36:25.300 --> 00:36:28.590
David and Yawning have been doing is that
they're they're active really trying to
00:36:28.590 --> 00:36:39.840
make the - the the, sorry, the reliability
measures work in the mixed work in the --
00:36:39.840 --> 00:36:43.320
or just just above the mix network. And
this is really essential if you want to
00:36:43.320 --> 00:36:48.030
build something that application
developers can use because one it is
00:36:48.030 --> 00:36:53.650
actually common in anonymity systems for
the sort of reliability measures to create
00:36:53.650 --> 00:36:59.420
to possibly compromise other things. So
having being able to do the reliability
00:36:59.420 --> 00:37:03.910
stuff in a way that you can still have
your security properties for it is
00:37:03.910 --> 00:37:09.100
important. Okay.
D: Oh yeah, we'd like to say thanks to the
00:37:09.100 --> 00:37:14.240
researchers we've been working with. And I
like to thank Yawning Angel for all the
00:37:14.240 --> 00:37:19.540
good design advice and work on the
specifications. And and for George for his
00:37:19.540 --> 00:37:21.810
advice.
J: George and Claudia are always one
00:37:21.810 --> 00:37:24.910
D: For their excellent paper. Anya for her
Loopix paper.
00:37:24.910 --> 00:37:27.452
J: Christian I've - everything that I've
been working on our talk to Christian
00:37:27.452 --> 00:37:29.550
about all the time
D: Nick Matheson from the Tor project
00:37:29.550 --> 00:37:35.210
helped me out a lot with the with our PKI
specification because, well, I mean he
00:37:35.210 --> 00:37:39.240
wrote the directory authority system for
mix minion, and for tor, and
00:37:39.240 --> 00:37:43.440
J: And also to Trevor Perrin for running
this wonderful mailing list which where we
00:37:43.440 --> 00:37:45.950
get all where we get numbers
of important ideas.
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
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
00:37:58.210 --> 00:38:03.000
of project. Alright, that's it.
00:38:03.000 --> 00:38:12.960
Applause
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
00:38:17.590 --> 00:38:25.470
at the microphones. Do we have questions
from the internet? From the IRC Network?
00:38:25.470 --> 00:38:31.220
No questions from the IRC. There's one
question microphone one
00:38:31.220 --> 00:38:35.720
Mic 1: You mentioned latency will be
higher than tor - should we be thinking
00:38:35.720 --> 00:38:41.450
sort of seconds, minutes,
what's the sort of order of
00:38:41.450 --> 00:38:44.000
J: We don't know
D: Oh yes so the question is, the latency
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
00:38:49.260 --> 00:38:52.990
the mix Network and we're not
J: George has claimed seconds so I don't
00:38:52.990 --> 00:38:55.500
know if I believe him
D: I should start off by saying that mix
00:38:55.500 --> 00:38:59.081
networks aren't trying to be a general-
purpose anonymity system like tor. We're
00:38:59.081 --> 00:39:03.850
trying to make customized networks for
specific applications, and so each
00:39:03.850 --> 00:39:09.480
application has different traffic patterns
in different ways they're used. So the
00:39:09.480 --> 00:39:17.390
latency would would necessarily come after
tuning. Now, some, we have some idea that
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.
00:39:22.700 --> 00:39:27.620
Actually the researchers were working with
are about to publish a new paper about how
00:39:27.620 --> 00:39:36.470
to tune decoy traffic and latency for the
desired entropy you want in each mix,
00:39:36.470 --> 00:39:41.200
yeah.
Herald: Microphone number two, your
00:39:41.200 --> 00:39:45.060
question?
Mic 2: You have mentioned that the in
00:39:45.060 --> 00:39:50.510
mixed networks PKI's have higher
scalability problems than in Tor - why is
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
00:39:54.890 --> 00:39:59.400
route unpredictability, so
J: I mean if you're trying to build a
00:39:59.400 --> 00:40:03.230
replacement for email and you want
everyone in the world to use it, if you
00:40:03.230 --> 00:40:10.060
work through like, a sort of very bullshit
back of the envelope computation -
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
00:40:17.810 --> 00:40:22.610
whatever other anonymity system is only
about 10 million times better than just
00:40:22.610 --> 00:40:27.790
sending every message to everybody.
Something, you know, that's very back of
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
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
00:40:41.600 --> 00:40:44.020
tor can do certain clever
things like there's a,
00:40:44.020 --> 00:40:47.070
there's one of their proposals I think is
actually not taking that seriously at the
00:40:47.070 --> 00:40:52.150
moment is where they published this big
list - they published the PKI or sorry,
00:40:52.150 --> 00:40:57.890
the big the the thing and nodes don't
actually download the whole, the the whole
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
00:41:02.290 --> 00:41:06.170
proof that they were given the correct
that they were forwarded to the correct
00:41:06.170 --> 00:41:10.240
node. So this might this then gives you
another order of magnitude or two on that
00:41:10.240 --> 00:41:16.370
fat on that you know 10 million
I just quoted you.
00:41:16.370 --> 00:41:22.090
Herald: Okay, microphone number three
Mic 3: Hi, this is looks like really good
00:41:22.090 --> 00:41:26.980
work and I'm happy to see it - now my
question is if there are multiple
00:41:26.980 --> 00:41:30.530
applications which have different tuning
requirements, can they share the same
00:41:30.530 --> 00:41:34.160
network and help each others anonymity
set, or do we have to have multiple
00:41:34.160 --> 00:41:38.610
networks?
D: Ah, so we agree it would be best if
00:41:38.610 --> 00:41:43.130
they could help each other by increasing
each other's anonymity set. But we're
00:41:43.130 --> 00:41:48.720
concerned that the specific tuning for the
decoy traffic might prohibit this in some
00:41:48.720 --> 00:41:54.110
cases. For -- actually, and there's some
other considerations as well, so since
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
00:41:59.510 --> 00:42:04.490
have like an email use case, we probably
are gonna get around 50 K average size
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,
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
00:42:15.650 --> 00:42:19.570
in a big 50 K a packet.
J: So, one thing that is clear - if you
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.
00:42:23.320 --> 00:42:26.210
Obviously if you have something that's
gonna be quite infrequent like a payment
00:42:26.210 --> 00:42:32.070
thing, then it needs then you should be
using a network with with much more
00:42:32.070 --> 00:42:36.480
frequent packets and just accept that
you're gonna be you -- accept though the
00:42:36.480 --> 00:42:40.560
inefficiency. D: And there's another
consideration too - it, which is,
00:42:40.560 --> 00:42:45.320
sometimes in these chat applications,
communication partnerships might be
00:42:45.320 --> 00:42:48.510
symmetrical in that we
might send each other roughly the same
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
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
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
00:43:02.490 --> 00:43:08.470
the decoy traffic look like that versus a
symmetrical communication partnership. So
00:43:08.470 --> 00:43:13.140
that's what I meant by some applications
might not be compatible with each other to
00:43:13.140 --> 00:43:17.250
tune this decoy traffic
J: Yeah we certainly would hope that most
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
00:43:21.550 --> 00:43:25.630
etherpad, your other sort of collaborative
applications, your email, your payment
00:43:25.630 --> 00:43:28.611
network - we'd certainly hope that all
that stuff could be bundled onto one thing
00:43:28.611 --> 00:43:33.750
that was sort of optimized for this email-
like use case. And then whether if you
00:43:33.750 --> 00:43:40.570
actually need the instant messaging
network at all is another question.
00:43:40.570 --> 00:43:44.580
Herald: All right, microphone number one
what's your question?
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
00:43:49.280 --> 00:43:54.610
out or like, so like like papers are
great, like is there anything to touch to
00:43:54.610 --> 00:43:57.850
act to, whatever
D: Well well, I mean, actually right now
00:43:57.850 --> 00:44:03.250
we're running a test mix Network on
several machines that we had lying around,
00:44:03.250 --> 00:44:08.240
and it works great - thanks for (meskhi
oh) and (kali) for their help for that.
00:44:08.240 --> 00:44:14.460
But, we don't really have any anything
near production-ready, like
00:44:14.460 --> 00:44:21.300
J: Yeah the stuff I was talking about
doesn't even work.
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.
00:44:27.590 --> 00:44:31.510
Like, I'm not sure how soon, but
J: Depends on funding, depends on other
00:44:31.510 --> 00:44:37.750
things: we're working on it.
Herald: Thank you, microphone two: what is
00:44:37.750 --> 00:44:41.420
your question?
Mic 2: I was thinking about this in the
00:44:41.420 --> 00:44:47.380
real world - you're envisioning an app
where people can communicate, and I worry
00:44:47.380 --> 00:44:54.930
about mobile telephones because; let's
envision two users using this app to
00:44:54.930 --> 00:44:58.950
communicate with each other. The idea
would be that one person sends a message
00:44:58.950 --> 00:45:02.260
and then sometime later this
other person takes their phone out
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
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
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,
00:45:17.190 --> 00:45:22.220
can correlate who picks their phone out of
their pockets every time when, when person
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
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
00:45:29.940 --> 00:45:34.780
thinking about.
J: My, in my ideal; I have no idea. In my
00:45:34.780 --> 00:45:40.480
ideal world the part of the solution to
making the users happier with latency is
00:45:40.480 --> 00:45:45.340
the phone doesn't ding anymore. You don't
get notifications - you check your phone
00:45:45.340 --> 00:45:51.720
when you check your phone.
Mic 2: Sorry, I think that would be an
00:45:51.720 --> 00:45:55.690
important security property as well.
J: But I would actually like it there's a
00:45:55.690 --> 00:45:59.960
question here is: would that make people
actually happier with latency? What can
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
00:46:03.330 --> 00:46:07.530
built to sort of maximize engagement. And
you want to actually, you actually don't
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
00:46:10.670 --> 00:46:19.490
when they want to use it.
Herald: All right, thank you. Seems there
00:46:19.490 --> 00:46:24.480
are no further questions, so thanks a lot
to Jeff, thanks a lot to David
00:46:24.480 --> 00:46:34.655
Applause
00:46:34.655 --> 00:46:39.637
Music
00:46:39.637 --> 00:46:52.000
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!