BSidesCharm 2025 - Beyond Tor and VPN: Protect Your Privacy With Decentralized Mixnet - Alexis Cao

[Music]

All right, I guess we'll get started. Um, this is a really big crowd. Thank you guys for coming. Yeah. [Applause] So, just to introduce myself. Hi, my name is Alexis. I'm currently a senior at Johns Hopkins University studying computer science. And um today I want to share with you guys a topic that I have been really passionate about. And as you can tell from the title, it's about mixnets. So before we get into all the cool things and all the technicalities about MixNet, um I want to share with you guys a little story of my first time running the mix node for the mixet that I'm going to talk about today. So back in 20121 I this my first time got

interested in all the privacy and cyber security stuff and uh I remember I would just like come back home after school like googling stuff and then find some like new cyber security tools. I would download and try them out and then one thing leads to another. One day I stumbled upon this thing called Nim. Um, back then in 2021 I didn't have a lot of experience and they have this whole guide of like setting up a node to how to be like a node operator to run the mix node. Um, eventually I figured it out and I was like so happy. So I took this photo and uh, little did I know back then that four years later I would

be doing all the things that I'm doing right now and to be able to have a talk on this. And uh for all those of you in the back that couldn't see the date, um it's 2021 April 17. So it's almost exactly four years ago today. So this was like a really special talk for me. So there you go. So to help build up the concepts and ideas of a mixet, um let's start with some basic concept of how a VPN works to help it build up to that decentralized um mixet. So basically when you have a VPN, you have the VPN client on your phone or on your desktop. Let's say ProtonVPN for example. When you connect

to the VPN, you're essentially establishing a connection with the VPN server through the internet key exchange and that VPN server helps you to route your request to the internet and how packets are encrypted during this process. So for an user you have an IP address for the website you want to visit and then you have a payload let's say like a message when you connect to the VPN client the VPN client helps encrypts the IP packet to the server to the payload the whole payload and attaches the server IP on the top of it and then the VPN server when they get the payload and the whole packet it decrypts the server it decrypts the whole payload gets the web

IP and to send the whole thing to the internet and the problem problem with a VPN is um that you're putting a lot of trust in the VPN server. So essentially you're giving all of your data to the VPN server. It can see your web IP address. Um it can see what website you're visiting. It can see a lot of things. So there are a lot of sketchy VPNs out there. So not the best idea. So to move on from the VPN, moving on um to the mixet, we have tour. So for how tour works, you have a tour client and then you have entry node, relay node, exit node, and you have the internet. So

basically we're routing through three different layers and a little bit better than the VPN than just having one. And how packets are encrypted in this process is that in the very innermost layer you have the web IP of the website that you want to visit and the payload and then on top of that the next layer you include the exit node IP addresses and then on top of that you include the relay node IP addresses. So when you use the tour browser, you connect to the tour client. The tour client creates this whole packet. It sends it it gets an IP address for the entry node, send the whole packet to the entry node. The

entry node decrypts the first layer, gets a really node IP address, send it to the really node, and then really node decrypts one more layer. See the exit node IP addresses, send it over to exit node and eventually gets a website IP address and send it to the internet. But why not tour? I know tour is a very private and secure option and whenever I go to conferences people give stickers like use signal use tour. Um but just to play the devil's advocate here um there are some attacks that's related to tour. For example for an attacker that controls an exit node and an entry node. They could do time analysis to analyze the traffic patterns

to do anonymize packets and also many other attacks. But that's not the only reason. The problem with tour is that there's little incentives for operators to run nodes because in a mixet you want a diverse amount of nodes. You don't want a few nodes to control a large amount of traffic. So imagine attacker to control a few nodes. They're able there just have a more likelihood to deanonymize your traffic. But at the same time, when you want to give people rewards and incentives for running node, you don't want an infinite amount of people running nodes because that would just lead to the case of a bad actor introduced an infinite amount of nodes into the network to lead to a civil

