*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*