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!