attack or to just take down the whole network. So at the same time with the incentives, you also want to add some costs for running node. For a node operator, you need to put a certain amount of money when you first start running a node to have both incentives and cost to make sure a stable network. So beyond the tour, there are many other decentralized mixets in development right now. And today I want to focus on one of them. Um it's a NIM mixet. So basically this is a graph that I got from their white paper. Um just to briefly go over their graph, you see you have the user on the left. Um and the

key infrastructures includes the validators, gateways, entry gateway, exit gateways, the NIM mix nodes in the middle and then you have the NIM blockchain and the ultimate service provider that you're connecting to. So how it works is that let's say you're a user and then you want to use this mixnet and what you would do is first of all you would deposit a certain amount of tokens and then you after depositing to the blockchain you get a proof of deposit you send that deposit at a one the number one label on here to the validators which controls the blockchain the validators then check with the blockchain to see if you actually deposit that amount of money. If the

check comes back correct, it gives you a certificate. Certificate for bandwidth and certificate for service. The bandwidth just indicating how much data you can use and a service just indicating what service you can use. And then when the user now getting all the certificates, you can actually connect to the mixet. So the user sends a certificate of bandwidth indicating how much bandwidth and data they can use to the entry gateway. The entry gateway then sends a certificate to the NIM blockchain to check if you actually if you actually um if the certificate has not been spent. If it returns return from the gateway if all checks were correct, the gateway then starts to route your traffic through three layers

of mix nodes. And then after routing through three layers, it sends to the exit gateway and the exit gateway sends to the service provider or it could just be another user also running this mixnet. So to simplify the graph that I had before, you can essentially imagine there's a client, an entry gateway, three nodes and an exit gateway and a destination. And one of the core features that it does other um that's better than tour is continuous time mixing. So basically what it does um is when you have tour when you send a packet from node one um for an attacker monitoring the traffic at note three they may be able to do time analysis or

timing correlation because packets are not delayed. So for continuous time mixing how it works is that let's say you have two packets packet A and packet B and you send the packet A before packet B and at note one when note one gets those two packets it doesn't necessarily send A before B just because you send A before B each packet is delayed for a certain randomized amount of time before they send it out. So when you send packet A before packet B, it's very likely that packet B might send before packet A or packet A might just send regularly. So there's really harder for attackers to tell which packets correlate to which. The next core feature of this

mixet, it's called cover traffic. So previously for tour we're only um accomplishing unlinkability which is essentially saying that for an attacker we don't want people to see what services were accessing but still for an observer of the network they're still able to see um they're still able to see that you're using the network and we don't want that and in this case we want unobservability which is essentially saying that we don't want attacker to see if we're sending any data at all. So basically what it does is to use cover traffic. So as soon as the client connects to the mixet even if you're not sending any requests, you're not sending any packets, it's generating random

packets as cover traffic to send that through the mixet because you're all encrypted in a sphinx packet format. You're not able to tell if it's a real packet or it's a cover packet. So, it's really harder for people to tell um to link to first to not link the services you're accessing and two to not be able to tell that you're even using a service in the first place. And the third thing that the core feature I want to talk about is a layered network topology. As you can see here, we have three mix nodes in the middle. And how the three mixed nodes um are layered is using essentially using a verifiable random function. Every epoch

time which is 60 minutes to rerandomize all the nodes in the network to the three different layers. And what it does is a validator in the network will generate a random value X send that value to the blockchain which the blockchain will then broadcast that value to all the nodes in the network and every nodes has a secret key. It uses a verifiable random function to use a secret key and that random value X to compute a value Y and then to do mod 3 which gets the layer that it should be on. And the reason for doing that, one of the reason is that for an attacker, you don't want them to purposefully to

