How to improve privacy and censorship-resistance by integrating a mixnet

Transcript

[music] [music] Hello, good afternoon ladies and gentlemen. Hello to you too uh who are watching online. My name is Jimn and I have the pleasure of serving as an MC today here. Before we begin and during the session, if you'd like to ask questions to the speaker, either you can go to defcon on your phone to submit questions or ask directly at the right moment. Um, so let's get started. Our first workshop is on how to improve privacy and censorship resistance by integrating a mixet. Let's welcome Max

Hampshire to the stage with a round of applause. >> Hi everybody. Um so first of all um everyone can actually follow along with what we're going to be going through today. Um all of the stuff that's on here is actually a documentation website with all of the stuff that I'm going to be demoing embedded in the web page. So, if you want to go to I know the bar at the top is quite small, but if you want to go to devcon-.nim.com. Um, and I'll obviously be keeping this documentation site up afterwards as well, so you can kind of always have it as a reference. Um, so I'll give everyone a sec to do that. If everyone who wants to do that, like give me a

thumbs up when you're on it. Uh, I can see a few people typing. So, okay. Two. Yep. and someone else is on it. All right, fantastic. Okay, so first of all the basically as we said we're going to be talk this is a workshop about how to integrate them with the NIM mix but then also what integration actually means. So we're going to start off [snorts] just briefly talking about what NIM is, what a NIM client is as well because it's slightly different from the usual kind of like networking clients that people are probably used to. people are probably used to thinking about HTTP or websockets or something like that. Um, and then we're going to step through all

of the different options that we have. Now, because this is an Ethereum conference, um, and a lot of the Ethereum ecosystem is web app driven, we're going to be focusing on all of the kind of all of the SDK stuff, all of the libraries that we have that work with browsers today because that's the kind of general dev environment we're in. We're going to touch on some of our other stuff, some of the Rust command line tools that we have, but we're really going to focus on those. And then we're going to go through some demos basically. Um, as well as talking about some of the kind of additional latency and limitations that the Mixat kind of brings with it at the moment. Um, as you can also see on the website and if you also want to follow along, then um, if you want to just plug an agent in and

uh, ask it a bunch of questions, then you can also do so. that's on the documentation site as well. We have an MCP server exactly for that. So, first of all, what actually is NIM? So, NIM is a decentralized network. It's an overlay network, right? Lots of computers around the world running on different servers or in people's houses that basically allows you to protect your network traffic against surveillance at the network level. Right? So, you can think of it like this. Um, at an Ethereum conference, we obviously talk a lot about ZK. Um, if you're thinking about just how the internet works in general, you can think of, oh, well, if it's encrypted, then it's protected, right?

That's not true necessarily. Encryption protects the contents of a message, right? Like TLS stops someone who intercepts your packets being able to see what the contents of the payload is that you're sending to a website, but it doesn't stop them actually being able to see which website you're communicating with, right? What your IP address is, what your connection type is. That's what Nim kind of [clears throat] that's the additional underlying network level protection that Ny gives you. Now in the context of Ethereum, right? Then think of it like this. Every time that your wallet basically contacts an RPC server, maybe it wants to get the balance for a particular account or you're actually

broadcasting a signed transaction to an RPC provider, right? The contents of that payload, yes, is protected, but your metadata is very visible. Every time you interact with an RPC provider, you're telling them your IP address, your connection type, and a whole host of other information about you. Why is this important? Because maybe that RPC provider is malicious. Maybe they're going to actually do something like a selective disclosure attack. Maybe they'll go, "Actually, no, we'll give you a different balance back. Maybe we'll drop your transaction, right?" Or alternatively, they might just be gathering information about you. This d this information is valuable. We already know that several centralized RPC providers have sold information in the past, shared it with authorities and stuff like that. If they're asks, if

they're asked, they will do that. These SDKs protect you against that basically. Now, there are two modes that uh NIM basically kind of offers, right? Um we have the use of the NIM mixet and this is a visualization of how a mixet works, right? So your every time your sorry I'll make this a little bit bigger. Um, basically that's your wallet on the on the left. That's your RPC RPC provider on the on the right. And [snorts] these blocks of these uh blocks of payload information here represent let's say a single signed RPC uh RPC uh something a single signed transaction

you want to send to an RPC, right? You know, you want to interact with a smart contract, you want to send a shielded Ethereum transaction, something like this, right? Now what happens is [snorts] that your kind of signed transaction will be broken up. In this case we're using uh into like seven packets. All the packets that travel through the mixet are encrypted in the sphinx packet format. So all of the packets that move through the network are exactly the same size and they're encrypted in exactly the same way. So you can already see kind of from the perspective of someone who either is running infrastructure or is just observing your connection that suddenly [snorts] you're not able to fingerprint traffic as easily. Everything that moves through it looks exactly the same. Right now, what you can also see from this is

