1 00:00:00,000 --> 00:00:16,300 *Music* Herald: The next talk coming up is going 2 00:00:16,300 --> 00:00:20,770 to be "Practical mix network designs, strong metadata protection for 3 00:00:20,770 --> 00:00:28,990 asynchronous messaging", held by by David, who has done research on mix networks and 4 00:00:28,990 --> 00:00:35,530 is a contributor to Tor network, and by Jeff, who has done contribution to the GNU 5 00:00:35,530 --> 00:00:40,420 network project, organized a couple of sessions for this on last year's Congress 6 00:00:40,420 --> 00:00:46,280 and is basically a mathematician, trying to get practical. they're going to talk 7 00:00:46,280 --> 00:00:54,879 about components on mix networks and defenses that basically Tor can't do. And, 8 00:00:54,879 --> 00:01:03,010 yeah. Welcome with a big round of applause, okay. 9 00:01:03,010 --> 00:01:12,229 *applause* Jeff: Okay, so I'm Jeff, this is David, 10 00:01:12,229 --> 00:01:16,549 we're going to be telling you some, we're going to be telling you some aspects about 11 00:01:16,549 --> 00:01:22,520 designing mix networks. The, I'm involved with the I'm an academic involved with the 12 00:01:22,520 --> 00:01:30,820 GNUnet project, he's involved with the Panoramix project. Okay, so first of all 13 00:01:30,820 --> 00:01:37,820 we, just to be clear, of course encryption works, you know, if it's, you know, 14 00:01:37,820 --> 00:01:42,270 properly implemented and then, you know, we have a huge amount of trust in it, we 15 00:01:42,270 --> 00:01:46,490 we even have, you know, sort of slides showing that the most powerful adversaries 16 00:01:46,490 --> 00:01:51,240 in the world can't can't can't break these things, so this is fine. 17 00:01:51,240 --> 00:01:57,100 However we have to worry about sort of about the metadata leakage or and in this 18 00:01:57,100 --> 00:02:01,370 talk we're specifically going to be worrying about traffic analysis of of 19 00:02:01,370 --> 00:02:08,650 connections. *inhales* So, yeah, it's time to, it's time to actually start addressing 20 00:02:08,650 --> 00:02:14,610 these things. Okay. So existing solutions to traffic analysis. So there's this 21 00:02:14,610 --> 00:02:22,420 wonderful Tor Tor program and project and they we we know as of five years ago they 22 00:02:22,420 --> 00:02:29,030 consider the the even the NSA considered considered Tor to be quite effective at 23 00:02:29,030 --> 00:02:35,510 preventing mass location tracking. So this is, so Tor works for what it's designed to 24 00:02:35,510 --> 00:02:44,840 do, Tor does not protect against an adversary who can see both ends of the Tor 25 00:02:44,840 --> 00:02:51,800 circuit, so this this is this is a handicap in a number of situ- in a number 26 00:02:51,800 --> 00:02:59,400 of situation, so the first situation is if if you have a website that is, if you if 27 00:02:59,400 --> 00:03:04,630 you have a website of course then somebody can have fingerprinted this website in 28 00:03:04,630 --> 00:03:10,720 advance, have some, you know, description of its of its traffic profile and they can 29 00:03:10,720 --> 00:03:15,080 and they can tell if you're just from looking at your connection if you're if 30 00:03:15,080 --> 00:03:18,390 you're accessing that that website over Tor. 31 00:03:18,390 --> 00:03:22,630 So okay, so let's admit defeat for the web on the web for now, because we're not 32 00:03:22,630 --> 00:03:28,570 going to, you know, we're not going to be able to provide that kind of, we're not 33 00:03:28,570 --> 00:03:33,510 going to be able to defeat that kind of adversary very quickly. But okay, can we 34 00:03:33,510 --> 00:03:36,990 just message our friends over Tor? So there's a few programs to do this: There's 35 00:03:36,990 --> 00:03:42,690 Ricochet there's Briar; the problem with using Tor as a messaging as a messaging 36 00:03:42,690 --> 00:03:48,890 transport layer is that frequently, the people you want to protect, are in the 37 00:03:48,890 --> 00:03:54,540 same country or even on the same ISP, so the original property of, you know, the 38 00:03:54,540 --> 00:03:57,670 adversary being able to see both sides of the connection comes comes through again 39 00:03:57,670 --> 00:04:01,270 and they can very quickly be - that connection between them can very quickly 40 00:04:01,270 --> 00:04:07,630 be seen. So okay, how can we actually keep our messaging metadata private? And the 41 00:04:07,630 --> 00:04:11,610 answer we're going to say sort of - we're going to say the right one is a mixed 42 00:04:11,610 --> 00:04:13,850 network. David: Oh yeah, so mixed networks are 43 00:04:13,850 --> 00:04:18,810 message oriented, as opposed to stream oriented. They are essentially an 44 00:04:18,810 --> 00:04:27,340 unreliable packet switching network. And also latency is added at each hop. This is 45 00:04:27,340 --> 00:04:35,060 called a mix strategy; there's a bunch of different mix strategies. It's kind of an 46 00:04:35,060 --> 00:04:40,660 architectural diagram. Notice there's no exit nodes, there's no talking to the web 47 00:04:40,660 --> 00:04:47,910 like with Tor, so the security model is different, we do have a PKI, similar to 48 00:04:47,910 --> 00:04:57,150 Tor, we we can call it like a directory authority system. So there's a bunch of 49 00:04:57,150 --> 00:05:04,480 differences between Tor and mix nets and one of the important ones is that we can 50 00:05:04,480 --> 00:05:09,450 actually do decoy traffic everywhere in this diagram, like we can do decoy traffic 51 00:05:09,450 --> 00:05:13,280 all the way to clients or to the destination. 52 00:05:13,280 --> 00:05:20,810 J.: Yeah so one of the one of the issues with Tor is of course you can't do you if 53 00:05:20,810 --> 00:05:26,570 even if you wanted to add decoy traffic you couldn't hide the - you couldn't 54 00:05:26,570 --> 00:05:30,340 protect against this website fingerprinting attack necessarily, because 55 00:05:30,340 --> 00:05:34,610 you're going to be or you're still seeing the connection coming out the other side, 56 00:05:34,610 --> 00:05:39,430 so you're see there's still a lot of analysis you can do. Okay so one thing, 57 00:05:39,430 --> 00:05:43,490 just some history here, mixed networks are actually the the oldest anonymity system 58 00:05:43,490 --> 00:05:50,370 as far as far as I know from David Chaum's 1981 paper, then there's a few other tools 59 00:05:50,370 --> 00:05:54,750 that have been proposed; one of them is private information retrieval, usually 60 00:05:54,750 --> 00:05:57,900 written PIR. This works in sort of narrow situations, 61 00:05:57,900 --> 00:06:02,000 when you're trying to retrieve something from some kind of database. The scaling 62 00:06:02,000 --> 00:06:08,380 isn't perfect on it but there's cool things you can do. But there's another the 63 00:06:08,380 --> 00:06:12,140 other the other one that sort of is generally proposed is the alternative to 64 00:06:12,140 --> 00:06:16,770 mix networks is dining cryptographers networks. And the problem with them is 65 00:06:16,770 --> 00:06:24,560 that the bandwidth is really literally, you know, each you're paying literally for 66 00:06:24,560 --> 00:06:31,150 the quadratic cost per user, so I mean something like cubic. so the your 67 00:06:31,150 --> 00:06:37,770 anonymity set is is is really going to wind up being very small and if you're 68 00:06:37,770 --> 00:06:42,580 talking about building something that has inherently has a small anonymity set then 69 00:06:42,580 --> 00:06:49,389 you have to "ask who are we protecting?" And, you know, if you're if - you're not 70 00:06:49,389 --> 00:06:53,220 protecting whistleblowers anymore, because of whistle- if a whistleblower talks to, 71 00:06:53,220 --> 00:06:56,770 you know, journalists and it's unclear which journalists, you know, Der Spiegel 72 00:06:56,770 --> 00:07:02,630 he's talking to, well he's still some- he's still the guy with who knew this 73 00:07:02,630 --> 00:07:06,530 thing, who talked to somebody at Der Spiegel. So and more as it does protect, 74 00:07:06,530 --> 00:07:11,730 you know, it doesn't, you know, it the person that it does protect is somebody 75 00:07:11,730 --> 00:07:15,620 who already has a lot of power and who it's gonna be hard to convict anyway be- 76 00:07:15,620 --> 00:07:20,639 so what we want to do, so we really want to blow up the anonymity set as large as 77 00:07:20,639 --> 00:07:22,790 possible and that's why we like mix networks. 78 00:07:22,790 --> 00:07:27,060 D.: All right so we're gonna talk about a few attacks on mix networks and some 79 00:07:27,060 --> 00:07:33,180 defenses. Epistemic attacks are not one of the attacks we're really going to focus on 80 00:07:33,180 --> 00:07:37,199 because it's it's really a specialized area of research; there's actually a bunch 81 00:07:37,199 --> 00:07:44,840 a few papers, written on breaking different public-key infrastructure 82 00:07:44,840 --> 00:07:49,680 systems for like things like point-to- point networks and other other things like 83 00:07:49,680 --> 00:07:51,750 that. J.: So, oh, so.. 84 00:07:51,750 --> 00:07:58,960 D.: Oh, so, okay, but we can say I guess we should mention that our PKI generally - 85 00:07:58,960 --> 00:08:06,199 mix literature assumes you have a PKI, it assumes that the all the clients using it 86 00:08:06,199 --> 00:08:08,831 somehow know about the whole network. J.: So 87 00:08:08,831 --> 00:08:13,110 D.: Yeah, g... J.: So so usually when P - anonymity 88 00:08:13,110 --> 00:08:16,210 researchers talk about a PKI, they generally assume something like the Tor 89 00:08:16,210 --> 00:08:19,470 directory authority system, where you have some people, who can be very trusted, who 90 00:08:19,470 --> 00:08:23,080 run the thing. This actually presents a scalability problem- it's what's goin- it's 91 00:08:23,080 --> 00:08:27,639 what's the cuts(?) and post-project(?) and and ever- and Panoramix is doing; it does 92 00:08:27,639 --> 00:08:33,139 present a scalability problem, more serious than the one for Tor. The there 93 00:08:33,139 --> 00:08:38,078 are other ideas you can do, there's there, so on the try, on the idea 94 00:08:38,078 --> 00:08:42,399 of sort of making it more secure beyond just these people, there's projects like 95 00:08:42,399 --> 00:08:46,970 (???)thority and things and on the - but on trying to make it more scalable, 96 00:08:46,970 --> 00:08:50,689 there's other things, like we have we have some people in the GNUnet project that are 97 00:08:50,689 --> 00:08:55,500 researching this. In past generally these peer-to-peer networking projects to try 98 00:08:55,500 --> 00:09:01,290 and come up with, you know, distributed PKI, had very serious attacks against 99 00:09:01,290 --> 00:09:05,369 them; these epistemic and especially these epistemic attack types things, so and 100 00:09:05,369 --> 00:09:09,009 you're not gonna completely fix those, so the way that you would have a distributed 101 00:09:09,009 --> 00:09:14,300 PKI is you would have to prove that you really know how bad the attack is and then 102 00:09:14,300 --> 00:09:19,559 argue that this is better than some nine people or whatever possibly being 103 00:09:19,559 --> 00:09:22,730 compromised. But we don't want to talk too much about this, because this is not our 104 00:09:22,730 --> 00:09:26,240 area of work but we just want to mention it's intr- it's a lot of interesting stuff 105 00:09:26,240 --> 00:09:32,379 there and right now - so since we were leading from the epistemic attacks David's 106 00:09:32,379 --> 00:09:36,180 gonna tell you about sort of, since this is sort of the sca- well, I'm sorry, he's 107 00:09:36,180 --> 00:09:39,620 gonna tell you about how the scalability comes in. 108 00:09:39,620 --> 00:09:46,449 D.: Yeah, so Tor, oh, so, sorry, mix nets can use cascade topologies where everyone 109 00:09:46,449 --> 00:09:52,009 uses the same route and this is quite a different than tor where route 110 00:09:52,009 --> 00:09:58,659 unpredictability is used to achieve some of it's anonymity properties. So in mixed 111 00:09:58,659 --> 00:10:04,209 nets you can use the same route as everybody but this is a scalability 112 00:10:04,209 --> 00:10:12,949 problem. So we have other things like free route and also stratified topology but 113 00:10:12,949 --> 00:10:18,139 free route actually has slightly worse anonymity. Claudia Diaz has got an 114 00:10:18,139 --> 00:10:22,010 excellent paper and about this. J.: Another kind of point about free route 115 00:10:22,010 --> 00:10:26,541 is that in practice, like the Tor network, you visualize it as a free network and it 116 00:10:26,541 --> 00:10:31,509 grew away from that. Nodes are authorized to be in specific positions and things 117 00:10:31,509 --> 00:10:36,339 like this. So it may be that free routes aren't just... you wouldn't land there 118 00:10:36,339 --> 00:10:42,610 anyway even if you tried D.: oh yeah. exit versus guard flags for 119 00:10:42,610 --> 00:10:50,990 tor. This is another diagram of the... any layer, any mixin layer 0 can connect to 120 00:10:50,990 --> 00:10:58,609 any mix in layer 1 and and send a mix packet. So this comes from the loop picks 121 00:10:58,609 --> 00:11:05,320 design, we're gonna be mentioning some more designed from loop picks. The cool 122 00:11:05,320 --> 00:11:10,699 thing about this is, it's fairly easy to calculate the entropy of each mix compared 123 00:11:10,699 --> 00:11:17,420 to say free route, which is pretty complicated. This also scales pretty well, 124 00:11:17,420 --> 00:11:22,319 we can add mixes to each layer if we need to scale up for more traffic and more 125 00:11:22,319 --> 00:11:26,389 users. D.: So we're gonna mention a couple, 126 00:11:26,389 --> 00:11:31,050 sometimes we'll put some citations on the slide. Don't take them.. they're not too 127 00:11:31,050 --> 00:11:35,899 critical, but the one on this one... yeah, Claudia Diaz has a very nice paper for 128 00:11:35,899 --> 00:11:41,029 understanding the different ideologies. J.: And I believe Roger has a paper on 129 00:11:41,029 --> 00:11:46,759 this topic as well. D.: Ok, so why isn't this tor? Well, the 130 00:11:46,759 --> 00:11:50,759 main thing that we can say is that tor doesn't actually mix. if the packets 131 00:11:50,759 --> 00:11:54,390 are... The packets coming in at a particular point in time are basically the 132 00:11:54,390 --> 00:12:01,649 same packets going out. You pretty much know within a very small number. So what a 133 00:12:01,649 --> 00:12:05,649 mixed strategy actually does. This is an algorithm that's part of the software to 134 00:12:05,649 --> 00:12:10,989 do the thing. What a mixed strategy actually does is it adds latency to reduce 135 00:12:10,989 --> 00:12:18,289 the correlation between packets. And there's yeah ... 136 00:12:18,289 --> 00:12:25,959 J.: So David Chum in 1981 with this first mix net paper describe this threshold mix. 137 00:12:25,959 --> 00:12:30,139 So say this mix had a threshold of four. It would accumulate four input messages 138 00:12:30,139 --> 00:12:35,929 like this. And when it had enough for its threshold, then it would shuffle them and 139 00:12:35,929 --> 00:12:40,820 send them out. Mixes are also unwrapping a layer of encryption for each of these 140 00:12:40,820 --> 00:12:49,269 hops. So if I was an attacker and I wanted to break this, what I could do is wait 141 00:12:49,269 --> 00:12:54,110 until the mix is empty, or I could make that mix empty by sending my own messages 142 00:12:54,110 --> 00:12:59,110 into it. And then when a target message enters this mix I could send my own 143 00:12:59,110 --> 00:13:03,999 messages and cause it to achieve its threshold and shuffle and send all the 144 00:13:03,999 --> 00:13:09,110 messages out. So then I would recognize all the cipher texts of my own messages 145 00:13:09,110 --> 00:13:11,360 and the one message I don't recognize it's the 146 00:13:11,360 --> 00:13:15,629 target message. You can keep doing this for each hop and this is called a 147 00:13:15,629 --> 00:13:21,110 n-minus-1 attack or blending attack. There's a lot of variations on them. We 148 00:13:21,110 --> 00:13:26,700 have continuous-time mixes like the stop- and-go mix and the poisson-mixed 149 00:13:26,700 --> 00:13:31,529 strategies. These mixed strategies allow the client to select the delays for each 150 00:13:31,529 --> 00:13:41,139 hop. Usually they're from an exponential distribution. If an attacker wants to 151 00:13:41,139 --> 00:13:47,799 break this using a blending attack, first they need to empty the mix queue by 152 00:13:47,799 --> 00:13:52,389 blocking all input messages from the mix and waiting some period of time where it's 153 00:13:52,389 --> 00:13:57,949 highly probable that the mix queue would then be empty. Then they would allow their 154 00:13:57,949 --> 00:14:03,199 one target message to enter the mix and continue to block other input messages and 155 00:14:03,199 --> 00:14:11,290 then simply wait for that message to be outputted. Now these attacks we have some 156 00:14:11,290 --> 00:14:17,059 defense for them, like say a heartbeat protocol from, George wrote a paper about 157 00:14:17,059 --> 00:14:22,779 ten years ago, George Danezis. It's also in the Loopix paper as well, it's 158 00:14:22,779 --> 00:14:31,600 mentioned. So we would have mixes with a kind of decoy traffic, we refer to him as 159 00:14:31,600 --> 00:14:35,580 mixed loops or heartbeat traffic, where a mix is sending itself a message. It's like 160 00:14:35,580 --> 00:14:38,920 a self-addressed stamped envelope. It's going through the mix network and coming 161 00:14:38,920 --> 00:14:46,299 back. And if it doesn't receive its heartbeat in some time out, it knows it 162 00:14:46,299 --> 00:14:50,040 could be under attack or of course there could be other problems in the network as 163 00:14:50,040 --> 00:14:57,429 well. So you would want to maybe correlate a attack with several failures to receive 164 00:14:57,429 --> 00:15:03,110 a heartbeat message. There's other defenses for blending 165 00:15:03,110 --> 00:15:06,370 attacks as well. There was a recent paper published, but we're not going to talk 166 00:15:06,370 --> 00:15:14,800 about that right now. The next category of attack is statistical disclosure attacks. 167 00:15:14,800 --> 00:15:20,320 This is essentially, I like to think of it as the adversary is abstracting the entire 168 00:15:20,320 --> 00:15:25,760 mix network as if it's one mix. They're looking at messages go in and messages 169 00:15:25,760 --> 00:15:31,559 come out. A lot of this literature is written from the perspective of like 170 00:15:31,559 --> 00:15:36,359 point-to-point networks. Like when Alice and Bob were receiving messages from the 171 00:15:36,359 --> 00:15:40,300 mixed network they're receiving it at their home IP addresses, as if we had 172 00:15:40,300 --> 00:15:45,589 publicly routable IP addresses and no NAT devices to get in the way. Maybe a more 173 00:15:45,589 --> 00:15:52,670 modern sort of architecture might involve queuing messages. This is a concept used 174 00:15:52,670 --> 00:15:58,629 in Loopix design as well. Loopix has got a bunch of different decoy 175 00:15:58,629 --> 00:16:05,819 traffic types in order to add noise to the signal at various locations in the 176 00:16:05,819 --> 00:16:13,980 network. So there's drop decoy traffic, where a client would select a random 177 00:16:13,980 --> 00:16:18,820 destination provider to send a message to. So it traverses the mix net and then gets 178 00:16:18,820 --> 00:16:26,920 dropped by the provider. And there's also client loops, and actually I should 179 00:16:26,920 --> 00:16:32,619 mention, if we're doing these kind of statistical disclosure attacks, a lot of 180 00:16:32,619 --> 00:16:36,980 this stuff we don't know how well it will work in the real world. Because, it really 181 00:16:36,980 --> 00:16:42,490 depends on a specific application and the adversaries ability to predict users 182 00:16:42,490 --> 00:16:47,990 behavior and that behavior should be repetitive. I mean this depends on how 183 00:16:47,990 --> 00:16:53,420 much information is leaked by the system. But mix networks always leak information, 184 00:16:53,420 --> 00:16:59,980 so it's it's about measuring the leakage and understanding if the user behavior is 185 00:16:59,980 --> 00:17:06,859 dynamic enough. These attacks cannot always converge on 186 00:17:06,859 --> 00:17:14,309 success. So it depends on the particular system and how it's tuned. In this 187 00:17:14,309 --> 00:17:20,359 particular case for queuing messages in this style mixed network the adversary 188 00:17:20,359 --> 00:17:27,880 would have to compromise the destination providers. So previously here in this 189 00:17:27,880 --> 00:17:32,210 situation it would be, in this point-to- point network situation where people are 190 00:17:32,210 --> 00:17:37,570 actually receiving messages from the mixed network to their mailbox directly or to 191 00:17:37,570 --> 00:17:44,740 their home IP, the adversary is a passive adversary. In the more modern architecture 192 00:17:44,740 --> 00:17:50,120 where messages are queued, I mean it's not more modern, but it's the Loopix design 193 00:17:50,120 --> 00:17:57,059 which is a recent paper, so this attack becomes an active attack. And there's some 194 00:17:57,059 --> 00:18:01,960 padding to the clients so we have some amount of receiver unobservability, so 195 00:18:01,960 --> 00:18:07,419 clients received the same amount of information when they received messages. 196 00:18:07,419 --> 00:18:10,760 D.: So okay, so there's a question that's natural. So we've talked about adding 197 00:18:10,760 --> 00:18:14,559 latency and we are also talking about adding cover traffic. So you might ask "Is 198 00:18:14,559 --> 00:18:21,880 this enough?" and "Could I get away with less?". And the answer to "Could I get 199 00:18:21,880 --> 00:18:32,820 away with less?" seems to be no. At least by some artificial measures your anonymity 200 00:18:32,820 --> 00:18:39,019 can't really scale better than the cover traffic times the latency. So one takeaway 201 00:18:39,019 --> 00:18:45,669 from this is in the Tor, in what is Tor's situation, so I mean Roger always tells 202 00:18:45,669 --> 00:18:51,539 people that they don't know, if adding cover traffic to Tor would help. And one 203 00:18:51,539 --> 00:18:55,450 sort of extreme version of this is of course, whatever cover traffic you add 204 00:18:55,450 --> 00:19:03,500 times something very small is still something rather relatively small. Now 205 00:19:03,500 --> 00:19:07,039 you'll notice here of course the anonymity still looks quadratic in something but 206 00:19:07,039 --> 00:19:10,909 it's still longer in the number of users. So what we're talking about is paying some 207 00:19:10,909 --> 00:19:15,500 sort of fixed upfront cost. It may be somewhat large, part of it is in terms of 208 00:19:15,500 --> 00:19:19,580 the users experience with the latency and part of it is in terms of the actual sort 209 00:19:19,580 --> 00:19:27,539 of cost of their you know of their network connection, but you know, it's doable. So 210 00:19:27,539 --> 00:19:31,440 one thing, so sometimes people have made these just to sort of wrap up this section 211 00:19:31,440 --> 00:19:36,340 about topologies and whatever and strategies and things, so people have made 212 00:19:36,340 --> 00:19:40,980 these sort of quasi religious statements about encryption from time to time. To 213 00:19:40,980 --> 00:19:45,960 sort of boil that down to something concrete encryption is basically free in 214 00:19:45,960 --> 00:19:50,750 general and but for the mixed network we're going to have to actually pay some 215 00:19:50,750 --> 00:19:56,160 kind of real costs. Okay, so one thing about mix networks, you 216 00:19:56,160 --> 00:20:01,200 don't want to roll your own packet format. There's this wonderful, first to know a 217 00:20:01,200 --> 00:20:05,910 very reasonable one, it's sort of the one that has stopped much of the development 218 00:20:05,910 --> 00:20:11,460 in this area, is Sphinx. It's quite compact, and it has a very nice security 219 00:20:11,460 --> 00:20:16,990 proof, it's by George Danezis and Ian Goldberg. So just to comment on the name, 220 00:20:16,990 --> 00:20:20,769 so the packet format has a header and a body and at the time that it was 221 00:20:20,769 --> 00:20:24,820 developed, so the body has to be encrypted with what's called a wide block cipher. At 222 00:20:24,820 --> 00:20:28,500 the time that was developed the only wide block cipher the people were thinking 223 00:20:28,500 --> 00:20:35,720 about was lioness. There's now some other wide block ciphers like AEZ by Rogaway and 224 00:20:35,720 --> 00:20:42,350 supposedly DJB has one on the way. So I'm gonna say a little few things about the 225 00:20:42,350 --> 00:20:47,370 packet format. So the header has three parts, but one of them, the first part is 226 00:20:47,370 --> 00:20:53,139 a public key this elliptic curve point, and then there's this body, which is 227 00:20:53,139 --> 00:20:57,510 encrypted with a wide box cipher. So the way you think about this mix node n 228 00:20:57,510 --> 00:21:04,840 operating is, Alice, you know there's this key exchange between the mix node and 229 00:21:04,840 --> 00:21:10,710 Alice, that Alice first does it. She thinks up this is key for her packet and 230 00:21:10,710 --> 00:21:16,029 does the exchange and then the mix node computes the other side of the Diffie- 231 00:21:16,029 --> 00:21:21,140 Hellman. From that the mix node extracts the next hop and he has to mutate all of 232 00:21:21,140 --> 00:21:27,981 the different things. So what Sphinx is, is the rules for how to mutate those. Okay 233 00:21:27,981 --> 00:21:32,760 so let's say one thing, that's kind of important is: "Why are we using...", you 234 00:21:32,760 --> 00:21:37,539 know "Why is this Delta...". I didn't make a comment on this too much, but the header 235 00:21:37,539 --> 00:21:42,340 part was MACed and Delta was not. So why do we not put a MAC on Delta? 236 00:21:42,340 --> 00:21:46,309 This seems very very dangerous. Of course if you know, if we had, if we were just 237 00:21:46,309 --> 00:21:52,590 using an unMACed stream cipher than some adversary who controls a mix node next to 238 00:21:52,590 --> 00:21:58,030 the sender and someplace where the message is going, could just XOR an arbitrary 239 00:21:58,030 --> 00:22:05,120 message into the packet and then check for it when it arrives. But we don't use a 240 00:22:05,120 --> 00:22:10,860 stream cipher, we use a wide block cipher. So what this means is, an attacker doing 241 00:22:10,860 --> 00:22:18,460 the same sort of thing will get at most a one bit tagging attack. Okay, that's still 242 00:22:18,460 --> 00:22:24,650 an attack. Why would we tolerate even a one bit tagging attack? And the answer is 243 00:22:24,650 --> 00:22:34,280 that anonymous receivers really matter. So there's a few things, so of course a 244 00:22:34,280 --> 00:22:38,230 journalistic source, some sort of whistleblower or whatever, but also any 245 00:22:38,230 --> 00:22:41,970 kind of service, like if you want to talk to some crypto currency network, or you 246 00:22:41,970 --> 00:22:46,071 want to talk to or download some file, or anything like this, anything where you 247 00:22:46,071 --> 00:22:52,139 interact with a service or you need some kind of acknowledgment back of it. And in 248 00:22:52,139 --> 00:22:59,640 fact even just the basic protocol acts for a messaging system need some sort of 249 00:22:59,640 --> 00:23:05,260 reply. Okay, so what is this? So how do we do anonymous receivers? We create what's 250 00:23:05,260 --> 00:23:12,570 called a single-use reply block, so that's a first node where it goes to, expiration 251 00:23:12,570 --> 00:23:20,919 date, and then the header and one cryptographic key for one layer of it. And 252 00:23:20,919 --> 00:23:28,710 so the recipient makes up this SURB and supplies it to the sender at some point in 253 00:23:28,710 --> 00:23:34,330 the past. the sender attaches their Delta and they can send to the recipient. 254 00:23:34,330 --> 00:23:45,429 Okay so great, now okay, now let's get into something tricky. We have these 255 00:23:45,429 --> 00:23:51,879 common... Okay we might worry, so if you looked at the key exchange that I did, 256 00:23:51,879 --> 00:23:59,480 Alice the sender just made up her alpha on the spot. So her key is ephemeral but the 257 00:23:59,480 --> 00:24:07,289 mix node he wasn't. It was supplied by this PKI. So that means, so we want our 258 00:24:07,289 --> 00:24:10,660 protocols to be forward secure and you know TOR is forward secure. It doesn't 259 00:24:10,660 --> 00:24:16,480 negotiate, live negotiation with the top which is great. But we need some kind of 260 00:24:16,480 --> 00:24:23,509 forward security and we don't have it, a priori. So what we have to do is well 261 00:24:23,509 --> 00:24:30,129 first of all a mixed net, we need some kind of replay attack protection anyway. 262 00:24:30,129 --> 00:24:38,450 So what this requires, some sort of data structure that will eventually fill up or 263 00:24:38,450 --> 00:24:43,569 overflow or something like this. So to prevent that we have to do key rotation 264 00:24:43,569 --> 00:24:47,870 anyway. So one option is to just rotate the mix node keys faster. The problem with 265 00:24:47,870 --> 00:24:52,320 that is that you don't want to stress the PKI too much. Because the PKI is already a 266 00:24:52,320 --> 00:24:58,600 scaling pain. So, okay. But another problem with that is that these SURB 267 00:24:58,600 --> 00:25:04,270 lifetimes are equal to the node key life, they can't exceed the node key lifetimes. 268 00:25:04,270 --> 00:25:09,789 So that means that we, if we want to be able to have our forward, have our key 269 00:25:09,789 --> 00:25:15,090 compromise window smaller than the node key lifetimes or then we have to do, or - 270 00:25:15,090 --> 00:25:19,559 you know smaller than the server lifetimes - and we have to do something else. So 271 00:25:19,559 --> 00:25:25,110 there's a couple ideas. So George, back in two thousand th- so, okay the idea is; 272 00:25:25,110 --> 00:25:29,910 Okay, maybe we can be like, a little like Tor and use more packets per for the 273 00:25:29,910 --> 00:25:35,210 packet we want to send but not do it in the way Tor does it. So George proposed 274 00:25:35,210 --> 00:25:40,710 using two packets in different key epochs. That's pretty good, that that gives you, 275 00:25:40,710 --> 00:25:46,270 that gives you a lot of nice properties. So there's another thing you can do that 276 00:25:46,270 --> 00:25:51,429 I'm sort of, that I've been working on, which is you can you can use a loop to the 277 00:25:51,429 --> 00:25:58,470 mix, to a mix node to actually do a key exchange and then on the mix node you can 278 00:25:58,470 --> 00:26:04,691 you can use a double ratchet construction for some hops. And that the this, problem 279 00:26:04,691 --> 00:26:11,169 with this is it's cheating, these two these two things. and you wouldn't want to 280 00:26:11,169 --> 00:26:17,250 do them at all hops, because they create some correlations between packets. So, 281 00:26:17,250 --> 00:26:23,409 okay, so we can so we can, in general we can ask what is what do we want the key 282 00:26:23,409 --> 00:26:28,559 exchange that our mix node - what do we want, how do we make this mix node forward 283 00:26:28,559 --> 00:26:33,360 secure, so I don't want to say too much about this but in general we can talk 284 00:26:33,360 --> 00:26:39,519 about the different stra- different sort of basic technologies for key exchanges 285 00:26:39,519 --> 00:26:43,960 and the properties we can get out of them in the context of Sphinx. 286 00:26:43,960 --> 00:26:48,139 And, you know, anything that's based on elliptic curves is not going to be post 287 00:26:48,139 --> 00:26:52,809 quantum, so if we want something based on, you know, if we want that then we need to 288 00:26:52,809 --> 00:26:55,950 something else so there was a blinding operations in Sphinx I didn't tell you 289 00:26:55,950 --> 00:27:00,039 about, doing that in the post quantum context is tricky. Probably it works for 290 00:27:00,039 --> 00:27:05,720 SIDH. We don't know if it works for LWE. We certainly have no idea how to do it 291 00:27:05,720 --> 00:27:10,909 efficiently, maybe it can be done. Our cheating strategy gives us nice key 292 00:27:10,909 --> 00:27:16,059 erasure properties, it gives us post quantum, if the loop if the loop did a 293 00:27:16,059 --> 00:27:20,710 post quantum key exchange and there's another nice property that it gives, that 294 00:27:20,710 --> 00:27:24,700 you can't really get any other way, which is that it the the blinding thing is 295 00:27:24,700 --> 00:27:29,809 hybrid - you can actually have a hybrid post quantum property, and that means that 296 00:27:29,809 --> 00:27:33,759 you can use both an elliptic curve and this post quantum key exchange and if 297 00:27:33,759 --> 00:27:39,010 either one of them is good then you can't break then you can't break it. If you try 298 00:27:39,010 --> 00:27:43,570 and do this construction with something like LWE you're probably not going to be 299 00:27:43,570 --> 00:27:47,111 able to get that hybrid post quantum property, 'cause the blinding operation 300 00:27:47,111 --> 00:27:51,080 itself will depend on the LWE cryptographic assumptions. 301 00:27:51,080 --> 00:27:58,240 So nevertheless I want to conjecture that LWE (?????????) LWE means "learning with 302 00:27:58,240 --> 00:28:03,899 errors", may be the eventual sort of post quantum key exchange we want to use and so 303 00:28:03,899 --> 00:28:07,630 mathematicians love conjectures, so I don't think there's one with blinding but 304 00:28:07,630 --> 00:28:14,590 I think we can probably come up with something that eventually, where we have 305 00:28:14,590 --> 00:28:19,750 some kind of nice blinding for the an LWE scheme and it even has puncturing. 306 00:28:19,750 --> 00:28:23,499 Punctured encryption is something that you can currently do with pairing based crypto 307 00:28:23,499 --> 00:28:30,639 and it's excruciatingly slow but I think it could, I suspect it could be done much 308 00:28:30,639 --> 00:28:37,450 faster with LWE. Okay D.: Okay, so mix networks: they're 309 00:28:37,450 --> 00:28:43,770 unreliable, they're packet switching, so in that case some classical Network 310 00:28:43,770 --> 00:28:51,831 literature can can be applied. Now an automatic repeat request protocol scheme 311 00:28:51,831 --> 00:28:56,820 is one of those protocol schemes that has protocol acknowledgments and retransmits 312 00:28:56,820 --> 00:29:01,870 and we can do this over mix networks but it leaks extra information. Every ACK you 313 00:29:01,870 --> 00:29:07,699 send could potentially be used as in a correlation attack, for instance if the 314 00:29:07,699 --> 00:29:12,909 adversary causes the ACK packet to be dropped. And in a stopping way ARQ(?) the 315 00:29:12,909 --> 00:29:18,370 simplest variety of these protocols, would leak the least amount of information, so 316 00:29:18,370 --> 00:29:26,960 that's what we're using and we have three cryptographic layers in our stack right 317 00:29:26,960 --> 00:29:35,210 now in this Loopix Katzenpost project we're working on. Yawning(?) angel wrote a 318 00:29:35,210 --> 00:29:42,029 cryptographic link layer based on the noise cryptographic framework. He's mixing 319 00:29:42,029 --> 00:29:49,509 new hope simple(?) with x25509 and the key exchange and we also have a Sphinx 320 00:29:49,509 --> 00:29:55,900 cryptographic layer. Sphinx is what Jeff talked about earlier, the cryptographic 321 00:29:55,900 --> 00:30:02,249 packet format and we also have an end-to- end cryptographic messaging. And this is 322 00:30:02,249 --> 00:30:08,519 another sort of Loopix style diagram: Alice sends message to Bob's provider, so 323 00:30:08,519 --> 00:30:14,870 it goes through the mix network to Bob and Bob can retrieve his message later and 324 00:30:14,870 --> 00:30:20,820 with some relatively simple changes from this Loopix design, we can, to have 325 00:30:20,820 --> 00:30:26,820 stronger location hiding properties, where Alice and Bob don't talk directly to the 326 00:30:26,820 --> 00:30:32,010 provider that they're retrieving messages from. They can send single-use reply 327 00:30:32,010 --> 00:30:37,520 blocks to retrieve messages this would increase latency. 328 00:30:37,520 --> 00:30:40,240 J.: So one thing that's nice there's a comment to make here, is that a lot of 329 00:30:40,240 --> 00:30:46,240 time certain schemes in academia tend to use, want to use PIR for this retrieving, 330 00:30:46,240 --> 00:30:52,950 the the thing I thought from your from your provider and then the - one of the 331 00:30:52,950 --> 00:30:58,309 problems with using a PIR scheme here is that you're gonna have very different very 332 00:30:58,309 --> 00:31:03,070 different sort of assumptions at play there and the way even what you model it 333 00:31:03,070 --> 00:31:07,860 is going to be necessary necessarily quite complex. It's probably fun if you're a 334 00:31:07,860 --> 00:31:11,480 graduate student, you know, doing, playing with all this stuff but it's actually 335 00:31:11,480 --> 00:31:17,450 giving all of everything to match up will be complicated. So this is why, so in the 336 00:31:17,450 --> 00:31:21,220 scheme they were talking about here you actually, you're your mix net is giving 337 00:31:21,220 --> 00:31:24,890 you your location hiding property so you can you can extract some similar things. 338 00:31:24,890 --> 00:31:29,620 D.: Well, right and also, whereas in this situation, with a Loopix design it doesn't 339 00:31:29,620 --> 00:31:36,330 have strong location hiding properties, in particular if Alice really wanted to 340 00:31:36,330 --> 00:31:42,429 figure figure out where Bob is she would hack his provider and then stake it out 341 00:31:42,429 --> 00:31:46,780 until his IP address showed up again or so - 342 00:31:46,780 --> 00:31:52,070 J.: One problem with this, with these provider models, is that, like David just 343 00:31:52,070 --> 00:32:00,620 said, you can get your provider hacked and there's a way to fix that. It requires 344 00:32:00,620 --> 00:32:03,830 modifying Sphinx a bit, I said, I know that we just said don't roll your own 345 00:32:03,830 --> 00:32:07,990 packet format but it's a good idea to go through the security proof again anyway 346 00:32:07,990 --> 00:32:14,590 and it's a small change. But, so, the idea is that we have, in this middle, this 347 00:32:14,590 --> 00:32:21,210 harddrive picture, is is some sort of of mailbox server or cumulation thing, that 348 00:32:21,210 --> 00:32:27,249 the receiver here can move whenever he wants without telling his contacts. And 349 00:32:27,249 --> 00:32:31,580 his contacts actually reach him in other ways; either he gives them SURBs or he 350 00:32:31,580 --> 00:32:35,139 sub- puts the SURBs at this thing called a crossover point, which I didn't want to 351 00:32:35,139 --> 00:32:42,519 tell you too much about. So, but the the idea is that this guy can, our receiver 352 00:32:42,519 --> 00:32:49,429 can supply the - he can send some SURBs to this point in the middle and then the 353 00:32:49,429 --> 00:32:55,640 pack- and when he goes online - and then it will send him messages, so the you can 354 00:32:55,640 --> 00:33:00,419 have this ver- this decoupling and one of the nice things - so at the end of the day 355 00:33:00,419 --> 00:33:03,929 what the proof, what's your like security result for the mix net's going to be, is 356 00:33:03,929 --> 00:33:08,100 like, okay well, in three months - you know they're not going to be able to 357 00:33:08,100 --> 00:33:12,880 deanonymise you in three months. So we may be able to do a bit more if we can move 358 00:33:12,880 --> 00:33:19,809 this guy in the middle periodically. Okay, so but this is work, very much work 359 00:33:19,809 --> 00:33:22,780 in progress, it's not at all in the cuts and post thing and it requires modifying 360 00:33:22,780 --> 00:33:28,690 Sphinx and doing doing some redoing a number of proofs. So, okay, we've been 361 00:33:28,690 --> 00:33:35,690 talking about applications with the idea being messaging. There's other 362 00:33:35,690 --> 00:33:41,150 applications and - where you're still sending messages but to give you a bit 363 00:33:41,150 --> 00:33:46,850 more, something a bit more concrete: There's a there's a few schemes for doing 364 00:33:46,850 --> 00:33:49,340 anonymous money, well right now there's a lot of schemes for doing anonymous money 365 00:33:49,340 --> 00:33:52,490 and mostly they suck but there's a few that are actually quite good and have 366 00:33:52,490 --> 00:33:58,289 extremely strong cryptographic assurances on their anonymity: Zcash you basically 367 00:33:58,289 --> 00:34:01,049 would have to invert a hash function or something to break it, I'm not completely 368 00:34:01,049 --> 00:34:07,799 sure, Taler, well in in the RSA blind signatures have information theoretically 369 00:34:07,799 --> 00:34:10,460 secure blinding, which means they are absolutely unbreakable. 370 00:34:10,460 --> 00:34:11,750 There's a point in Taler where it's weaker 371 00:34:11,750 --> 00:34:18,860 than that, but another thing you might ask is, you know, can we do anything web-like. 372 00:34:18,860 --> 00:34:23,840 Well, there's a project that wants to like package up web pages and ship them over 373 00:34:23,840 --> 00:34:30,449 free nets, so you could use it to ship things over a mix network. But, 374 00:34:30,449 --> 00:34:33,980 fundamentally, if you imagine what we want to do is like build build some application 375 00:34:33,980 --> 00:34:36,860 that does some collaborative thing like run something like Google Wave or have a 376 00:34:36,860 --> 00:34:42,460 have just an etherpad over a mix network, you're gonna have the interesting issues 377 00:34:42,460 --> 00:34:48,400 that pop up with like the merges and other thing and, and anyway the latency is gonna 378 00:34:48,400 --> 00:34:53,370 have other impacts on the users. And one things we're not really thinking about but 379 00:34:53,370 --> 00:34:59,230 we would really like other people to think about is sort of how to make how to make 380 00:34:59,230 --> 00:35:08,420 people happy with higher latency applications. And this sounds hard, but 381 00:35:08,420 --> 00:35:11,670 actually a lot of times, like, you know when you look at people who are developing 382 00:35:11,670 --> 00:35:16,440 more modern web frameworks, actually they are doing you know more of the abstract 383 00:35:16,440 --> 00:35:23,000 alike something like couch TV is doing; it's not literally, you know, supporting 384 00:35:23,000 --> 00:35:27,110 latency, but it's it's decoupling things in a way that it is quite relevant to what 385 00:35:27,110 --> 00:35:30,060 we want to do. D: So, but it wouldn't be fair for us to 386 00:35:30,060 --> 00:35:35,150 say, like, "hey, use this cool messaging app - it's unreliable, so I'm gonna send 387 00:35:35,150 --> 00:35:40,980 you a message, but you might not get it." So we want to definitely build in some 388 00:35:40,980 --> 00:35:47,230 reliability, and and you and you pay for that in in retransmission some times and 389 00:35:47,230 --> 00:35:51,290 and some extra leaked information for which we need to compensate with more 390 00:35:51,290 --> 00:35:56,050 decoy traffic. We can actually -- the Loopix paper explores this trade-off where 391 00:35:56,050 --> 00:36:00,040 you can make the latency lower in a mixed network if you are willing to send more 392 00:36:00,040 --> 00:36:05,760 decoy traffic. And so that should help. J: Yeah 393 00:36:05,760 --> 00:36:11,190 D: It's it would still it still doesn't make mix networks, I don't think as low 394 00:36:11,190 --> 00:36:18,840 latency as tor or even close. But this is a matter of tuning, and we can at least 395 00:36:18,840 --> 00:36:22,660 have lower latency mix networks than say, 10 years ago. 396 00:36:22,660 --> 00:36:25,300 J: One of the nice things about certainly the nice things about the stuff that 397 00:36:25,300 --> 00:36:28,590 David and Yawning have been doing is that they're they're active really trying to 398 00:36:28,590 --> 00:36:39,840 make the - the the, sorry, the reliability measures work in the mixed work in the -- 399 00:36:39,840 --> 00:36:43,320 or just just above the mix network. And this is really essential if you want to 400 00:36:43,320 --> 00:36:48,030 build something that application developers can use because one it is 401 00:36:48,030 --> 00:36:53,650 actually common in anonymity systems for the sort of reliability measures to create 402 00:36:53,650 --> 00:36:59,420 to possibly compromise other things. So having being able to do the reliability 403 00:36:59,420 --> 00:37:03,910 stuff in a way that you can still have your security properties for it is 404 00:37:03,910 --> 00:37:09,100 important. Okay. D: Oh yeah, we'd like to say thanks to the 405 00:37:09,100 --> 00:37:14,240 researchers we've been working with. And I like to thank Yawning Angel for all the 406 00:37:14,240 --> 00:37:19,540 good design advice and work on the specifications. And and for George for his 407 00:37:19,540 --> 00:37:21,810 advice. J: George and Claudia are always one 408 00:37:21,810 --> 00:37:24,910 D: For their excellent paper. Anya for her Loopix paper. 409 00:37:24,910 --> 00:37:27,452 J: Christian I've - everything that I've been working on our talk to Christian 410 00:37:27,452 --> 00:37:29,550 about all the time D: Nick Matheson from the Tor project 411 00:37:29,550 --> 00:37:35,210 helped me out a lot with the with our PKI specification because, well, I mean he 412 00:37:35,210 --> 00:37:39,240 wrote the directory authority system for mix minion, and for tor, and 413 00:37:39,240 --> 00:37:43,440 J: And also to Trevor Perrin for running this wonderful mailing list which where we 414 00:37:43,440 --> 00:37:45,950 get all where we get numbers of important ideas. 415 00:37:45,950 --> 00:37:52,030 D: Ah yeah and Trevor also helped with our PKI sense so that was really great; with 416 00:37:52,030 --> 00:37:58,210 our wire protocol using noise, I mean. Anyway and that's that's the this new sort 417 00:37:58,210 --> 00:38:03,000 of project. Alright, that's it. 418 00:38:03,000 --> 00:38:12,960 *Applause* 419 00:38:12,960 --> 00:38:17,590 Herald: Thank you so much, if you have any questions here in the room, please line up 420 00:38:17,590 --> 00:38:25,470 at the microphones. Do we have questions from the internet? From the IRC Network? 421 00:38:25,470 --> 00:38:31,220 No questions from the IRC. There's one question microphone one 422 00:38:31,220 --> 00:38:35,720 Mic 1: You mentioned latency will be higher than tor - should we be thinking 423 00:38:35,720 --> 00:38:41,450 sort of seconds, minutes, what's the sort of order of 424 00:38:41,450 --> 00:38:44,000 J: We don't know D: Oh yes so the question is, the latency 425 00:38:44,000 --> 00:38:49,260 will be higher than tor, how how high will it be? We don't really know until we tune 426 00:38:49,260 --> 00:38:52,990 the mix Network and we're not J: George has claimed seconds so I don't 427 00:38:52,990 --> 00:38:55,500 know if I believe him D: I should start off by saying that mix 428 00:38:55,500 --> 00:38:59,081 networks aren't trying to be a general- purpose anonymity system like tor. We're 429 00:38:59,081 --> 00:39:03,850 trying to make customized networks for specific applications, and so each 430 00:39:03,850 --> 00:39:09,480 application has different traffic patterns in different ways they're used. So the 431 00:39:09,480 --> 00:39:17,390 latency would would necessarily come after tuning. Now, some, we have some idea that 432 00:39:17,390 --> 00:39:22,700 maybe a few minutes, let's say. But it; really I can't answer the question yet. 433 00:39:22,700 --> 00:39:27,620 Actually the researchers were working with are about to publish a new paper about how 434 00:39:27,620 --> 00:39:36,470 to tune decoy traffic and latency for the desired entropy you want in each mix, 435 00:39:36,470 --> 00:39:41,200 yeah. Herald: Microphone number two, your 436 00:39:41,200 --> 00:39:45,060 question? Mic 2: You have mentioned that the in 437 00:39:45,060 --> 00:39:50,510 mixed networks PKI's have higher scalability problems than in Tor - why is 438 00:39:50,510 --> 00:39:54,890 that? It looks like the mix Network will have less nodes because the you don't need 439 00:39:54,890 --> 00:39:59,400 route unpredictability, so J: I mean if you're trying to build a 440 00:39:59,400 --> 00:40:03,230 replacement for email and you want everyone in the world to use it, if you 441 00:40:03,230 --> 00:40:10,060 work through like, a sort of very bullshit back of the envelope computation - 442 00:40:10,060 --> 00:40:17,810 there's an argument that your that if you have a central that a centralized PKI plus 443 00:40:17,810 --> 00:40:22,610 whatever other anonymity system is only about 10 million times better than just 444 00:40:22,610 --> 00:40:27,790 sending every message to everybody. Something, you know, that's very back of 445 00:40:27,790 --> 00:40:37,090 the envelope you can try and work. So you need; yeah well okay so there's that, and 446 00:40:37,090 --> 00:40:41,600 and the the specific seeing when I said it's less of a problem for tor, is that 447 00:40:41,600 --> 00:40:44,020 tor can do certain clever things like there's a, 448 00:40:44,020 --> 00:40:47,070 there's one of their proposals I think is actually not taking that seriously at the 449 00:40:47,070 --> 00:40:52,150 moment is where they published this big list - they published the PKI or sorry, 450 00:40:52,150 --> 00:40:57,890 the big the the thing and nodes don't actually download the whole, the the whole 451 00:40:57,890 --> 00:41:02,290 consensus at all. They just point to a place in the consensus and they get back a 452 00:41:02,290 --> 00:41:06,170 proof that they were given the correct that they were forwarded to the correct 453 00:41:06,170 --> 00:41:10,240 node. So this might this then gives you another order of magnitude or two on that 454 00:41:10,240 --> 00:41:16,370 fat on that you know 10 million I just quoted you. 455 00:41:16,370 --> 00:41:22,090 Herald: Okay, microphone number three Mic 3: Hi, this is looks like really good 456 00:41:22,090 --> 00:41:26,980 work and I'm happy to see it - now my question is if there are multiple 457 00:41:26,980 --> 00:41:30,530 applications which have different tuning requirements, can they share the same 458 00:41:30,530 --> 00:41:34,160 network and help each others anonymity set, or do we have to have multiple 459 00:41:34,160 --> 00:41:38,610 networks? D: Ah, so we agree it would be best if 460 00:41:38,610 --> 00:41:43,130 they could help each other by increasing each other's anonymity set. But we're 461 00:41:43,130 --> 00:41:48,720 concerned that the specific tuning for the decoy traffic might prohibit this in some 462 00:41:48,720 --> 00:41:54,110 cases. For -- actually, and there's some other considerations as well, so since 463 00:41:54,110 --> 00:41:59,510 we're not stream oriented, all the data has to fit in one packet. And so if we 464 00:41:59,510 --> 00:42:04,490 have like an email use case, we probably are gonna get around 50 K average size 465 00:42:04,490 --> 00:42:10,430 emails, let's say. And if we want to make like mix chat or Katzen chat application, 466 00:42:10,430 --> 00:42:15,650 I might send really short messages like, "yo what's up", and now we're sending that 467 00:42:15,650 --> 00:42:19,570 in a big 50 K a packet. J: So, one thing that is clear - if you 468 00:42:19,570 --> 00:42:23,320 wouldn't do it for all, think you wouldn't have a new thing for every application. 469 00:42:23,320 --> 00:42:26,210 Obviously if you have something that's gonna be quite infrequent like a payment 470 00:42:26,210 --> 00:42:32,070 thing, then it needs then you should be using a network with with much more 471 00:42:32,070 --> 00:42:36,480 frequent packets and just accept that you're gonna be you -- accept though the 472 00:42:36,480 --> 00:42:40,560 inefficiency. D: And there's another consideration too - it, which is, 473 00:42:40,560 --> 00:42:45,320 sometimes in these chat applications, communication partnerships might be 474 00:42:45,320 --> 00:42:48,510 symmetrical in that we might send each other roughly the same 475 00:42:48,510 --> 00:42:53,560 amount of data. And and stuff that, like not that I don't think mix Nets are good 476 00:42:53,560 --> 00:42:58,230 for web browsing, but in stuff like the web it's more like "get to page" and then 477 00:42:58,230 --> 00:43:02,490 you get a bunch of information back. So there's a lot of different; so what would 478 00:43:02,490 --> 00:43:08,470 the decoy traffic look like that versus a symmetrical communication partnership. So 479 00:43:08,470 --> 00:43:13,140 that's what I meant by some applications might not be compatible with each other to 480 00:43:13,140 --> 00:43:17,250 tune this decoy traffic J: Yeah we certainly would hope that most 481 00:43:17,250 --> 00:43:21,550 sort of like peer-to-peer, that, you know most sort of peer-to-peer like all of your 482 00:43:21,550 --> 00:43:25,630 etherpad, your other sort of collaborative applications, your email, your payment 483 00:43:25,630 --> 00:43:28,611 network - we'd certainly hope that all that stuff could be bundled onto one thing 484 00:43:28,611 --> 00:43:33,750 that was sort of optimized for this email- like use case. And then whether if you 485 00:43:33,750 --> 00:43:40,570 actually need the instant messaging network at all is another question. 486 00:43:40,570 --> 00:43:44,580 Herald: All right, microphone number one what's your question? 487 00:43:44,580 --> 00:43:49,280 Mic 1: Um, can you give well can you give more concrete examples of software to try 488 00:43:49,280 --> 00:43:54,610 out or like, so like like papers are great, like is there anything to touch to 489 00:43:54,610 --> 00:43:57,850 act to, whatever D: Well well, I mean, actually right now 490 00:43:57,850 --> 00:44:03,250 we're running a test mix Network on several machines that we had lying around, 491 00:44:03,250 --> 00:44:08,240 and it works great - thanks for (meskhi oh) and (kali) for their help for that. 492 00:44:08,240 --> 00:44:14,460 But, we don't really have any anything near production-ready, like 493 00:44:14,460 --> 00:44:21,300 J: Yeah the stuff I was talking about doesn't even work. 494 00:44:21,300 --> 00:44:27,590 D: So the answer to question is: no, we got nothing. But but we hope we hope soon. 495 00:44:27,590 --> 00:44:31,510 Like, I'm not sure how soon, but J: Depends on funding, depends on other 496 00:44:31,510 --> 00:44:37,750 things: we're working on it. Herald: Thank you, microphone two: what is 497 00:44:37,750 --> 00:44:41,420 your question? Mic 2: I was thinking about this in the 498 00:44:41,420 --> 00:44:47,380 real world - you're envisioning an app where people can communicate, and I worry 499 00:44:47,380 --> 00:44:54,930 about mobile telephones because; let's envision two users using this app to 500 00:44:54,930 --> 00:44:58,950 communicate with each other. The idea would be that one person sends a message 501 00:44:58,950 --> 00:45:02,260 and then sometime later this other person takes their phone out 502 00:45:02,260 --> 00:45:06,180 of their pocket. There is so much going on when a phone comes out of a pocket and 503 00:45:06,180 --> 00:45:12,270 as the screen is turned on. WhatsApp is talked to; there's so much that that you 504 00:45:12,270 --> 00:45:17,190 can look at outside of this whole mix Network that if you, over a month of time, 505 00:45:17,190 --> 00:45:22,220 can correlate who picks their phone out of their pockets every time when, when person 506 00:45:22,220 --> 00:45:25,680 sends a message. So can't you correlate that way and isn't that a huge problem 507 00:45:25,680 --> 00:45:29,940 that, that sort of is completely outside of the world of the of the problems you're 508 00:45:29,940 --> 00:45:34,780 thinking about. J: My, in my ideal; I have no idea. In my 509 00:45:34,780 --> 00:45:40,480 ideal world the part of the solution to making the users happier with latency is 510 00:45:40,480 --> 00:45:45,340 the phone doesn't ding anymore. You don't get notifications - you check your phone 511 00:45:45,340 --> 00:45:51,720 when you check your phone. Mic 2: Sorry, I think that would be an 512 00:45:51,720 --> 00:45:55,690 important security property as well. J: But I would actually like it there's a 513 00:45:55,690 --> 00:45:59,960 question here is: would that make people actually happier with latency? What can 514 00:45:59,960 --> 00:46:03,330 you, I mean, you you know all of these things that are being built now are being 515 00:46:03,330 --> 00:46:07,530 built to sort of maximize engagement. And you want to actually, you actually don't 516 00:46:07,530 --> 00:46:10,670 want to do that anymore. You want people to only use it when they want to you know 517 00:46:10,670 --> 00:46:19,490 when they want to use it. Herald: All right, thank you. Seems there 518 00:46:19,490 --> 00:46:24,480 are no further questions, so thanks a lot to Jeff, thanks a lot to David 519 00:46:24,480 --> 00:46:34,655 *Applause* 520 00:46:34,655 --> 00:46:51,280 *Music*