position a node in one layer because that just would make it easier for them to uncover the traffic because to see what services someone is using. You essentially want to control all three nodes on the path to be able to deanonymize the traffic and by randomly reordering the nodes to different layer every 60 minutes, it makes it harder for attackers to do so. And the next thing I want to talk about is this special packet format that this mixnet uses to encrypt a packet. So at the very high level um every packet has a header and a payload. The header is encrypted using the AES counter mode and the payload is encrypted using a white block cipher. So

essentially when the client is about to send a packet, it construct the sphinx packet format. At the very innermost layer, it has a destination IP address and then it has a payload. And on top of that, it adds a header of the exit gateway IP and then the node 3 IP, the node two IP and the node one IP. So the client creates a whole packet and send it to the entry gateway. The entry gateway decrypts the first layer to get the node one IP addresses. Send it to node one. Node one decrys one more layer. Get to node two IP. Send it to node two. Node three. Note node two decrypts one more layer. gets a node

three IP and then send it to node3 and then get the gateway IP send to exit gateway and eventually routes through destination. So, one of the ways that Spring's packet format does to prevent attackers messing with the headers or payload is using an HMAC integrity check, which takes in the cipher text of the hider of the header and also the shared secret key with each note to compute an HMAC as integrity tag. And for every note when they receive the packet they first check if it if the integrity tag matches and if it doesn't match it drops entire packet just to make sure that people don't miss mess with the header or the payload. So another feature that I use

is anonymous replies with singleuse reply blocks. Essentially it's just one of the blocks at the end of the message that says I am the sender. This is my IP. I want you to send a reply to that IP back to me. And that creates some problem. It's a very useful feature, but it does come with problems. So, one of the known attack with single-use reply blocks is that let's say you have a client A and a client B. And the client B it's it's an attacker, someone that wants to do damage. So, client A send messages with single-use reply blocks as usual. And the client B in this case used for used the reply blocks to

request A to send more and more single-use reply blocks. So client A saw the request thinking that they need more space for their reply. So they send out more. And then at this point when client B gets a large amount of reply blocks, it sends back all the accumulated single-use reply blocks. And by doing so, they can monitor the entry gateway traffic permutation to find out which one A is using. And the next feature that I want to talk about for this decentralized mixets is called verifiable localization in decentralized system or for short verlock. So previously um a lot of the verification for location has problems because it's using a trusted landmark. So if an attacker wants to attack the

network, they can just proof they can just spoof the landmark to to mess with the location. And what this does, what Verlock does in this case is to verify nodes are where they say they are without using trusted authorities or landmarks. And to simplify this, basically what it does is to measure the internet round time between a node and a set of pseudorandomly chosen reference node and to infer the distance from the time measured. and those set of pseudorandomly chosen reference node are optimized during the process to make sure that the landmarks or the trusted authority or the central measurement is decentralized. So how can you actually use it? So at the moment right now

there's a VPN client that you can actually use and there are two different modes um for this VPN client. As you can see for the photo on the left, it's the wire guard mode, which is just like any other VPN you're using. Nothing really special. And you can choose your entry and exit gateway. For the photo on the right, you have the anonymous mode, which is essentially routing the traffic through the mixet. You can also choose the entry node uh the entry gateway and the exit gateway, but you don't get to choose the mix node. client will randomly pick one node um from the three layers and build a path and route your traffic through

that. So how do you actually pay for something like this? Obviously um you can just pay with regular dollars but in this case um there's this ecosystem as tokconomics which is basically you get to be a node operator. When you get to be a node operators when you run nodes you get tokens as rewards and then you can use that tokens to use your service as a eventually to access the mixet. So in this tokconomics we have basically three key things the stake node operators and delegators. So as a node operators, anybody can be an operators as soon as long as you can run nodes. And what you would do when you want to run a node is that you would put

a certain amount of stake first before you set up a node as a measure to prevent civil attacks. For example, many many bad nodes setting up um in the network. And um for delegators, what they would do, they're essentially like investors. they have lots of tokens and uh for every node that they think is performing well, they invest your tokens or stake to the note operators and by investing those amount of tokens. So every time that a node operator gets some rewards um from running a node, the delegator share part of the profit. And so for when you're running a node, you want your node to be actively selected to get the rewards. And the