that those packets that actually contain bits of your payload information are green. But there's a lot of gray ones as well. This is cover traffic. This is to basically stop um someone who's observing the network being able to go, okay, well, they're sending a transaction at this time. Maybe I can correlate that on the other end by saying, okay, well, this RPC provider received a transaction then, right? your your client, your NIM client in this case, your Ethereum wallet is integrated with the mixet sending traffic at an average constant rate. Okay, so it's your think of this always as hiding a signal inside the noise.

Every single one of these nodes which is passing all packets between them to get to the other side of the mixer doesn't know what's in it. They don't know if it's a real packet, if it's cover traffic. So they don't know the timing. They can't see what's inside it because it's encrypted obviously. [snorts] And at each of these tops here, there is a variable length delay applied to it. This is where the mix in mixet comes from. Okay? So think of it every single time you're shuffling a deck of cards and you can't tell whether those cards are real, whether they're [snorts] like part of a real transaction or whether they're just fake cover traffic. And this little diagram here kind of elucidates this properly as well. So no single part of the network can see both your IP address or the destination that

you're sending to, right? The RPC provider just gets packets from an exit gateway and then does with it what it will. So it can't see anything about you. It can't get any of this metadata that we talked about before. Um your entry gateway can just see that you're sending packets into the mixet but not where you're going. And [snorts] the mix nodes themselves don't see either of these things. All they're doing is shuffling packets around. Right? So if we want to do a quick comparison against maybe tour and a VPN, then here you can see the red eyes, the observers of the network, right? Say if you're just sending a VP is sending your

Ethereum traffic through a VPN, then your VPN server knows what you're who you're contacting and what you're doing and anyone who's observing both of those links can trivially deanonymize you at the networking level, right? It's not really giving you any additional protections at all. And even with to which you know until recently has kind of been the industry standard with stuff like this and there are a lot of wallets that do have tour as a as an additional network layer then [snorts] this doesn't really protect you either right you have an observer either side because they don't do any of the timing offuscation any of the uh anti-fingerprinting stuff that the mixet does you're able to follow packets through you're sending it through to but it doesn't really matter

right you can see what goes in you can see what comes out and you can correlate those two things pretty trivially Right. Um, again versus the mix. Now, let's put this into the adversarial position. Right? You have an observer looking at your entry. Again, they can see this random stream of packets going in. They can see random stream of packets coming out, but there's no way that they can correlate either of those sides. They can't link you and your transaction. The RPC provider can't link you to your transaction. Right? So, this is like a very high [snorts] level overview of the kind of protections that are offered. Um again this is more for your reference afterwards and [snorts] um so before I continue does anyone have

any questions about this because this is the kind of highle stuff that is good to hammer down before we jump into anything else. >> Yeah. >> Um the question for those watching on the recording was are we not moving the trust assumptions onto the mixet servers. So this is why this is important here this diagram right because in the centralized case yes the the trust is all in the VPN provider right to not sell your information it doesn't help with the observer here you're removing any trust assumptions that you actually have for the servers right because everything that leaves your wallet is in this um averaged but

randomly distributed stream of packets that look the same. So, let's say if you're talking to a malicious entry gateway, right? All they can tell is that your IP address is talking to them. They can't tell exactly what the timing is. They can't make guesses about the amount of traffic that you actually send, what you're sending because your client sends at a constant rate. And we'll we'll dive into this a little bit on the next page. [snorts] So, that trust assumption is automatically gone, right? This is from your first topic. these mix nodes, all they know is that they're receiving packets and they're sending them somewhere else.

Otherwise, there's not really anything that they can do with that information, is there? So, it's kind of by the design of the way that we send the traffic, we're actually removing a lot of the trust assumptions. Does that make sense? >> It doesn't. Uh so the question for the for the um those watching online how can the nodes tell the difference? The nodes can't tell the difference, right? All the nodes do in the case of get the entry gateways, mix nodes, not the exit gateway, that's slightly different, but these four layers here, right? They receive a sphinx packet. They unwrap the outer layer of the encryption and that sends that tells them where to send it

to and what to send, right? As well as a couple of other things like an HMAC to check it hasn't been fiddled with. But they don't they have no idea whether they're sending cover traffic to these empty flooded packets or whether they're sending real traffic because if they did then you would have to trust them >> that when you use a mixnet at least properly designed one. We've seen a few that are kind of sketchy. Um each packet gets its own a different route through the network, right? So maybe my packet goes to the top node on one layer, the

