34C3 - Practical Mix Network Design

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!