selection probability for this is to stake times the configuration score times the format score. And the last two is raised to the power of 20. So for configuration score essentially measuring if you accepted a terms and condition and what version of mix node you're running because the goal is to essentially we want to encourage people to run mix node on the very um the latest version and the performance score is just um a network monitor sending test packets to see like um to see how packets are performing and essentially measuring the uptime that a node is running. So it comes with problems with um this makes sense. It's all like a lot of nodes, a lot of mixing and latency is

a big issue here. As you can see from slides ago, um you have on the right side the anonymous mode. He says best for payments, emails, and messages because um when I try to run this, the latency is actually um sort of an issue um that wouldn't necessarily be the best for browsing, but for things like payment or maybe crypto um crypto transactions where a little bit of latency would be less than an issue um it's best for those situations. And there's a lot of ongoing work in this area of how to minimize the latency for the mixet while not decreasing the privacy or the performance of the mixet. Um there has been some research into

like um like lightweight approaches to do something like that but still to make sure that both we have both the um to make sure that we have to reduce the latency while not reducing the privacy. It's still something um that um we could look into in the future. So I guess that sums up with my talk and uh if anybody has any questions. So yeah, thank you. [Applause] So I just did I speak out? Yeah, sure. Go ahead. So uh Alexis, right? Yeah. So Alexis, thank you for the presentation. I had two questions that came to mind. The first one was on configuration when it came to I didn't know if I was okay. So, um, when it comes to

configurations, the wire guard, is that something that you can, uh, configure your own server to leverage because wire guard is the protocol or does it automatically use NIM's configured servers for WireGuard? I think it's using the nymph servers for now because for um the client we actually use it there are not a lot of um configuration options. So that's the one that you can that's just a default option like it doesn't give you many options to um to like change the servers or like cher protocols. So yeah. Okay great great. Um my second question was about uh talking about tour early earlier something that I learned a long time ago and I live by is that you never want to

register your node as a exit node but I saw you mention kind of exit nodes here as well. Is there a layer of anonymity that we can um when it comes to offering our node up as an exit node or do is that an option when you set up a node? Are you saying, "Hey, I want to be a regular mix node. I want to be an exit node." I'm not familiar with that part of it. Right. So, basically for NIM mixet, there's not essentially an exit mix node. There's an exit gateway. So, for the gateway um you can run as a gateway, but that's um sort of on a different structure as the mix

node because um as you can see here um you have three mix nodes in the middle. So, like those three the last one, the node three is not essentially the exit node. So, um, it's a like a it's like a sort of a different feature than tour. Okay. Thank you. I appreciate Yeah. Oh, go ahead.

Uh, uh, hello. Just want to also uh just start off by saying I enjoyed the presentation. Thank you. Uh, but I wanted to first ask for the blockchain part of the uh for NIM. I was wondering uh particularly sorry if you state it before what are it's verifying the transactions but what what is stored on the blockchain and can that information be backtracked and how does how does that all work with I see so basically for what the blockchain is doing right now um is storing the payment information that users made and also just all kind of essential informations that they need to broadcast to nodes on the network to make sure they're running properly. Um, so

basically I think it's using something called Cosmos. Um, I'm not sure about the backtracking to like get your information from blockchain, but I don't think there has been any attacks found for like getting your information from the blockchain. But essentially what blockchain does is you are depositing your money to a n pool which is like a wallet that um runs on the blockchain and then the what the validators or the gateway will check um if you actually deposited money before you connect to the mixet. Okay. And then my last question to kind of be the two parts to it would be the first of like has there been any uh papers or active research within like formally looking at NIM and