bottom on the next and the middle on the front and then the next packet and these two packets together could be like an image or a transaction because nim packets are like two kilobytes pretty small >> could go through like the bottom and then to the top and then to the middle. So like because each packet is sent individually, in order to deanmize a packet, a single packet, you have to control the entire path. And in order and and in order to deanmize most things or more than one packet, so you'd have to control multiple paths, right? So it's pretty hard. That's like harder than controlling like Bitcoin miners, right?

So you have to control like I don't know. I think we ran some napkin math and it was like it control like 80% of the network to reasonably deanonymize traffic. So the sphinx packet again the the user it's called called source routing they choose a path through the network by essentially downloading a network topology which is stored on a blockchain also on an API and different other ways. You basically do diffy helmans to each of the nodes. You then onion wrap the packets similar to tour but different than tour. Tour takes the same circuit for every buries it every 10 minutes or so and each packet goes to a different route. So on that level the

packets only know where it came from and where it's going. So the first layer knows kind of like who you are. They know your IP address. The second layer doesn't know your IP address. Doesn't know where you're going. And the third knows where you're going. So on that level it's actually quite similar tour but it's a bit it's quite a bit stronger due to the independent per packet asynchronous routing while tour is what you consider synchronous circuitbased routing. So sorry it's a little bit technical but there's a whole paper called the sphinx packet format which is uh which explains it and we've upgraded that to be postquantum what's called the outf fox packet format.

>> Yep. That's linked in the docs. Uh we've got another question linked in the docs. Yeah, all of the docs are linked from this website as well obviously. So, uh this is just the specific one for this workshop and every single page will have links to kind of both the reference documentation and the dev stocks. Yes. Just for educational purposes to like dive a little deeper on what you were saying about the that um that would exist with tour. Can you describe a little more what would be the necessary capabilities of the threat actor for what you said would be a trivial thing because I think there might be a difference between like a Wi-Fi coffee shop concern versus I don't know nation state.

>> Yeah. Yeah. Right. So this is where you have to think of um threat modeling itself and the different like levels of threat actors that you're actually engaging with. Right. So which is also you defend against them in different ways. So let's again let's use this kind of diagram up here as the reference point. Right? You might have it. Your threat actor might be that you just don't trust your RPC provider. Yeah, it might be a malicious RPC provider. This is not the that's not the case of what we were talking about there. That's just kind of someone who runs a malicious RPC node but doesn't necessarily have the capabilities to like watch different points in the network, actually own different bits of internet infrastructure, right? And for that then your threat model there is all you want to do is like IP unlinkability between

you and that malicious node. Right? So that's not really what we're talking about. What we're talking about is the kind of the level of threat actor, the kind of global passive adversary who [snorts] can actually own and monitor either huge sways of or basically every kind of like packet that's moving through bits of the network in virtue of the fact that they like own bits of ISP infrastructure or border gateway infrastructure or these kinds of things. Does that elucidate a bit more why tour did that's what this is why tour didn't address this model. People were like, "Oh, well that's crazy."

[clears throat] Obviously, when Snowden came out, it's like, "Oh, actually NSA does observe a lot of global internet traffic." That model seemed less crazy. But when you look at blockchain traffic, that model is extremely not crazy. Blockchain networks are actually pretty small. There's hundreds of full nodes, sometimes thousands for Bitcoin and Monero. And for like and a lot of traffic goes to a few RPC and light client kind of servers. I forget the stats for Ethereum because I haven't looked into it, but we just did a lot of work with the Zcash people integrating mixnets against Zcash. All there's like 16 Zcash RPC light client nodes. 16. Okay. For the entire network. So, is it possible

that a adversary can monitor 16 light clients? Of course. And how much internet traffic for Ethereum goes to Infuro? Well, probably a lot of it, right? So, I think this this chain analysis we already know model can uh monitor all of the Bitcoin network like that that that was revealed in I think 2015. And there's a paper by NIM researchers called the anonymity of peer-to-peer systems where we actually measure for I think Bitcoin and I forget um one other network. It wasn't Ethereum. I think it was Zcash. uh we measure like how easy it is to monitor a whole peer-to-peer network. And the answer is you just run a few nodes, it's

pretty easy statistically. So even if you're like, oh well then government or like Palunteer and NSA doesn't care. Like come on. Like we know chain analysis is doing this. We know TRM is doing this and it's I can do it like with small networks like the Zcash network. I we could look at Ethereum in more detail if you want us to. There was a there was also a um there was a paper a couple of years ago as well where people were um basically putting malicious nodes into the lib P2P mesh that was used for Ethereum consensus and then relatively quickly and you know relatively cheaply as well. This was a group of researchers doing this in virtue [snorts] of the fact that they were able to run a bunch of malicious uh lipb nodes. then you could actually

