Music
Herald: The next talk coming up is going
to be "Practical mix network designs,
strong metadata protection for
asynchronous messaging", held by by David,
who has done research on mix networks and
is a contributor to Tor network, and by
Jeff, who has done contribution to the GNU
network project, organized a couple of
sessions for this on last year's Congress
and is basically a mathematician, trying
to get practical. they're going to talk
about components on mix networks and
defenses that basically Tor can't do. And,
yeah. Welcome with a big round of
applause, okay.
applause
Jeff: Okay, so I'm Jeff, this is David,
we're going to be telling you some, we're
going to be telling you some aspects about
designing mix networks. The, I'm involved
with the I'm an academic involved with the
GNUnet project, he's involved with the
Panoramix project. Okay, so first of all
we, just to be clear, of course encryption
works, you know, if it's, you know,
properly implemented and then, you know,
we have a huge amount of trust in it, we
we even have, you know, sort of slides
showing that the most powerful adversaries
in the world can't can't can't break these
things, so this is fine.
However we have to worry about sort of
about the metadata leakage or and in this
talk we're specifically going to be
worrying about traffic analysis of of
connections. inhales So, yeah, it's time
to, it's time to actually start addressing
these things. Okay. So existing solutions
to traffic analysis. So there's this
wonderful Tor Tor program and project and
they we we know as of five years ago they
consider the the even the NSA considered
considered Tor to be quite effective at
preventing mass location tracking. So this
is, so Tor works for what it's designed to
do, Tor does not protect against an
adversary who can see both ends of the Tor
circuit, so this this is this is a
handicap in a number of situ- in a number
of situation, so the first situation is if
if you have a website that is, if you if
you have a website of course then somebody
can have fingerprinted this website in
advance, have some, you know, description
of its of its traffic profile and they can
and they can tell if you're just from
looking at your connection if you're if
you're accessing that that website over
Tor.
So okay, so let's admit defeat for the web
on the web for now, because we're not
going to, you know, we're not going to be
able to provide that kind of, we're not
going to be able to defeat that kind of
adversary very quickly. But okay, can we
just message our friends over Tor? So
there's a few programs to do this: There's
Ricochet there's Briar; the problem with
using Tor as a messaging as a messaging
transport layer is that frequently, the
people you want to protect, are in the
same country or even on the same ISP, so
the original property of, you know, the
adversary being able to see both sides of
the connection comes comes through again
and they can very quickly be - that
connection between them can very quickly
be seen. So okay, how can we actually keep
our messaging metadata private? And the
answer we're going to say sort of - we're
going to say the right one is a mixed
network.
David: Oh yeah, so mixed networks are
message oriented, as opposed to stream
oriented. They are essentially an
unreliable packet switching network. And
also latency is added at each hop. This is
called a mix strategy; there's a bunch of
different mix strategies. It's kind of an
architectural diagram. Notice there's no
exit nodes, there's no talking to the web
like with Tor, so the security model is
different, we do have a PKI, similar to
Tor, we we can call it like a directory
authority system. So there's a bunch of
differences between Tor and mix nets and
one of the important ones is that we can
actually do decoy traffic everywhere in
this diagram, like we can do decoy traffic
all the way to clients or to the
destination.
J.: Yeah so one of the one of the issues
with Tor is of course you can't do you if
even if you wanted to add decoy traffic
you couldn't hide the - you couldn't
protect against this website
fingerprinting attack necessarily, because
you're going to be or you're still seeing
the connection coming out the other side,
so you're see there's still a lot of
analysis you can do. Okay so one thing,
just some history here, mixed networks are
actually the the oldest anonymity system
as far as far as I know from David Chaum's
1981 paper, then there's a few other tools
that have been proposed; one of them is
private information retrieval, usually
written PIR.
This works in sort of narrow situations,
when you're trying to retrieve something
from some kind of database. The scaling
isn't perfect on it but there's cool
things you can do. But there's another the
other the other one that sort of is
generally proposed is the alternative to
mix networks is dining cryptographers
networks. And the problem with them is
that the bandwidth is really literally,
you know, each you're paying literally for
the quadratic cost per user, so I mean
something like cubic. so the your
anonymity set is is is really going to
wind up being very small and if you're
talking about building something that has
inherently has a small anonymity set then
you have to "ask who are we protecting?"
And, you know, if you're if - you're not
protecting whistleblowers anymore, because
of whistle- if a whistleblower talks to,
you know, journalists and it's unclear
which journalists, you know, Der Spiegel
he's talking to, well he's still some-
he's still the guy with who knew this
thing, who talked to somebody at Der
Spiegel. So and more as it does protect,
you know, it doesn't, you know, it the
person that it does protect is somebody
who already has a lot of power and who
it's gonna be hard to convict anyway be-
so what we want to do, so we really want
to blow up the anonymity set as large as
possible and that's why we like mix
networks.
D.: All right so we're gonna talk about a
few attacks on mix networks and some
defenses. Epistemic attacks are not one of
the attacks we're really going to focus on
because it's it's really a specialized
area of research; there's actually a bunch
a few papers, written on breaking
different public-key infrastructure
systems for like things like point-to-
point networks and other other things like
that.
J.: So, oh, so..
D.: Oh, so, okay, but we can say I guess
we should mention that our PKI generally -
mix literature assumes you have a PKI, it
assumes that the all the clients using it
somehow know about the whole network.
J.: So
D.: Yeah, g...
J.: So so usually when P - anonymity
researchers talk about a PKI, they
generally assume something like the Tor
directory authority system, where you have
some people, who can be very trusted, who
run the thing. This actually presents a
scalability problem- it's what's goin- it's
what's the cuts(?) and post-project(?) and
and ever- and Panoramix is doing; it does
present a scalability problem, more
serious than the one for Tor. The there
are other ideas you can do, there's there,
so on the try, on the idea
of sort of making it more secure beyond
just these people, there's projects like
(???)thority and things and on the - but
on trying to make it more scalable,
there's other things, like we have we have
some people in the GNUnet project that are
researching this. In past generally these
peer-to-peer networking projects to try
and come up with, you know, distributed
PKI, had very serious attacks against
them; these epistemic and especially these
epistemic attack types things, so and
you're not gonna completely fix those, so
the way that you would have a distributed
PKI is you would have to prove that you
really know how bad the attack is and then
argue that this is better than some nine
people or whatever possibly being
compromised. But we don't want to talk too
much about this, because this is not our
area of work but we just want to mention
it's intr- it's a lot of interesting stuff
there and right now - so since we were
leading from the epistemic attacks David's
gonna tell you about sort of, since this
is sort of the sca- well, I'm sorry, he's
gonna tell you about how the scalability
comes in.
D.: Yeah, so Tor, oh, so, sorry, mix nets
can use cascade topologies where everyone
uses the same route and this is quite a
different than tor where route
unpredictability is used to achieve some
of it's anonymity properties. So in mixed
nets you can use the same route as
everybody but this is a scalability
problem. So we have other things like free
route and also stratified topology but
free route actually has slightly worse
anonymity. Claudia Diaz has got an
excellent paper and about this.
J.: Another kind of point about free route
is that in practice, like the Tor network,
you visualize it as a free network and it
grew away from that. Nodes are authorized
to be in specific positions and things
like this. So it may be that free routes
aren't just... you wouldn't land there
anyway even if you tried
D.: oh yeah. exit versus guard flags for
tor. This is another diagram of the... any
layer, any mixin layer 0 can connect to
any mix in layer 1 and and send a mix
packet. So this comes from the loop picks
design, we're gonna be mentioning some
more designed from loop picks. The cool
thing about this is, it's fairly easy to
calculate the entropy of each mix compared
to say free route, which is pretty
complicated. This also scales pretty well,
we can add mixes to each layer if we need
to scale up for more traffic and more
users.
D.: So we're gonna mention a couple,
sometimes we'll put some citations on the
slide. Don't take them.. they're not too
critical, but the one on this one... yeah,
Claudia Diaz has a very nice paper for
understanding the different ideologies.
J.: And I believe Roger has a paper on
this topic as well.
D.: Ok, so why isn't this tor? Well, the
main thing that we can say is that tor
doesn't actually mix. if the packets
are... The packets coming in at a
particular point in time are basically the
same packets going out. You pretty much
know within a very small number. So what a
mixed strategy actually does. This is an
algorithm that's part of the software to
do the thing. What a mixed strategy
actually does is it adds latency to reduce
the correlation between packets.
And there's yeah ...
J.: So David Chum in 1981 with this first
mix net paper describe this threshold mix.
So say this mix had a threshold of four.
It would accumulate four input messages
like this. And when it had enough for its
threshold, then it would shuffle them and
send them out. Mixes are also unwrapping a
layer of encryption for each of these
hops. So if I was an attacker and I wanted
to break this, what I could do is wait
until the mix is empty, or I could make
that mix empty by sending my own messages
into it. And then when a target message
enters this mix I could send my own
messages and cause it to achieve its
threshold and shuffle and send all the
messages out. So then I would recognize
all the cipher texts of my own messages
and the one message
I don't recognize it's the
target message. You can keep doing this
for each hop and this is called a
n-minus-1 attack or blending attack.
There's a lot of variations on them. We
have continuous-time mixes like the stop-
and-go mix and the poisson-mixed
strategies. These mixed strategies allow
the client to select the delays for each
hop. Usually they're from an exponential
distribution. If an attacker wants to
break this using a blending attack, first
they need to empty the mix queue by
blocking all input messages from the mix
and waiting some period of time where it's
highly probable that the mix queue would
then be empty. Then they would allow their
one target message to enter the mix and
continue to block other input messages and
then simply wait for that message to be
outputted. Now these attacks we have some
defense for them, like say a heartbeat
protocol from, George wrote a paper about
ten years ago, George Danezis. It's also
in the Loopix paper as well, it's
mentioned. So we would have mixes with a
kind of decoy traffic, we refer to him as
mixed loops or heartbeat traffic, where a
mix is sending itself a message. It's like
a self-addressed stamped envelope. It's
going through the mix network and coming
back. And if it doesn't receive its
heartbeat in some time out, it knows it
could be under attack or of course there
could be other problems in the network as
well. So you would want to maybe correlate
a attack with several failures to receive
a heartbeat message.
There's other defenses for blending
attacks as well. There was a recent paper
published, but we're not going to talk
about that right now. The next category of
attack is statistical disclosure attacks.
This is essentially, I like to think of it
as the adversary is abstracting the entire
mix network as if it's one mix. They're
looking at messages go in and messages
come out. A lot of this literature is
written from the perspective of like
point-to-point networks. Like when Alice
and Bob were receiving messages from the
mixed network they're receiving it at
their home IP addresses, as if we had
publicly routable IP addresses and no NAT
devices to get in the way. Maybe a more
modern sort of architecture might involve
queuing messages. This is a concept used
in Loopix design as well.
Loopix has got a bunch of different decoy
traffic types in order to add noise to the
signal at various locations in the
network. So there's drop decoy traffic,
where a client would select a random
destination provider to send a message to.
So it traverses the mix net and then gets
dropped by the provider. And there's also
client loops, and actually I should
mention, if we're doing these kind of
statistical disclosure attacks, a lot of
this stuff we don't know how well it will
work in the real world. Because, it really
depends on a specific application and the
adversaries ability to predict users
behavior and that behavior should be
repetitive. I mean this depends on how
much information is leaked by the system.
But mix networks always leak information,
so it's it's about measuring the leakage
and understanding if the user behavior is
dynamic enough.
These attacks cannot always converge on
success. So it depends on the particular
system and how it's tuned. In this
particular case for queuing messages in
this style mixed network the adversary
would have to compromise the destination
providers. So previously here in this
situation it would be, in this point-to-
point network situation where people are
actually receiving messages from the mixed
network to their mailbox directly or to
their home IP, the adversary is a passive
adversary. In the more modern architecture
where messages are queued, I mean it's not
more modern, but it's the Loopix design
which is a recent paper, so this attack
becomes an active attack. And there's some
padding to the clients so we have some
amount of receiver unobservability, so
clients received the same amount of
information when they received messages.
D.: So okay, so there's a question that's
natural. So we've talked about adding
latency and we are also talking about
adding cover traffic. So you might ask "Is
this enough?" and "Could I get away with
less?". And the answer to "Could I get
away with less?" seems to be no. At least
by some artificial measures your anonymity
can't really scale better than the cover
traffic times the latency. So one takeaway
from this is in the Tor, in what is Tor's
situation, so I mean Roger always tells
people that they don't know, if adding
cover traffic to Tor would help. And one
sort of extreme version of this is of
course, whatever cover traffic you add
times something very small is still
something rather relatively small. Now
you'll notice here of course the anonymity
still looks quadratic in something but
it's still longer in the number of users.
So what we're talking about is paying some
sort of fixed upfront cost. It may be
somewhat large, part of it is in terms of
the users experience with the latency and
part of it is in terms of the actual sort
of cost of their you know of their network
connection, but you know, it's doable. So
one thing, so sometimes people have made
these just to sort of wrap up this section
about topologies and whatever and
strategies and things, so people have made
these sort of quasi religious statements
about encryption from time to time. To
sort of boil that down to something
concrete encryption is basically free in
general and but for the mixed network
we're going to have to actually pay some
kind of real costs.
Okay, so one thing about mix networks, you
don't want to roll your own packet format.
There's this wonderful, first to know a
very reasonable one, it's sort of the one
that has stopped much of the development
in this area, is Sphinx. It's quite
compact, and it has a very nice security
proof, it's by George Danezis and Ian
Goldberg. So just to comment on the name,
so the packet format has a header and a
body and at the time that it was
developed, so the body has to be encrypted
with what's called a wide block cipher. At
the time that was developed the only wide
block cipher the people were thinking
about was lioness. There's now some other
wide block ciphers like AEZ by Rogaway and
supposedly DJB has one on the way. So I'm
gonna say a little few things about the
packet format. So the header has three
parts, but one of them, the first part is
a public key this elliptic curve point,
and then there's this body, which is
encrypted with a wide box cipher. So the
way you think about this mix node n
operating is, Alice, you know there's this
key exchange between the mix node and
Alice, that Alice first does it. She
thinks up this is key for her packet and
does the exchange and then the mix node
computes the other side of the Diffie-
Hellman. From that the mix node extracts
the next hop and he has to mutate all of
the different things. So what Sphinx is,
is the rules for how to mutate those. Okay
so let's say one thing, that's kind of
important is: "Why are we using...", you
know "Why is this Delta...". I didn't make
a comment on this too much, but the header
part was MACed and Delta was not. So why
do we not put a MAC on Delta?
This seems very very dangerous. Of course
if you know, if we had, if we were just
using an unMACed stream cipher than some
adversary who controls a mix node next to
the sender and someplace where the message
is going, could just XOR an arbitrary
message into the packet and then check for
it when it arrives. But we don't use a
stream cipher, we use a wide block cipher.
So what this means is, an attacker doing
the same sort of thing will get at most a
one bit tagging attack. Okay, that's still
an attack. Why would we tolerate even a
one bit tagging attack? And the answer is
that anonymous receivers really matter. So
there's a few things, so of course a
journalistic source, some sort of
whistleblower or whatever, but also any
kind of service, like if you want to talk
to some crypto currency network, or you
want to talk to or download some file, or
anything like this, anything where you
interact with a service or you need some
kind of acknowledgment back of it. And in
fact even just the basic protocol acts for
a messaging system need some sort of
reply. Okay, so what is this? So how do we
do anonymous receivers? We create what's
called a single-use reply block, so that's
a first node where it goes to, expiration
date, and then the header and one
cryptographic key for one layer of it. And
so the recipient makes up this SURB and
supplies it to the sender at some point in
the past. the sender attaches their Delta
and they can send to the recipient.
Okay so great, now okay, now let's get
into something tricky. We have these
common... Okay we might worry, so if you
looked at the key exchange that I did,
Alice the sender just made up her alpha on
the spot. So her key is ephemeral but the
mix node he wasn't. It was supplied by
this PKI. So that means, so we want our
protocols to be forward secure and you
know TOR is forward secure. It doesn't
negotiate, live negotiation with the top
which is great. But we need some kind of
forward security and we don't have it, a
priori. So what we have to do is well
first of all a mixed net, we need some
kind of replay attack protection anyway.
So what this requires, some sort of data
structure that will eventually fill up or
overflow or something like this. So to
prevent that we have to do key rotation
anyway. So one option is to just rotate
the mix node keys faster. The problem with
that is that you don't want to stress the
PKI too much. Because the PKI is already a
scaling pain. So, okay. But another
problem with that is that these SURB
lifetimes are equal to the node key life,
they can't exceed the node key lifetimes.
So that means that we, if we want to be
able to have our forward, have our key
compromise window smaller than the node
key lifetimes or then we have to do, or -
you know smaller than the server lifetimes
- and we have to do something else. So
there's a couple ideas. So George, back in
two thousand th- so, okay the idea is;
Okay, maybe we can be like, a little like
Tor and use more packets per for the
packet we want to send but not do it in
the way Tor does it. So George proposed
using two packets in different key epochs.
That's pretty good, that that gives you,
that gives you a lot of nice properties.
So there's another thing you can do that
I'm sort of, that I've been working on,
which is you can you can use a loop to the
mix, to a mix node to actually do a key
exchange and then on the mix node you can
you can use a double ratchet construction
for some hops. And that the this, problem
with this is it's cheating, these two
these two things. and you wouldn't want to
do them at all hops, because they create
some correlations between packets. So,
okay, so we can so we can, in general we
can ask what is what do we want the key
exchange that our mix node - what do we
want, how do we make this mix node forward
secure, so I don't want to say too much
about this but in general we can talk
about the different stra- different sort
of basic technologies for key exchanges
and the properties we can get out of them
in the context of Sphinx.
And, you know, anything that's based on
elliptic curves is not going to be post
quantum, so if we want something based on,
you know, if we want that then we need to
something else so there was a blinding
operations in Sphinx I didn't tell you
about, doing that in the post quantum
context is tricky. Probably it works for
SIDH. We don't know if it works for LWE.
We certainly have no idea how to do it
efficiently, maybe it can be done. Our
cheating strategy gives us nice key
erasure properties, it gives us post
quantum, if the loop if the loop did a
post quantum key exchange and there's
another nice property that it gives, that
you can't really get any other way, which
is that it the the blinding thing is
hybrid - you can actually have a hybrid
post quantum property, and that means that
you can use both an elliptic curve and
this post quantum key exchange and if
either one of them is good then you can't
break then you can't break it. If you try
and do this construction with something
like LWE you're probably not going to be
able to get that hybrid post quantum
property, 'cause the blinding operation
itself will depend on the LWE
cryptographic assumptions.
So nevertheless I want to conjecture that
LWE (?????????) LWE means "learning with
errors", may be the eventual sort of post
quantum key exchange we want to use and so
mathematicians love conjectures, so I
don't think there's one with blinding but
I think we can probably come up with
something that eventually, where we have
some kind of nice blinding for the an LWE
scheme and it even has puncturing.
Punctured encryption is something that you
can currently do with pairing based crypto
and it's excruciatingly slow but I think
it could, I suspect it could be done much
faster with LWE. Okay
D.: Okay, so mix networks: they're
unreliable, they're packet switching, so
in that case some classical Network
literature can can be applied. Now an
automatic repeat request protocol scheme
is one of those protocol schemes that has
protocol acknowledgments and retransmits
and we can do this over mix networks but
it leaks extra information. Every ACK you
send could potentially be used as in a
correlation attack, for instance if the
adversary causes the ACK packet to be
dropped. And in a stopping way ARQ(?) the
simplest variety of these protocols, would
leak the least amount of information, so
that's what we're using and we have three
cryptographic layers in our stack right
now in this Loopix Katzenpost project
we're working on. Yawning(?) angel wrote a
cryptographic link layer based on the
noise cryptographic framework. He's mixing
new hope simple(?) with x25509 and the key
exchange and we also have a Sphinx
cryptographic layer. Sphinx is what Jeff
talked about earlier, the cryptographic
packet format and we also have an end-to-
end cryptographic messaging. And this is
another sort of Loopix style diagram:
Alice sends message to Bob's provider, so
it goes through the mix network to Bob and
Bob can retrieve his message later and
with some relatively simple changes from
this Loopix design, we can, to have
stronger location hiding properties, where
Alice and Bob don't talk directly to the
provider that they're retrieving messages
from. They can send single-use reply
blocks to retrieve messages this would
increase latency.
J.: So one thing that's nice there's a
comment to make here, is that a lot of
time certain schemes in academia tend to
use, want to use PIR for this retrieving,
the the thing I thought from your from
your provider and then the - one of the
problems with using a PIR scheme here is
that you're gonna have very different very
different sort of assumptions at play
there and the way even what you model it
is going to be necessary necessarily quite
complex. It's probably fun if you're a
graduate student, you know, doing, playing
with all this stuff but it's actually
giving all of everything to match up will
be complicated. So this is why, so in the
scheme they were talking about here you
actually, you're your mix net is giving
you your location hiding property so you
can you can extract some similar things.
D.: Well, right and also, whereas in this
situation, with a Loopix design it doesn't
have strong location hiding properties, in
particular if Alice really wanted to
figure figure out where Bob is she would
hack his provider and then stake it out
until his IP address showed up again or so
-
J.: One problem with this, with these
provider models, is that, like David just
said, you can get your provider hacked and
there's a way to fix that. It requires
modifying Sphinx a bit, I said, I know
that we just said don't roll your own
packet format but it's a good idea to go
through the security proof again anyway
and it's a small change. But, so, the idea
is that we have, in this middle, this
harddrive picture, is is some sort of of
mailbox server or cumulation thing, that
the receiver here can move whenever he
wants without telling his contacts. And
his contacts actually reach him in other
ways; either he gives them SURBs or he
sub- puts the SURBs at this thing called a
crossover point, which I didn't want to
tell you too much about. So, but the the
idea is that this guy can, our receiver
can supply the - he can send some SURBs to
this point in the middle and then the
pack- and when he goes online - and then
it will send him messages, so the you can
have this ver- this decoupling and one of
the nice things - so at the end of the day
what the proof, what's your like security
result for the mix net's going to be, is
like, okay well, in three months - you
know they're not going to be able to
deanonymise you in three months. So we may
be able to do a bit more if we can move
this guy in the middle periodically.
Okay, so but this is work, very much work
in progress, it's not at all in the cuts
and post thing and it requires modifying
Sphinx and doing doing some redoing a
number of proofs. So, okay, we've been
talking about applications with the idea
being messaging. There's other
applications and - where you're still
sending messages but to give you a bit
more, something a bit more concrete:
There's a there's a few schemes for doing
anonymous money, well right now there's a
lot of schemes for doing anonymous money
and mostly they suck but there's a few
that are actually quite good and have
extremely strong cryptographic assurances
on their anonymity: Zcash you basically
would have to invert a hash function or
something to break it, I'm not completely
sure, Taler, well in in the RSA blind
signatures have information theoretically
secure blinding, which means they are
absolutely unbreakable.
There's a point in Taler where it's weaker
than that, but another thing you might ask
is, you know, can we do anything web-like.
Well, there's a project that wants to like
package up web pages and ship them over
free nets, so you could use it to ship
things over a mix network. But,
fundamentally, if you imagine what we want
to do is like build build some application
that does some collaborative thing like
run something like Google Wave or have a
have just an etherpad over a mix network,
you're gonna have the interesting issues
that pop up with like the merges and other
thing and, and anyway the latency is gonna
have other impacts on the users. And one
things we're not really thinking about but
we would really like other people to think
about is sort of how to make how to make
people happy with higher latency
applications. And this sounds hard, but
actually a lot of times, like, you know
when you look at people who are developing
more modern web frameworks, actually they
are doing you know more of the abstract
alike something like couch TV is doing;
it's not literally, you know, supporting
latency, but it's it's decoupling things
in a way that it is quite relevant to what
we want to do.
D: So, but it wouldn't be fair for us to
say, like, "hey, use this cool messaging
app - it's unreliable, so I'm gonna send
you a message, but you might not get it."
So we want to definitely build in some
reliability, and and you and you pay for
that in in retransmission some times and
and some extra leaked information for
which we need to compensate with more
decoy traffic. We can actually -- the
Loopix paper explores this trade-off where
you can make the latency lower in a mixed
network if you are willing to send more
decoy traffic. And so that should help.
J: Yeah
D: It's it would still it still doesn't
make mix networks, I don't think as low
latency as tor or even close. But this is
a matter of tuning, and we can at least
have lower latency mix networks than say,
10 years ago.
J: One of the nice things about certainly
the nice things about the stuff that
David and Yawning have been doing is that
they're they're active really trying to
make the - the the, sorry, the reliability
measures work in the mixed work in the --
or just just above the mix network. And
this is really essential if you want to
build something that application
developers can use because one it is
actually common in anonymity systems for
the sort of reliability measures to create
to possibly compromise other things. So
having being able to do the reliability
stuff in a way that you can still have
your security properties for it is
important. Okay.
D: Oh yeah, we'd like to say thanks to the
researchers we've been working with. And I
like to thank Yawning Angel for all the
good design advice and work on the
specifications. And and for George for his
advice.
J: George and Claudia are always one
D: For their excellent paper. Anya for her
Loopix paper.
J: Christian I've - everything that I've
been working on our talk to Christian
about all the time
D: Nick Matheson from the Tor project
helped me out a lot with the with our PKI
specification because, well, I mean he
wrote the directory authority system for
mix minion, and for tor, and
J: And also to Trevor Perrin for running
this wonderful mailing list which where we
get all where we get numbers
of important ideas.
D: Ah yeah and Trevor also helped with our
PKI sense so that was really great; with
our wire protocol using noise, I mean.
Anyway and that's that's the this new sort
of project. Alright, that's it.
Applause
Herald: Thank you so much, if you have any
questions here in the room, please line up
at the microphones. Do we have questions
from the internet? From the IRC Network?
No questions from the IRC. There's one
question microphone one
Mic 1: You mentioned latency will be
higher than tor - should we be thinking
sort of seconds, minutes,
what's the sort of order of
J: We don't know
D: Oh yes so the question is, the latency
will be higher than tor, how how high will
it be? We don't really know until we tune
the mix Network and we're not
J: George has claimed seconds so I don't
know if I believe him
D: I should start off by saying that mix
networks aren't trying to be a general-
purpose anonymity system like tor. We're
trying to make customized networks for
specific applications, and so each
application has different traffic patterns
in different ways they're used. So the
latency would would necessarily come after
tuning. Now, some, we have some idea that
maybe a few minutes, let's say. But it;
really I can't answer the question yet.
Actually the researchers were working with
are about to publish a new paper about how
to tune decoy traffic and latency for the
desired entropy you want in each mix,
yeah.
Herald: Microphone number two, your
question?
Mic 2: You have mentioned that the in
mixed networks PKI's have higher
scalability problems than in Tor - why is
that? It looks like the mix Network will
have less nodes because the you don't need
route unpredictability, so
J: I mean if you're trying to build a
replacement for email and you want
everyone in the world to use it, if you
work through like, a sort of very bullshit
back of the envelope computation -
there's an argument that your that if you
have a central that a centralized PKI plus
whatever other anonymity system is only
about 10 million times better than just
sending every message to everybody.
Something, you know, that's very back of
the envelope you can try and work. So you
need; yeah well okay so there's that, and
and the the specific seeing when I said
it's less of a problem for tor, is that
tor can do certain clever
things like there's a,
there's one of their proposals I think is
actually not taking that seriously at the
moment is where they published this big
list - they published the PKI or sorry,
the big the the thing and nodes don't
actually download the whole, the the whole
consensus at all. They just point to a
place in the consensus and they get back a
proof that they were given the correct
that they were forwarded to the correct
node. So this might this then gives you
another order of magnitude or two on that
fat on that you know 10 million
I just quoted you.
Herald: Okay, microphone number three
Mic 3: Hi, this is looks like really good
work and I'm happy to see it - now my
question is if there are multiple
applications which have different tuning
requirements, can they share the same
network and help each others anonymity
set, or do we have to have multiple
networks?
D: Ah, so we agree it would be best if
they could help each other by increasing
each other's anonymity set. But we're
concerned that the specific tuning for the
decoy traffic might prohibit this in some
cases. For -- actually, and there's some
other considerations as well, so since
we're not stream oriented, all the data
has to fit in one packet. And so if we
have like an email use case, we probably
are gonna get around 50 K average size
emails, let's say. And if we want to make
like mix chat or Katzen chat application,
I might send really short messages like,
"yo what's up", and now we're sending that
in a big 50 K a packet.
J: So, one thing that is clear - if you
wouldn't do it for all, think you wouldn't
have a new thing for every application.
Obviously if you have something that's
gonna be quite infrequent like a payment
thing, then it needs then you should be
using a network with with much more
frequent packets and just accept that
you're gonna be you -- accept though the
inefficiency. D: And there's another
consideration too - it, which is,
sometimes in these chat applications,
communication partnerships might be
symmetrical in that we
might send each other roughly the same
amount of data. And and stuff that, like
not that I don't think mix Nets are good
for web browsing, but in stuff like the
web it's more like "get to page" and then
you get a bunch of information back. So
there's a lot of different; so what would
the decoy traffic look like that versus a
symmetrical communication partnership. So
that's what I meant by some applications
might not be compatible with each other to
tune this decoy traffic
J: Yeah we certainly would hope that most
sort of like peer-to-peer, that, you know
most sort of peer-to-peer like all of your
etherpad, your other sort of collaborative
applications, your email, your payment
network - we'd certainly hope that all
that stuff could be bundled onto one thing
that was sort of optimized for this email-
like use case. And then whether if you
actually need the instant messaging
network at all is another question.
Herald: All right, microphone number one
what's your question?
Mic 1: Um, can you give well can you give
more concrete examples of software to try
out or like, so like like papers are
great, like is there anything to touch to
act to, whatever
D: Well well, I mean, actually right now
we're running a test mix Network on
several machines that we had lying around,
and it works great - thanks for (meskhi
oh) and (kali) for their help for that.
But, we don't really have any anything
near production-ready, like
J: Yeah the stuff I was talking about
doesn't even work.
D: So the answer to question is: no, we
got nothing. But but we hope we hope soon.
Like, I'm not sure how soon, but
J: Depends on funding, depends on other
things: we're working on it.
Herald: Thank you, microphone two: what is
your question?
Mic 2: I was thinking about this in the
real world - you're envisioning an app
where people can communicate, and I worry
about mobile telephones because; let's
envision two users using this app to
communicate with each other. The idea
would be that one person sends a message
and then sometime later this
other person takes their phone out
of their pocket. There is so much going
on when a phone comes out of a pocket and
as the screen is turned on. WhatsApp is
talked to; there's so much that that you
can look at outside of this whole mix
Network that if you, over a month of time,
can correlate who picks their phone out of
their pockets every time when, when person
sends a message. So can't you correlate
that way and isn't that a huge problem
that, that sort of is completely outside
of the world of the of the problems you're
thinking about.
J: My, in my ideal; I have no idea. In my
ideal world the part of the solution to
making the users happier with latency is
the phone doesn't ding anymore. You don't
get notifications - you check your phone
when you check your phone.
Mic 2: Sorry, I think that would be an
important security property as well.
J: But I would actually like it there's a
question here is: would that make people
actually happier with latency? What can
you, I mean, you you know all of these
things that are being built now are being
built to sort of maximize engagement. And
you want to actually, you actually don't
want to do that anymore. You want people
to only use it when they want to you know
when they want to use it.
Herald: All right, thank you. Seems there
are no further questions, so thanks a lot
to Jeff, thanks a lot to David
Applause
Music
subtitles created by c3subtitles.de
in the year 2018. Join, and help us!