WEBVTT 00:00.000 --> 00:14.560 Okay, hi, good morning, I'm Alexis, this is Harry, I'm also a part of the decentralized 00:14.560 --> 00:26.800 at the CDC committee, so we are a bunch of crew at CDC every year and working on the 00:26.800 --> 00:33.120 privacy infrastructure, so here I was Harry, we've been working for years on the first 00:34.240 --> 00:41.120 large size mixnet in decentralized mixnet in order to build anonymity and so 00:43.520 --> 00:49.280 yeah, we have a we have a team with been it was like coming from a European project called Panohanix 00:49.360 --> 00:55.840 and so with Claude Adias and Annapute Roscaue who are a part of a cozic and also from 00:55.840 --> 01:05.600 a university in UCL they develop a concept based on David Shom's initial concept of the mixnet, 01:05.600 --> 01:12.960 so it's I think we've been funded by first by the European Commission and it was like a large 01:12.960 --> 01:20.320 effort on building a large mixnet, so why does it matter, basically on the internet you leave a lot 01:20.320 --> 01:28.800 of metadata and you can encrypt as much as you want your communication, your message actually 01:28.800 --> 01:35.360 the metadata is about the timing and the volume of data which is exchange and also like the 01:35.440 --> 01:43.520 the recipient and the receiver the recipient and the sender of this communication and so this 01:43.520 --> 01:51.200 pattern can be analyzed and basically the metadata is as important as the content of the data itself, 01:51.920 --> 01:59.680 so when we talk about surveillance capitalism it's more about the profiling and so it's more 01:59.760 --> 02:04.240 about the metadata than actually the data itself and also I think there's a study where you can 02:04.240 --> 02:12.480 derive the content of the data just based on the metadata itself, so how do you hide this so that was 02:12.480 --> 02:23.120 the original idea from David Shom to make a mixnet but it was based it was done for email that's 02:23.120 --> 02:30.960 so the remalers and so you had a whole research for a long time about how to do anonymous email 02:30.960 --> 02:41.440 and remalers and so this is where the name NIM comes from, yeah it's a bit slow, so here you have 02:41.440 --> 02:46.480 like different kind of topologies of the network and so we can see in practice how it works so 02:47.120 --> 02:54.400 on the top you have like a traditional VPN which is basically one computer between you and the 02:54.400 --> 03:02.400 person you're trying to speak to and in this case basically the you hide your IP address and you can hide 03:02.400 --> 03:08.560 where you are from the internet from the person you're talking to or what sort of website you're 03:08.560 --> 03:17.200 going but still the VPN in the middle knows exactly who you are and why you're where you're going so 03:18.320 --> 03:26.640 this model has me improved by double VPNs or even tour which has maybe three computers where 03:26.720 --> 03:36.480 indeed the the degree of separation between you and the the other side is like a much wider but 03:36.480 --> 03:43.760 still by and that is analyzing the timing for example you can make timing at tax and if you 03:43.760 --> 03:49.680 observe the whole network you can correlate who's talking to who so here the design is what we call 03:49.760 --> 03:58.000 five hop or a mixnet which basically creates extra lag and we'll go into the detail how 03:59.280 --> 04:05.840 the the packaging system is done but basically here you can see your enter into a gateway and then 04:05.840 --> 04:11.440 every packet has its own own onion rooting that goes through another gateway and then finally 04:12.080 --> 04:19.520 reaches the the other side and there's some noise which is added some fake packets and there's some 04:20.160 --> 04:26.400 latency which is added so it's slower but it actually prevents for an observer to correlate 04:26.400 --> 04:34.320 between the sender and the recipients so yeah so that's the that's the whole that's the whole point 04:34.320 --> 04:40.480 the whole point is basically and and this is our wallpaper you can go and read on on our websites 04:40.480 --> 04:48.320 you have the link over there the whole point of the mixnet is to avoid is to protect ourselves from 04:48.400 --> 04:55.360 a global passive adversary which is going to be able to have to view the whole network or 04:55.360 --> 05:04.480 big parts of the network and and and this is a new kind of attack that is trying to 05:04.480 --> 05:13.200 denomize basically the your your connection so please you can go read this it's a bit slow so 05:14.160 --> 05:20.240 the project like moved on and basically what we did is that we mixnet is something which is 05:20.240 --> 05:27.120 pretty hard to understand for people and it's pretty slow so in order to like create some 05:27.120 --> 05:32.080 adoption what we build also we use the infrastructure and the infrastructure of the mixnet is like 05:33.200 --> 05:38.880 the mixnet itself but it's also like a second element which is what we call the ZKNIM the 05:38.960 --> 05:45.520 NIM credentials basically this is a zero-knowledge proof that allows you to prove that you 05:45.520 --> 05:52.320 have that you have the right to access the network because in this case it's an incentive network 05:52.320 --> 06:00.720 so we built a an app which looks like a VPN app and but the app has actually two mode it has a 06:00.720 --> 06:06.240 double VPN mode two two VPN mode which we call the fast fast mode based on wireguard an easier 06:07.200 --> 06:12.160 fork and and then there's the anonymous mode which is the mix that and people can try out 06:12.160 --> 06:17.040 and so you can try out the mixnet through a normal app you can also like connect directly on the mixnet 06:17.040 --> 06:21.760 because the mixnet itself is free to use and you can connect it through CLI but for like 06:22.560 --> 06:29.440 daily usage we have the app to make it nice and to have an entry point in one country and an 06:29.440 --> 06:38.960 exit point in another country and and you just connect yeah so there's a whole community behind 06:38.960 --> 06:44.960 NIM which is maintaining all the servers so the whole network of so we only provide provide the code which 06:44.960 --> 06:52.320 is all GPL version three for the for the client side applications and what is running on the on the 06:53.280 --> 06:58.320 on the servers and basically we don't run any infrastructure and it's the community who is running the 06:58.400 --> 07:04.160 infrastructure so hopefully we will go we're going to provide tools so that people can share their own 07:04.720 --> 07:11.440 personal internet connection outside also yeah and now we're going to go into the deep dive and it's 07:11.440 --> 07:20.960 I'm going to give her the talk the mic from okay thank you Alexie so I'm going to I think I 07:20.960 --> 07:28.000 have a few minutes here oh maybe not let's so we're going to try to explain 07:29.360 --> 07:35.840 I'm going to put this on real quick exactly how this thing works so is this better better okay 07:35.840 --> 07:43.920 so effectively when you a mixnet just to reiterate it does what it says on the tin so to speak 07:43.920 --> 07:50.080 it mixes packets and by virtue of mixing packets anonymizes packets on the packet level 07:50.240 --> 07:57.040 so as an overlay network on top of your ordinary TCP IP or UDP connection how does this work 07:57.840 --> 08:03.360 you are hanging out your machine you're running our demon you're running it the NIM software 08:04.160 --> 08:10.160 just like you would you know proxy to any other overlay network like Tor VPN but what you do 08:10.720 --> 08:18.240 is you send your packets to the NIM client and the NIM client packages those packets and the equally 08:18.320 --> 08:24.080 sized uniform cryptographically encrypted packets on your machine using something called the 08:24.080 --> 08:32.960 Sphinx packet format okay then those packets are sent using a what's called a passon distribution 08:32.960 --> 08:39.280 extra continuous time distribution what cover traffic will go into one second into the mixnet 08:39.280 --> 08:46.640 itself at each hop the packet is mixed with other packets then you know after enough hops three 08:46.720 --> 08:52.080 is what we've shown is more sort of declining returns after three every packet has to kind of mixed 08:52.080 --> 08:58.960 ideally equally with other packets the packets come out and they're effectively anonymous next line 09:00.320 --> 09:06.240 so how this things packet format works is a little bit like onion routing if you're familiar with Tor 09:07.040 --> 09:12.960 you could read the paper we've done only a few minor modifications to the paper to get the kind of 09:12.960 --> 09:17.520 crypto more cryptography more at the speed but effectively what you want to say you've got 09:17.520 --> 09:23.840 you have a header that tells you kind of like what's you download the topology of the mixnet 09:23.840 --> 09:29.360 we do use a blockchain that's the main use of it to decentralize the downloading of topology 09:29.360 --> 09:35.680 you download this topology the topology is a bunch of nodes again ran by decentralized volunteers 09:35.680 --> 09:42.240 each identified by a key you then basically do a bunch of diffi Helmins or Kims in the future version 09:43.440 --> 09:51.120 to basically get you your shared keys then you blind each of those and then you attach a payload 09:51.840 --> 09:59.760 and then what happens at each hop you kind of like removing one you do an integrity check 10:00.160 --> 10:06.480 and then you kind of remove one layer and be blind so what this means is that each mixed node 10:06.480 --> 10:11.360 only knows the next mixed node it's going through they don't know your final destination 10:12.080 --> 10:17.120 and then also because we use a wide block cipher is called rerandomizable 10:17.760 --> 10:24.320 but at each hop you can rerandomize all the bits in your packet so that provides what's called 10:24.400 --> 10:31.760 bitwise unlinkability so if an adversary is watching your packets every single packet 10:32.800 --> 10:38.480 and they're looking at the bits at each hop the bits totally change so you can't distinguish 10:38.480 --> 10:44.400 if a packet has gone into a mixed node and it's the same packet coming out by looking at the bits 10:45.040 --> 10:49.200 now how it works and this is sort of knit this is how it's always worked but we're actually 10:49.200 --> 10:55.840 going to show this in the GUI the next release so this would be quite exciting is how it mixes 10:55.840 --> 11:02.720 is again at each hop there's a delay right there's some delay it's randomized ideally and then 11:02.720 --> 11:10.240 that delay you can kind of set the delay but again the what happens is like I'm releasing a packet 11:11.040 --> 11:19.120 and the stream of packets could reveal my data so I release the packets I slow them down 11:19.200 --> 11:24.880 and release them according to a standardized process that's a pass on process and that's a cool 11:24.880 --> 11:31.520 process because I know that every time it's supposed to take my packet to get there right but each 11:31.520 --> 11:36.560 packet individually could be like delayed who knows how long and that kind of scramble the 11:36.560 --> 11:43.760 enemies attempt to predict when your packet is being sent or not and then you have the sending rate 11:43.760 --> 11:49.120 so again we're smoothing these bursts of traffic we're in the pass on process we're delaying 11:49.120 --> 11:55.440 traffic whenever you're not sending a packet a fake packet is sent so the pass on distribution 11:55.440 --> 12:00.240 is kind of maintained and then we also have a second stream of cover traffic and this really 12:00.240 --> 12:05.840 provides a lot of anonymity at the cost of a large slow down and so the way you want to think 12:05.840 --> 12:13.840 about this I'm trying to speed up here is that at each mix there's a delay right so I have a I 12:14.720 --> 12:21.040 packet it's going to mix one it's going to mix two it's going to mix three and these different delays 12:21.840 --> 12:31.040 basically provide a is what actually provides your anonymity and what's really important is that if you 12:31.040 --> 12:36.960 want to send let's say cool the property that's provides in terms of privacy is called sender 12:36.960 --> 12:41.920 anonymity so the sender of the packets anonymous but maybe you want to get some packets back and you want 12:41.920 --> 12:47.120 those packets to also be anonymous so what you do is you use what's called a single use for 12:47.120 --> 12:52.720 apply block which is just a kind of you you don't give when you say I want packets back you don't 12:52.720 --> 12:58.480 ideally give your home address or your address of your gateway or first node you give it kind of 12:58.480 --> 13:04.080 dropbox in the middle of the network somewhere and you give it and then when packets are delivered 13:04.080 --> 13:09.520 there then you send packets again and so this kind of looks like almost like a chat like a chat 13:09.520 --> 13:14.400 and they're going to back and forth between different drop boxes of course the real quick 13:14.400 --> 13:20.800 because every assume most people here are devs let's spend let's see what I might have five minutes 13:22.640 --> 13:28.560 10 okay so I want five minutes of questions but let's just go five minutes on how you could use this so 13:28.560 --> 13:34.880 get some mix net and I want maybe you want to build a app on it so we provide there's two ways 13:35.200 --> 13:44.640 one is very traditional right which is just use your socks five local you send your traffic to 13:44.640 --> 13:50.400 a local local host then of course you know it's sinks in the home then mix that kicks in the 13:50.400 --> 13:56.720 gear and this actually works kind of out the box with you know software like Monero desks top or 13:56.720 --> 14:04.320 Firefox that support socks more app support than you think however a lot of apps don't and also 14:04.320 --> 14:10.000 you know this users may not want to cut in paste you know they're they may not really understand socks 14:10.000 --> 14:15.520 we also allow compilation and API calls and again if you're injured if you're free software 14:15.520 --> 14:21.920 devs I assume most you are are all the client code is GPL version three there's some a patch in 14:22.320 --> 14:30.320 and my and my device is code in the server side now what what do you get when you kind of 14:30.320 --> 14:34.640 integrate them you get a bunch of stuff and you don't have to use it all I just want to say 14:34.640 --> 14:40.240 some of the stuff that we provide that could be useful for you so again we mentioned earlier ZK NIMS 14:40.880 --> 14:47.440 you know NL net and next generation in GI next generation internet help fund some of that work 14:47.440 --> 14:54.400 with ZK NIMS are just a decentralized threshold signature so it's a little bit it's anonymous credential 14:54.400 --> 14:59.680 you can kind of prove things in zero knowledge but more like attribute value pairs it's useful 14:59.680 --> 15:03.920 as a kind of autonomous authentication system because maybe you don't want like everyone 15:04.880 --> 15:10.640 overloading your app and using it like DDoS people which of course is one great use case of 15:10.640 --> 15:18.080 anonymizing technology do you know that we do try to you remember the PGP talk you know 15:19.520 --> 15:24.400 we did try to provide some elementary cryptographic security for the mix that so again there's e-pocks 15:24.400 --> 15:31.200 every e-pock the topology is refreshed it's about an hour and we refresh the keys so you have some 15:31.200 --> 15:37.680 level for security on the cryptographic level currently between the nodes and the mix that we 15:37.680 --> 15:44.560 use noise between you and the first hop we use a mixture of web sockets and we also use wire guard 15:44.560 --> 15:50.480 there and then we do do censorship resistance but when we launch the app a lot of people try to 15:50.480 --> 15:54.960 use them in countries like Russia and China and of course it didn't work because the traffic 15:54.960 --> 16:00.640 looks really weird and wire guards blocks so forth and so on so we do provide modes such as quick 16:00.640 --> 16:05.040 with domain frightening to help poke through censorship and it's been surprisingly effective 16:05.040 --> 16:09.200 particularly combined with decentralization with it's not like a set number of IPs that since 16:09.200 --> 16:15.920 are can just block so if you're interested in native integration we provide a rust SDK 16:15.920 --> 16:23.360 a crate which is the guy from IRO as for we just provided we provide a JavaScript SDK in pmp packages 16:23.360 --> 16:28.400 and because a lot of people need to use C and go particularly in mobile we also provide bindings for 16:28.400 --> 16:35.440 C and go next okay I don't think my time we go into this in super much detail but effectively 16:35.440 --> 16:40.160 what's really cool about them is because the whole thing is built in rust so I'm just going to just 16:40.160 --> 16:46.560 quickly say because it's built in rust you can basically take the whole thing put in web assembly 16:46.560 --> 16:52.000 you can run them inside of a website just also very useful for censorship resistance and we have 16:52.000 --> 16:57.600 a testnet you can use as well that testnet lets you kind of test your app out without screwing up 16:57.600 --> 17:03.200 the real world network if you're building it anything so the rust SDK has a lot of different 17:03.200 --> 17:10.400 modules we have basically you know modules the easily proxy on top of TCP IP we allow you access 17:10.400 --> 17:15.840 the raw data various kinds of interfaces to do all sorts of stuff and particularly to help out 17:15.840 --> 17:20.880 with TLS hand shakes other things that you might need for JavaScript this time we go quickly 17:20.880 --> 17:26.880 here for JavaScript we have kind of two different packages we provide all the functionality the 17:26.960 --> 17:34.320 low-level functionality that you have in rust is provided in what's called mixnet client but a lot 17:34.320 --> 17:39.680 of JavaScript does they really don't want to get down which I can't blame them into the real 17:39.680 --> 17:47.200 dark layers of TCP IP and UDP so we provide a simple thing called mix fetch so if you use the 17:47.200 --> 17:53.280 if you ever use a fetch you can just kind of drop in mix fetch and then you kind of get the mix 17:53.280 --> 17:57.440 net so it's just fetch over the mixnet and that's very useful we found it would be a popular 17:58.160 --> 18:03.760 aspect we are upgrading to post quantum we've upgraded sphinx already so we have a new packet 18:03.760 --> 18:10.560 format called outfox the central trick is that we will allow users to have long-standing keys 18:10.560 --> 18:16.560 including as necessary in macallus keys and we can substitute MLKM or whatever other variant you want 18:16.560 --> 18:21.840 where we use curve two five five one nine right now it seems to work pretty well that will be 18:21.840 --> 18:28.560 implemented the deployed over March we have a lot of people building apps some file sharing apps 18:28.560 --> 18:34.560 messaging apps mailers drives I think one of our good friends over there is working on an 18:34.560 --> 18:40.960 open WRT fork you even put nim on your router or your star link or whatever and even some proof 18:40.960 --> 18:48.160 of concept of using it to anonymize connections that local AI AI and so yeah so we have a lot of stuff 18:48.160 --> 18:55.360 we want to build SSH deaddrops hidden services tons of cool stuff could be built if you want to build 18:55.360 --> 19:00.480 just talk to us we've been discussed more we have we want to try the app we can give you free access 19:00.480 --> 19:05.680 to the app for as long as you want just stop buying grab us after the talk and I do want to think 19:05.680 --> 19:09.120 the person that inspired us to do all this actually was I know it's a bit controversial but 19:09.120 --> 19:13.920 joining us on's really did kind of push for us to help build this way back in the days and look 19:13.920 --> 19:20.240 we do know every we do know that it seems paranoid but surveillance now is totalizing 19:20.240 --> 19:25.840 every single packet can be watched and therefore we need a system which can break that break that 19:25.840 --> 19:30.000 and I think nim is the first real world system to do so thanks so much so if we have time for maybe 19:30.640 --> 19:37.440 I don't know one question a moment one question so we have time for a question maybe one 19:37.440 --> 19:45.520 one question for it yeah sorry the noise that you have mentioned that you say about the 19:45.520 --> 19:52.000 idle packets at the random idle packets you send it during the idle times yeah so what happens 19:52.000 --> 19:57.520 is like I have my machine online and I'm sending a packet on the normal internet you just send the 19:57.520 --> 20:01.120 packet you know you get this kind of burst of traffic because you're just in the bunch of packets 20:01.120 --> 20:06.880 at once so what nim does we we're continuously sending packets on this kind of exponential 20:06.880 --> 20:12.160 looking distribution so it's like this and then essentially when you're not sending packets we 20:12.160 --> 20:17.600 fill in fake packets and so that's the that's the fake cover traffic we also have a few advanced 20:17.600 --> 20:21.680 techniques we'll work on but those aren't quite ready yet to basically because the main problem 20:21.680 --> 20:25.920 of nim is you run on your mobile you're seeing a lot of fake traffic your mobile is online you 20:25.920 --> 20:30.240 have limited data plants not so great so you can we want people to just that build turn it off 20:30.240 --> 20:37.120 and on uh next question we actually have time for a few more so uh awesome I see one over here 20:50.000 --> 20:54.720 oh it's pretty huge right here's a piece of question real quick for the stream oh one 20:54.720 --> 20:58.880 oh I can repeat so what's the difference between the fast mode and the mix that so again the fast 20:58.880 --> 21:03.760 mode says hey cool we have this decentralized network let's just use it like tour and send packets 21:03.760 --> 21:07.120 through and it's because some people they want to do things like watch video and you know we want to 21:07.120 --> 21:12.800 support that too however in general uh mix nuts you know we're talking about like kind of one 21:12.800 --> 21:19.280 megabyte speeds here around in terms of upload download and that's often too slow for a lot of use 21:19.280 --> 21:24.480 cases and that's with like kind of lower level non-immediate you want higher level you can of course 21:24.480 --> 21:31.600 wait even longer um I would say 10 seven seconds is pretty good but then you again it's too slow so 21:31.600 --> 21:39.040 the fast mode just to be clear sends packets into the entry of the mix nut but skips the mixing 21:39.040 --> 21:45.280 part and then send them out a decentralized uh a decentralized network on some level we take the 21:45.280 --> 21:51.120 mix of infrastructure and we in a degenerate case push it towards something that looks basically like 21:51.120 --> 21:56.720 tour or decentralized VPN and that ends up being very fast so that you can you can it's about 21:56.720 --> 22:02.960 fast decentralized VPN because again with a mix nut you want to think back weird-wise it's slow 22:02.960 --> 22:08.720 a mixing delays but that's what gives you an automatic and b cryptographic and linkability 22:08.720 --> 22:16.160 but that requires per packet five defy helmet operations or key exchange operations and that's slow 22:16.240 --> 22:21.920 so uh the fast mode again you're you're doing basically wire guard twice it's like a tunnel inside 22:21.920 --> 22:26.880 tunnel so two cryptographic operations in each packet is sent to the same tunnel so it's a 22:26.880 --> 22:37.840 basis fastest centralized VPN I think that's about as fast as you can get um yeah it's about as fast 22:37.840 --> 22:42.160 that's that I mean you can you could maybe speed up a little bit I think if you've got rid of 22:42.160 --> 22:48.000 all the mixing and it was just like pure cryptography I think we can get it down to like 300 milliseconds 22:48.000 --> 22:52.480 but again there's always network latency between nodes and decentralized networks so if you're running 22:52.480 --> 22:56.560 it like an a test environment and you can do that we we can let we give you having the structure 22:56.560 --> 23:02.960 to do that you can make it even even faster uh hey another question so you presented a VPN which 23:02.960 --> 23:09.200 probably tunnels IP so addresses would be regular IP addresses right via socks and so on but then 23:09.280 --> 23:13.760 you also mentioned hidden services so I'm wondering how our hidden services address and how 23:13.760 --> 23:19.680 stable RT's addresses yeah so again the way you think about mixing that it's a little bit different 23:19.680 --> 23:24.720 than tour it provides an army for the sender and you can provide some an army for the recipient 23:24.720 --> 23:29.440 via again this single use reply block flow so if you want to learn about that flow we have 23:29.440 --> 23:37.200 love documentation on it the problem with that flow is that because it's anonymized using like per packet 23:37.280 --> 23:43.840 routing right it's not ideal like how tour works the hidden services toward as a DHT inside 23:43.840 --> 23:47.360 the network so distribute hash tables you go to like a tour and you're like oh where's thought 23:47.360 --> 23:51.920 onion and you have a key and that kind of sends you there so we don't have persistent 23:52.560 --> 23:57.440 identities within them because every packet is anonymized kind of separately and they're sent 23:57.440 --> 24:04.880 back and forth to different kind of dead drop so again very paranoid which is good but not good 24:04.880 --> 24:08.160 for hidden services because people just want to like I want this website with this long term 24:08.160 --> 24:14.080 precise ID so that's actually an open research topic so we haven't figured out how to do it yet 24:14.080 --> 24:19.440 you could if you were going to build like something that was like an anonymous chat service 24:20.160 --> 24:24.240 like an anonymous I don't know LLMA AI bought or prompts or something I think 24:24.240 --> 24:29.120 nimble actually would be perfect because again chatting is a bit like asynchronous messaging right 24:29.120 --> 24:33.360 so you send something is something back you send something and each of these packets are like 24:33.360 --> 24:38.240 self-contained and the mix that's very good at this kind of self-contained thing like signal 24:38.240 --> 24:43.680 messages or PGP encrypted emails or crypto currency transaction stuff like that it's not so good 24:43.680 --> 24:50.000 like giant chunks of JavaScript like websites so I think it's interesting topic to get hidden 24:50.000 --> 24:54.640 services in someone so talk about it we I can talk a lot about it we had someone did a master 24:54.640 --> 25:00.720 thesis on it you can build these kind of things on top of them but we don't have like a native 25:00.800 --> 25:06.400 hidden service way but you could easily build an online chat apps that kind of look like a hidden 25:06.400 --> 25:12.080 service on top of them that's what we recommend doing now I think that's it maybe I want to 25:12.080 --> 25:16.320 I think that's yeah okay well grab this afterwards thanks so much a more out of applause everyone thank 25:16.320 --> 25:22.720 you very much guys and keep the internet anonymous all right thank you guys