start to build up um based on the ping latency between different validators um what the IP address of those validators were and the key and like basically their public keys right so you're able to start kind of deanonymizing people in that way and that was [snorts] something that like probably with the resources of like the people in this room we could reproduce so you have to think of the different threat actors in very different ways the kind of highest level threat actor that the mixet is designed to protect against and kind of everyone underneath it is this global passive Sorry. >> Right. So, we're not just talking necessarily about like malicious nodes in a P2P network. Um, [snorts] but yeah, we're going to kind of speed up a bit as well because we're on the second page.

So, okay, we we've talked about NIM on a high level. We're now going to look at like a NIM client, the thing that's actually in the SDKs that you would integrate to use, right? So, most importantly, how a NIM client is actually different from an HTTP client, a UDP client. You know, we say client with networking and people kind of have this assumption, right? There are a couple of ways in which these clients [clears throat] are different from what you usually think of. An HTTP client is something that basically deals with the HTTP protocol. When you give it something to send, it sends it off for you and it deals with kind of all of the unwrapping, the TLS, everything underneath it. Nim clients [snorts] are slightly different. Okay, so this constant stream of cover traffic is the big one, right? [snorts]

As we talked about before, this is one of the ways in which the network or in in which NIM actually protects you from these kind of like timing based attacks and kind of obuscates when you're actually sending traffic into a network. Okay, so you're constantly sending these cover this cover traffic wrapped in Sphinx. And this little diagram here, this is kind of your app when it's idle. As soon as your client is on, it's sending this constant stream of traffic. So if you actually when you're actually sending something, let's say our application is busy now. As you can see, you're actually all you're doing is you're writing your, you know, Ethereum transaction to the payload of these packets and just kind of placing them into this con into this constant stream, right? They're sent out in the same order to the gateway, [snorts] but at

that point, they also get reordered, resent through the mixet, and then kind of reorganized on the other side, right? So, this is the this is one of the main kind of differences, right? You're constantly sending packets. Each stream is a bus on process with its own rate. So you're sending this constant stream of loop cover traffic through the mixet back to yourself through different nodes and you're sending your real packets as well. Um basically the other way is because of this underneath you know underneath uh in the in the client under under the hood sending doesn't actually necessarily just uh send it immediately nor does it necessarily wait for a reply. This is all stuff that I built into all of these SDK abstractions. So again, a big difference between like an HTTP client, right? It sends it into a

queue that's slotted in, sent off, and the way that we do replies, the way that we do anonymous replies as well. So obviously, if you're sending something through a network, it's kind of useless if they can't reply to you. But if you want them to reply to you, then presumably you have to give them your IP address. You have to give them some identifier. And then again, you've docked yourself. Why would you use a mixer in the first place? And this [snorts] is why we have something called SERBs, single-use reply blocks. So if you can think of this these multiply encrypted packets, think of them as envelopes, right? What you do is you actually I want to send you an RPC.

You're you're an RPC provider for this example. I want to send you something and I want a reply from you. I want to know that you've got it. I want to get the transaction hash back. I want to do something like that. >> [snorts] >> So along with my message that I actually send in the payload, I will send you a bunch of essentially pre-addressed Sphinx packet headers, a bunch of pre-addressed envelopes that you can't read. You can read the first hop back, but because everything else is multiply encrypted like onion routting, then you don't know exactly where it's going. You can write into you can write to the letter in it, but you can't actually read the address of where it's going. So we also have this anonymous replying scheme as well. So your client is kind of sending stuff out at a constant rate

and it's waiting for stuff to come back to it, but it's not kind of a request response pattern that a lot of kind of other uh networking clients are you know that everyone kind of has as a mental model. So that's the let's say highle stuff. Now [snorts] let's look at what integration itself actually means. We have lots of different packages at this point, all built for kind of different environments and all with different abstractions in mind as well, right? Because obviously this is quite complicated. A lot of application developers don't want to think about networking too much. So we've built a bunch of drop-in replacements so you don't have to um you the matrix here is basically a question of your runtime and

your approach, right? So where does your code run? What environment does it run in? And for your kind of desktop environments, your CLI, your server environments, we have a bunch of Rust stuff. Like I said at the beginning, we're not necessarily going to focus on those here because I think the main focus of the room. Actually, if I get like a show of hands for people who are developers and interested are people mostly working in a kind of like browser environment or like a CLI kind of environment. What's the temperature? Can I get some hands up for browsers? Okay. Got one, two, three. Okay. Well, and CLI kind of rust stuff. Okay, cool.