particularly are there any issues with attacks on validators and the validator system, right? Um so for the validators um the the issue with the validators is right now at the moment not anybody can sign up to be a val to be a validator runner. you have to send an application to them and they will need to like I think there's like a wait list or something they need to verify your request or this is something that I think um you need to be vetted to be a validator runner. So I don't think that's something that anybody can sign up because if that's the case um that just could like create a lot of problems for attackers um trying to be the

validators and I think there are like research papers on this for example like this paper is from their white paper. So yeah. Oh, hi. Uh, great presentation. Thank you. I had a quick question. I was wondering uh cuz there is a blockchain component. It seems like money is being exchanged. What kind of cryptocurrencies would be supported? Would I, let's say, if I wanted to use this be able to put forth money using Monero? Uh, would that be feasible? So, you mean like what cryptocurrency this it supports? So um basically it has their own tokens which is um the logo here. They have their own NIM token. Um it's something that you could buy on the crypto exchange

platforms and also there something that you could get from as a reward for running the note. So that's just their tokens. Gotcha. I figured it was something on their own but want to double check with you. Thank you. Yeah. Um are we running Okay. Uh I guess we'll take uh we'll take uh questions. Anybody I just wanted to ask the what's the minimum resources to run a node? Are you aware the minimum resources? Um so basically you need a VPS to run the node. Um, and that depends on like I think around maybe like 4 GB of RAM and like um around like maybe like for now I know people running for like maybe like

$20 a month for the VPS, but um it's not a lot of resources. It's not designed for you to cost a lot of money to run the nodes. Yeah. Hi, I was just um curious like who runs the gateways? Like can we sign up to run our own gateway node or is it all ran by NIM? Yeah. um you know you can anybody can set up with running the gateway. So essentially when you're running a node you can declare your role as either a mix node or as a um gateway. So it's just something that you declare as at your runtime. So yeah anybody can do that. Oh go ahead. Is there any kind of

security protocol in place to prevent a node from saying uh rerouting traffic back through myself more often to demand more tokens? Like rerouting like as a node runner. Yeah. Can I reroute traffic to say I'm running more and therefore I need more tokens? Sorry. What do you mean by like rerouting? like well I could force is there anything to prevent myself from forcing you to use me for all of your next notes? So basically the reason that I think would be really hard for you to force someone to use your node because um the client randomly chooses a note you don't really get to say like if you get picked um and also at the same time

the nodes even if you did get a node to choose you um it's reordered to different layers every 60 minutes. So you really don't get a lot of say in that. So yeah, can the gateway bias that? Can the gateway only publish? Can the gateway bias that by only publishing a small subset of the nodes thereby forcing you to pick from? What do you mean gateway publishing a node? When the gateway helps the user connect to the nodes as the as the man in the middle and they uh perform a um I can't remember the name of the attack, a subset attack. the gateway is that not possible in this protocol. The gateway doesn't, if I

understand your question correctly, the the gateway doesn't necessarily um help the client um pick a node because um that's something that client could choose. Um but also at the same time um it just like the client chooses the node. You have to some sort of a like manipulate the client to control the exit gateway. I'm just speculating on ways that you could manipulate the client to I see. I guess it could be. Yeah. like anything I can do to falsify what my secure score is. So that the probability of me having my node tick is to the 20th power. If I could get that secure score higher by saying I'm more have a better performance that like

now I'm more easily randomly picked, right? I guess. Um, but that just depends on like how you would go about like doing that because um like right now like it's measured on your uptime. So it's like pretty something that's like um so that's something that still depends on like a lot of factors and variables involved. So yeah, also I guess we're u running short on time. So um if anybody has we can take one last question.

Okay. Oh, go ahead. Do you see some VPS's trying to crack down on this if they discover that's what's happening? Sorry, what's what's the what's the first part of the question? Just that if a VPS starts seeing that this is how you're using, have you heard of any VPS's the actual like company being upset and trying to stop this kind of service from happening or can they detect it? I have not heard of anything like that um like this so far. So yeah. So any more questions or Okay. Um I guess we'll wrap it up then. Thank you guys so much for coming today. So thank you. [Applause]