Nice. Okay, sweet. Okay. Um, sweet. I will keep doing the stuff on this because it's it's more fun to do it in the adversarial browser environment, but all of this stuff that's down here works in all of the other environments. It's great as well. Um, the other side is the approach, right? There is a question of whether you're communicating between two NIM clients themselves, whether you're talking to something somewhat analogous to like a tour hidden service, right? Or as [snorts] is often the case in especially blockchain applications, maybe you're talking to infrastructure that you don't own. Maybe you're talking to like a public RPC endpoint. Maybe you're talking to a peer-to-peer swarm, right? Someone that you can't

essentially ask, hey, by the way, can you run this other version of this software, right? You want to talk to the clearet internet and you don't necessarily want them to have to. You don't want to have to limit yourself to actually someone else that uses NIM, right? So we can provide for both instances. Um I'll call the NIM side like NIM to Nim this hidden service side. We'll call that end to end. And exiting to the clearet say you want to talk to I don't know a public Ethereum RPC. We'll call that the proxy mode. Right? And this is the usual pattern that browsers take right and we're going to go through couple of these packages.

um as well as how some demos for ENS and rail gun as well. Um on top of that we do also have a bunch of other stuff. We have some standalone clients. We have a socks client. Um and we also have some FFI bindings for Go C and C++ as well. And you can generate stuff for Swift or Cotlin. So let's have a look at the proxy mode. Right. Your proxy mode is essentially where you want to tunnel everything through Nim. Again, this is somewhat analogous to tour, right? You want to send something through an exit node, but communicate with something on the clear internet that's provided by a DNS. You know, you want to you want to do a DNS lookup. You want to get the IP address

and you want to talk to it like you usually would in any other instance, right? So, your mixet, your edge here is your exit gateway, right? And this your exit gateway is essentially the thing your destination will see that your you know the metam mask RPC will actually see as communicating with it itself. Right? [snorts] This one note as well this doesn't get rid of the need to do TLS or noise or anything like that. You need to do package like you need to do payload encryption because otherwise your exit gateway will be able to see it. But for a third party service like a blockchain RPC or an API, this is exactly [clears throat] what you would use, right? And we're going to go through that in a second about how you can use that from a browser. Um, one note as well, if you're for

instance, as we saw in the Zcash case where you need to sync a load of block headers first, this is a pattern that a lot of privacyoriented [snorts] um blockchain wallets have started doing, right? where you need to sync a bunch of block headers because you don't want to um essentially dox to your RPC provider which blocks or which address or which account you actually need to like update before you can broadcast a transaction. Then um we also have a two hop VPN uh version of this which is you can use to do your kind of bulk uh you can use use to do your bulk downloads as well. Um we have four packages for the browser. All of these are essentially three. The top three of these are

drop-in replacements for commonly used packages. Um, which means that you as a developer, you basically have exactly the same API and you can interact with them in exactly the same way. I'll show you in some of the demos. They're like 15 or 20 lines of shim code that you have to write just to get this in and that's the only thing you have to do. We have mix fetch which is a replacement for the browser's fetch API. We have mix websocket for both websocket and secure websockets. And we also have a DNS package as well. So this is a host name to IP resolution package through the mixet. [snorts] And what that allows you to do is essentially do um protected DNS through DO. So you do DNS over HTTPS and you send it [snorts] through the mixer.

So, this isn't to say that you can necessarily route absolutely everything through the mixet as well, right? Um, [snorts] because all of this extra privacy that we're adding does also give adds some latency and it kind of throttles the throughput of what you're able to do. So, [snorts] when you're integrating, you have to ask, is it something that actually identifies you, right? Are you sending HTTPS? Are you sending secure traffic already? Um, is this something that you need to have immediately? Is this something that a user waits for? Right?

Is this something that actually blocks your application before you get it back? Can you run it sequentially? And also, can your code actually control its transport? Sometimes you're using like third party SDKs and all of this stuff that have their own things tied in. Okay. Um, this is all maybe a bit too in the weeds. So, we're going to move on to we'll skip censorship resistance and we can go straight to some of the demos and we can actually look at how this is going how this all actually works. All right. So, this isn't a mockup. This is actually all happening like in this browser window. You can follow along as you want. [snorts] And what we're going to do is we're actually going to open up the networking console and reload the

page to actually see this. So this is all just all of the documentation page actually loading right we're going to try and connect to an exit gateway. So if we pass these and what we can see here that's happening right is we can see that we're actually making a websocket connection to an entry gateway right so we're doing our request that's being that's being upgraded to a websocket connection and [snorts] we now have a solid tunnel through the mix.

What has actually happened on the other side right which you can see here is that actually we've been we've connected to a service running on an exit on an exit gateway and we've actually been allocated two IP addresses. We've been allocated an IPv4 address and an IPv6 address. So now from the perspective of everyone we want to talk to through that those are the IP addresses that it's coming from. Right? So we're we're all good there. We have our tunnel set up. And now we're just going to do if we look at our networking tab again, right?

From the perspective of our website or from the perspective of this website, this web page, then nothing is going to happen because everything is going to go through this tunnel that we've just made. Right? What we're going to do is here we can see that actually we've started our request. We're trying to resolve the IP address of example.com. We are making a TCP connection to 9999 which is just the pre which is the DNS endpoint that I configured for this.

We're sending a bunch of packets. Right? So this is an abstraction that looks [snorts] and acts from the top like a TCP uh just like a normal TCP IP stack. We're sending IP packets through the mixnet. We're sending a normal get request again tunneling it through and we've reached the 200. Okay, so that took us 7 seconds which is quite slow but the next time we do this then because it's cached it's only four, right? But what we've actually done in this little example here, if we go back to here is through sent tunneling all of this through the mixet is we've actually made a connection from your wallet to

this exit gateway. We've done to and then we've done a TLS handshake. We've sent that through and then we've actually made a request to our DNS server and that's responded to us. Right? All of this without that DNS server learning anything about you at the network level at the network level. All of that has been protected because we did uh DNS over HTTPS. Then the DNS server also doesn't necessarily know what you're even asking for. Right. Any questions for that? Great. Cool. Um let's go back playing around.

So we've got a tunnel. We're already using it. Um, and basically what you can do is all of this stuff, all the code is here and you can do all of the same stuff that you usually do. You can do get requests everywhere. You can set up a websocket connection. Um, there's a stress testing thing and then there's also kind of file downloads as well. All of these have exactly the same API as um as a normal fetch or websocket connection right? So we can also set up we can connect a web soocket. We're just going to connect to various echo servers here. Um and we can step through again. We're going to do DNS. We're sending IP packets through.

We can see this. Oh no, our DNS request failed out. Um let's try a different one. Sorry. Curse of the live demo. Um go. We're going to connect. Going to send our connection handshake. We have a stream and we're ready. Perfect. And then we can also do stuff like fetching text. And for all of this, we're doing everything that you would usually do. We're just tunneling it through the mixet. So, we're tunneling normal TCP IP traffic through the mixet, performing TLS and all of this kind of stuff.

um we're able to perform TLS without your browser actually knowing about it because we have bundled all of this into the WA and blob itself. Usually browsers are a very very adversarial environment in the sense of like trying to do anything fun with them because they don't give you access to the certificate store. They don't give you any real access to like do your own TLS. All of this is like handled for you by browsers. And it's usually for a good reason because that's kind of security stuff that's built up over the years to stop people banning the middling or being able to kind of run kind of bad scripts on websites and do anything kind of dodgy with them, right? We're trying to we've had to try and get around that in interesting ways. So what we've done is actually in the W in the web assembly

blob, we have the Mozilla certificate store which is bundled into it. So your browser doesn't know your browser window doesn't know that you're doing any of this. It doesn't know that you're making these DNS requests. It doesn't you're not accessing a certificate store. You're not leaking any of this information to your own browser and any for instance like dodgy extensions or anything that might also be running in that browser as well, right? Everything is happening through this encrypted tunnel that you're sending [snorts] through the mixet. And yep, these are just file download examples. So now let's do an example where we look through how you can integrate this with ENS. And again this is all actually happening in the browser window itself.

Right? So this is the only code that you actually have to write to use mix fetch instead of using the normal RP JSON RPC provider. are using the HTTP library that um Ethers, which is just the networking library that ENS uses, actually wants to use, right? It's these lines of code and [snorts] importing mix fetch that will allow you to essentially use mix fetch instead of using your browser's fetch API, instead of doxing yourself directly to whichever um RPC point uh or the PCP node you're actually talking to when you interact with the ENS. Okay. Um all of this code

is linked from this page as well uh in components demos and EDS. So you can check that out after the uh after the after this. Right now let's again do it. So we want to connect to ENS. We already have a tunnel up. So let's connect to Vitalic. Right. First we need to resolve its address. So as we can see here we're building a JSON RPC provider. This is the RPC endpoint that we're actually going to be talking to. So, we're going to be talking to this this one here. Transport is using mix fetch. This is just using this code that's running in that window. So, if we open up the networking tab, then

hold on. Sorry about internet. Our DNS resolution is timing out. So, we're going to round rob in the DNS resolution and try that again. Okay, we have our websocket to the entry gateway open. We're sending our handshake and Okay, great. There we go. Let's resolve. Perfect. So, we obviously got a slightly dodgy internet connection there for a moment. So, we managed to do TCP

to our DNS server. Okay, so we've got that. We've got the name. We're getting all of these packets. We're sending a get request. We've got the get request as normal. As you can see, you can step through it. These are all just very normal. Um, all you're doing is tunneling existing protocols through the MixNet tunnel. So now if we kill that. Okay, great. So now we've actually interacted with this IPFS gateway again using only the code that's on this page. We've actually got the result. Okay, so we've resolved the address. And then we can do the same with getting the content hash. Now this this one is happening a lot faster because we've already done we've already performed TLS with the endpoint that we

want to do. So we've removed some of the RAM trips that we had to take through the mix there. Right? In this instance, we've already got T. We've already performed TLS. We've done the handshake. They know who we are. We know everything that we need to do. So, all we're doing then is actually just sending this request saying, "Hey, what's up? This is the address of the resolver. Could you please give me the IPFS hash back?" Right? As because that took 3 seconds and the one beforehand took 15. And then we can just fetch it from IPFS. So this one will go slightly slightly slower as well because we're again having to perform TLS and actually do all of this other handshake stuff that we're having to like tunnel through the mixet. Right? So anything that has this back and forth and this is something

that is where the kind of the orthogonal relationship between the way that the internet has developed and then trying to do network level privacy kind of appears because everything that previously you imagine took you know nanconds or milliseconds you're having to t you're having to send through whatever tunneling protocol you're using. Um but oh okay the IP [laughter] the IPFS endpoint it's got too many requests. Um but we did actually get a response to it. So let me try that with another which is not an US problem that's an IPFS problem. So let's switch to rail gun. Um this again is how you would patch it. Right. All

we're doing here essentially is just patching the um we're just giving a patch in this case a global patch to ethers which is the networking library that a lot most Ethereum wallets use and we're just saying by the way in this instance please whenever it says get URL use mix fetch instead of the browsers fetch right and there's an there's a longer explanation here um you do have to do a little bit of pinning with this but this is something that like especially with agents now is relatively trivial.

Um you can try this out as well. We're going to use the tunnel from our other page. And now what we're doing is we're actually initializing our rail gun engine and deriving [clears throat] the shielding address for the pneummonic which is also loaded in this page. Obviously in production never do that but this is a demo and I didn't want to have to constantly copy and paste stuff in there. So you know um also it's holy it's and it's support here so it's fine. Um the rail gun one takes a little [snorts] bit of time. So if anyone has any questions whilst this is running then now will be a good time.

what's preventing a malicious mixnet server from selectively dropping uh the packets uh which could eventually you know affect the uh application package. >> So um the way that the topology of the network so the way that the actual set of nodes which are up and mixing at any one time right is decided is partially based on performance metrics and it's partially based on reputation. So this and this topology changes once an hour, right? So you can imagine that like as you know if I want to be a malicious mix node then yes I could just like randomly drop packets

in a short amount of time then yes you could kind of cause a bit of chaos in terms of like you could you would then force clients to essentially like resend packets using a different route. So they would route around you. you would be adding latency to people. Um, but this would only work for a small amount of time, right? Because then you cuz you don't know which ones are like application specific ones or you know you would be applying this kind of like generally to either all of the packets or like across all of the packets that you would be receiving. Some of those packets would also be like performance packets, right? Ways that we actually monitor. Okay, well like how good is this mix node? [snorts] And that would mean that in that would then affect your

overall kind of performance rating and it would mean that like you're then less likely to actually get selected to mix afterwards. [snorts] Now operators of these nodes also do get rewarded for doing the mixing as well. So apart from the fact that it's kind of econ like economically you're um incentivized to operate as well as possible and people we have a delegated stake staking scheme as well. So you're, you know, economically speaking, you're taking a hit, but then also you, your node would perform badly, so people would destroke from you. So you'll be even less likely to be involved in mixing. So over time, you wouldn't necessarily be able to perform this attack. You could do it maybe once or twice but yeah >> so it's basically a slashing mechanism in place where uh you're required to

stake and only then are you allowed to be a mixet node and then you uh >> yeah it's kind of like an implicit slacking slashing mechanism like you don't slash anything that you've kind of bonded. It's not like an escrow slashing mechanism where you put something up and you lose it but you would be less likely to be chosen to mix. Therefore you would like kind of stop the ability to get rewards in the future. Yeah. >> And uh just one last one. Uh so where does the indistinguishability between the u loop uh covered traffic and [snorts] the application traffic end in the sense uh all of those packets reach the exit gateway and from there it goes to the application. So can uh

>> so an observer can he not correlate from the exit gateway to the application and see uh which one is the loop cover traffic and which one is application you're only sending the loop cover traffic inside the mixet right so it's only application traffic that will ever leave the exit node right so the so an observer if you're kind of using the proxy model which is I'm going to send my DNS s request to this service that lives on an exit gateway and then that's going to for instance like make a DNS request for me then the observer can see that little hop it can see that this exit gateway is interacting with quad 9 or cloudflare or something like that [snorts] in the other integration model then which is where like a nim client to

a n client you also get rid of that right so say if you set up a DNS service or an RPC endpoint or something like that which actually had a nim client integrated into that so could kind of be used similarly to a hidden service then [snorts] all that they would see was swings packets traveling end to end between these two things. You wouldn't actually then be able to tell anything else about them. So that's kind of the distinguishing factor there. That does from an integration perspective mean that you kind of have to you know this is that the service has to integrate NIM there whereas the proxy model means that you know we we were interacting with like public IPFS gateways there. They have they don't need to have any knowledge of them. They don't need to

know anything about it because your exit gateway is essentially acting as your proxy in the same way that like a tour exit is acting as your proxy. Um any other questions? We have like two minutes left. Nope. Okay, cool. Um sorry. So when I was doing that then basically right so we've actually interacted with we've made our RPC request. Uh the [snorts] first one failed but that's okay because it retried it. And we have derived our shielded address from there. So then what we can do is then we can do all of the normal stuff that we want to do.

This is exactly the same as how we were interacting with ENS before. We're building a JSON RPC provider. We're talking to this Solia RPC public node and we're using mix fetch as a transport. So again, our browser window has no idea that we've just sent these requests out of it and to that mix node and to that endpoint itself. from the perspective of your browser, you made a websocket connection to an entry gateway and then you didn't do anything. Nothing has happened, right? Which is kind of cool. Um that you can lie to your own browser. We've done just a normal ETH get balance and we've actually checked what our Solia test net is, uh our balance is. And then we can do the same with shielding. Um we can step through it again. We're actually doing [snorts] all of the stuff. We're signing this the

key derivation message, estimating our gas. Again, we're using mix fetch. We've just got the transaction hash through. That's all fantastic. Broadcast happened on on attempt number one. And then all we're doing now is waiting for our receipt. And then we will have just shielded a bunch. We would have interacted with the rail gun uh smart contracts. There we go. Boom. And we've actually just shielded some polio and it will give us a transaction hash back and we can actually verify that that's on etherscan. Um yeah, I think that's maybe yeah, we have two minutes left. We didn't get a chance to go through the latency and the limits. Um but this [snorts] is um some deeper explanations that like people who are interested can look into.

So why the mix now actually adds latency itself um what we've measured as well. Um and then I'm going to for the last minute I'm actually going to talk about a nonRPC too. So, a nonRPC is actually an EF standard. And this is basically an EF standard for being able to load um something like MixFetch um or something like RT, the tour uh web assembly client into a browser window and do that in a verifiable way. So, what it basically does is it makes an RPC request to a particular um Ethereum address. That Ethereum address holds basically just a

a hash of the bytes of the HTTP client that you're going to be pulling in. You then pull in the HTTP client from somewhere else, either from a CDN, from GitHub, or you can actually pull it using KPS from a um from a KPS node as well. So that's a way that you can do it without any certificates or anything like this. And it [snorts] will essentially verify that the thing you pull in has exactly the same bytes as the stuff that is in the smart contract. So it's kind of a semi it's a adding a layer of uh bite- checking verifiability to um pulling in whatever you want to use as your anonymous client. You don't need to configure the worker or anything. It does all of this for you.

And then basically that's another way that you can um also pull in mix. Um, this you can use in a bunch of Ethereum wallets now and kind of just does everything for you under the hood that I was showing that you had to kind of do manually with the 15 or 20 lines of code to patch ethers in the instance of ENS and Rail Gun. Um, I've just hit time. So, if anyone else has any final questions, then please ask them. If not, thanks for coming. Oh yeah. Oh yeah.

Yeah. We have uh free month VPN passes over here as well if anyone wants to actually Yeah. They're all laid out on the table. Please just take them. >> [music]