Nym and NymVPN - Next-gen privacy with mixnet and VPN service

ania · March 27, 2025, 12:00am

Thanks for raising your points @SaltyYogurtt - appreciated! Just to help clarify a few things from my side:
As for DAITA, as I mentioned in my previous post, we looked at it when it was first announced. And yes, you’re absolutely right – it’s based on the Maybenot paper, which I personally think is a great piece of work. Our analysis was simply based on their open-source codebase. It’s all publicly available, and anyone can inspect it. That’s how we saw which state machines were used and how they were implemented, here for reference:

github.com/mullvad/mullvadvpn-app

talpid-wireguard/src/wireguard_nt/daita.rs

e3d696372


      
              resource_dir: &Path,
              daita: Session,
              peer: PublicKey,
              mtu: u16,
          ) -> std::result::Result<MachinistHandle, Error> {
              const MAX_PADDING_BYTES: f64 = 0.0;
              const MAX_BLOCKING_BYTES: f64 = 0.0;
          
              static MAYBENOT_MACHINES: OnceCell<Vec<maybenot::Machine>> = OnceCell::new();
          
              let machines =
                  MAYBENOT_MACHINES.get_or_try_init(|| load_maybenot_machines(resource_dir))?;
          
              let quit_event =
                  talpid_windows::sync::Event::new(true, false).map_err(Error::InitializeQuitEvent)?;
              let handle = MachinistHandle::new(&quit_event).map_err(Error::InitializeHandle)?;
          
              let framework = maybenot::Framework::new(
                  machines.clone(),
                  MAX_PADDING_BYTES,
                  MAX_BLOCKING_BYTES,

github.com/mullvad/mullvadvpn-app

dist-assets/maybenot_machines

df5128939

02eNptjLsNwCAQQ++yQRZImTJlRIfYBDEJA7ERJQtQ0iC+dxSIJ1mWLcv5TsLH9wMmF4KLqwkRAawk2yPR00CHX3V3j1GziWvE09NBBWg9Fjk=
02eNqFjLENwCAMBP8hC2SJlKnTsVr2zBKUaVACNgiBEJxknex/Oezv9fjjRCF8mXLY4pAEbpeFJFlFqJBGA7PqWQ3spCer4l3rnvGDH6+FGlE=
02eNqFjDkOgDAMBL056PkEJTVdvsY/+URKmojDmwiBUDyStbJ35DLuy5anWRrlqLTDcA0AkTXVkDt01ZAHwLFwludZeMsLLILlRRax4+lKcnrnl/8HJzqIIG0=
02eNpdjr0LQVEYxt9zGES5o4myKVksFM45lEHKx0LJYDAZ5C+QRTHIaGETViYDKYPp3ijFYLj3KkmGK2WwuVwiv3rrrafnA1Jm16ijKBQ+6NRDGPJ2E0Xe6YnAD0hFD9nm/ObIHumlv4imZ3Mm8DwvtaxB0Jy1IUex0pYIIB30lhuCYkYvwW6nQFSV41R1L8vkmwlgEOONVvEaYt1SwLhdhxn8gdBgEfXU7RFmzeR9YtPPxrbqOVkLsd29XJhIJfbqRomGheLcYUWeFgxQodrq9wcP1E88/w==

It was clear from that inspection that the cover traffic patterns at the time were quite regular, making them distinguishable with relatively simple traffic analysis techniques. Of course, it’s entirely possible that things have improved since then – as I also mentioned, we haven’t evaluated recent versions.

To be crystal clear, there is no intent to discredit anyone’s work. In fact, it’s great to see more VPNs taking traffic analysis seriously – this is a crucial area where more research and more diverse approaches are badly needed and collectively looking at how the problem is addressed in various systems will only contributing to strengthening the countermeasures even more.

Regarding the Dandelion++ paper:
Neither Dandelion nor the Lightning Network are in any way competitors to Nym, so there’s definitely no conflict of interest Academic research on their anonymity properties also predates the NymVPN effort and is not commercially motivated. The paper you mentioned was published at NDSS - which is one of the top conferences in network and security research - hence, it went through a very thorough peer-review process by experts in the field. And I think it is important to keep in mind that research analysis (even if critical) is not discrediting, it’s a natural part of the research ecosystem. Take Tor as an example - researchers and academics (including our Chief Scientist) have spent years working on analysis and improvements to systems like Tor – which actively collaborates with academia and encourages critical studies. These efforts don’t weaken Tor, they help make it stronger.

I think it’s also worth noting that the authors of the Dandelion++ paper also interacted extensively with the Monero community – including presenting the work in person at Monero events (e.g., https://www.youtube.com/watch?v=kfyhb-GCPEE). I think it’s fair to say this was not some hit piece, but a legitimate peer-reviewed research contribution aiming to further our understanding of privacy in decentralized systems.
I would encourage you to reach out to the authors directly, as they’re happy to answer any questions. That might be a better setting to clarify your concerns, especially since more details on your actual concerns would be helpful.

Finally, regarding the notion that mentioning a past limitation in a public forum constitutes “irresponsible disclosure” – the DAITA code was (and is) open source. Everything discussed was visible and already public. It’s important to talk openly about both strengths and limitations of privacy tools if we want to push the field forward.

Again – thanks for raising these points! It’s good to keep discussions grounded and constructive, and I’m glad to see we both care about advancing real privacy for users.

cdiaz · March 27, 2025, 11:58am

Hi, I’m Claudia Diaz, one of the authors of the paper you referenced. Thanks for taking an interest in our work! Let me try to address the three issues you mention in your message.

Regarding your first point about a “flawed methodology”: I reviewed the Monero research lab forum thread you linked (#monero-research-lab), but I couldn’t find anything indicating a flaw in the paper’s methodology (nor have we been made aware of any methodological flaws in our multiple discussions with the Monero community). The discussion there revolves around the metric we used — which is indeed different from the one in the original Dandelion++ paper. However, using a different metric is not a flaw; it’s simply a different lens for evaluating the system. The original Dandelion++ work used a more abstract metric that doesn’t model a concrete adversary. Our work, on the other hand, evaluates the system against an adversary with specific capabilities and attack strategies, and measures their uncertainty about the transaction origin. This makes the results more interpretable and grounded in concrete threat models.

The simulator we used in the paper is open source, so you’re welcome to explore alternative assumptions — for example, different transaction distributions or network dynamics— and see how that affects the adversary’s performance. In fact, we very much encourage such follow-up work! This addresses your second point: whether the attack “impractical” or not in a real deployment is dependent on the number of tx sent by peers (where more transactions means more effective attack, though we also proposed attack methods to increase success when the “natural” number of txs is low). We assumed 50 transactions per peer before topology changes, which provides a well-defined and reproducible baseline. Exploring how different transaction volumes affect the attack’s success is a valuable direction for future research — and our open-source framework makes this easy to do.

As for your third point that “learning the subgraph isn’t equivalent to finding the origin IP” — that’s absolutely correct, and we never claim otherwise. The paper clearly presents subgraph discovery as an intermediate step that enables origin identification. If that was misunderstood, I’d recommend revisiting the paper, as it should be quite explicit about this.

Finally, please note that LN and Dandelion are not “competitors” of Nym but rather different technologies suiting different use cases and functionalities: in a p2p network the peers are both “users” and “intermediaries for others” (i.e., “infrastructure”) in the system, while mixnets are client-server architectures where a large number of users is served by a smaller number of servers. You can even combine them together: having the peers in LN or Dandelion communicate via a mixnet like Nym’s would enhance their privacy properties: peers would not learn each other’s IP addresses (only logical addresses) and they would also be protected towards network adversaries, who would not be able to figure out which peers are directly communicating with which other peers — while still using the overlay p2p structure to enable payment channels or the dissemination of monero/bitcoin transactions.

If you have further questions or would like a deeper technical discussion, please don’t hesitate to reach out via email to me and the other authors! We’re always happy to clarify our work and engage in discussion.

Thanks,
Claudia

Rucknium · March 27, 2025, 7:31pm

Hi Drs. Diaz and Piotrowska,

Rucknium with the Monero Research Lab (MRL) here. Just to give more context about discussions of Kumar Sharma, Gosain, & Diaz (2023) “On the Anonymity of Peer-To-Peer Network Anonymity Schemes Used by Cryptocurrencies”:

After commenting on the paper in an MRL meeting, I invited its first author, Piyush Kumar Sharma, to discuss the paper. A log of the conversation is here:

More recently, my colleague Boog900, who implemented the Dandelion++ protocol for the cuprate alternative Monero node written in Rust, read the paper. He gave a few comments in the #monero-research-lounge IRC/Matrix channel, which is not archived on the web. He quoted part of the paper:

Routing: The routing policy for Dandelion(++) is implemented as specified in the original paper, with each hop tossing a biased coin to decide whether to forward the transaction to the next hop in the privacy subgraph or broadcast (diffuse) it to the network.

and then commented:

That’s different than D++'s routing method, D++ is either stemming or fluffing every tx in a 10 minute epoch. I think having a node change between stemming and fluffing per tx would make finding the privacy sub-graph easier. After the 10 minutes is up the privacy sub graph is changed as well, meaning that most nodes will never fluff txs first in a normal D++ network epoch (as most nodes [are] in stem state)…

With coin flip per tx, and with enough txs, all nodes will fluff a tx first. Spamming a node with txs would eventually lead to every node in the stem path fluffing a certain amount of txs depending on how far they are from the first node.

With coin flip per epoch, spamming a node will just cause the last node in the path to fluff them all first.

Anyway, Kumar Sharma, Gosain, & Diaz (2023) is an important contribution to the analysis of clearnet privacy techniques for blockchain peer-to-peer networks. The paper’s assumption about the very large number of transactions broadcasted per node are unrealistic for the Monero network, but the paper was about a general implementation of Dandelion++, not specifically just Monero. (Recall that Dandelion++ was originally designed as a bitcoin protocol.) So maybe the results in the paper would help another blockchain with much greater number of transactions per node (Solana?).

When I first read the paper, I did test its Python simulation code and it seemed to work, but I didn’t take the extra step of changing the simulation’s parameters to lower the transaction volume.

A while ago I read the Nym whitepaper. For what it’s worth, I thought the privacy design was great. If implemented correctly, it could offer stronger privacy than even Tor.

But I have more important matters to discuss with @ania and @cdiaz ! MRL believes that a network of spy nodes is active on the Monero p2p network. Many of the suspected spy node IP addresses are the same as the “LinkingLion” suspected bitcoin spy nodes. MRL has recommended that Monero node operators enable a ban list against the suspected spy nodes.

A voluntary ban list against specific IP addresses is obviously an incomplete, short-term solution. I have written a little about preferring connections to nodes in separate IP subnets, but that’s still just an intermediate solution. Are you aware of research about increasing the economic cost of operating spy cryptocurrency nodes?

And do you have opinions about this paper?: Franzoni & Daza (2022) “Clover: An anonymous transaction relay protocol for the Bitcoin P2P network.” It’s supposed to be an alternative to Dandelion++, with equivalent privacy, but simpler and with better protection for node operators that don’t accept inbound connections, i.e. nodes that have closed ports. In January I contacted Giulia Fanti, first author of the Dandelion++ paper, to see if she had thoughts on it. She said she would take a look and get back to me, but I haven’t heard from her yet.

Thanks!

Rucknium · March 27, 2025, 7:37pm

Forum moderation rules limits me to two links per comment. Here’s two more:

MRL recommendation to enable a spy node ban list:

github.com/monero-project/meta

MRL recommendation: Ban spy node IP addresses from connecting to your node

opened 07:02PM - 11 Dec 24 UTC

Rucknium

The Monero Research Lab (MRL) [has decided](https://github.com/monero-project/me…ta/issues/1119) to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses. The spy nodes can reduce the privacy of Monero users. `cuprate` developer Boog900 discovered these spy nodes and created an IP address ban list. Developers and researchers associated with MRL (list names) have indicated their approval of this list by signing it with their PGP keys. ## How do I enable the ban list? Download the ban list from `https://github.com/Boog900/monero-ban-list/blob/main/ban_list.txt` and remember the directory on your computer where you saved it so you can replace `--ban-list <file-path-to-ban-list>` below with it. For example, if you saved the file in `/home/user/Downloads`, they you would replace `<file-path-to-ban-list>` with `/home/user/Downloads/ban_list.txt`. **WINDOWS USERS**: Download the ban list file directly and save it. Do not copy-paste it into a new file. There is a Windows problem with the copy-paste method that [will be fixed in the next Monero software release version](https://github.com/monero-project/monero/pull/9610). ### Running `monerod` from the terminal If you run the node from the terminal, add `--ban-list <file-path-to-ban-list>` when you start up `monerod`, i.e. `./monerod --ban-list <file-path-to-ban-list>` If you use a config file instead of command line flags, add this line to the config file: `ban-list=<file-path-to-ban-list>` ### Monero GUI wallet If you use a remote node, whoever operates the remote node will decide if the ban list is enabled. If your run your own local node through the GUI wallet, go to Settings. In the "Daemon startup flags" box, input "`--ban-list <file-path-to-ban-list>`". Then click the orange "Stop daemon" button. It will take a few seconds for the daemon to shut down. Then click the orange "Start daemon" button. ### Docker If you use SethForPrivacy's `monerod` Docker file, update to the latest version, which has the ban list: https://github.com/sethforprivacy/simple-monerod-docker If you run the Docker Monero node with any custom flags or custom config file, [you need to add to `--ban-list=/home/monero/ban_list.txt` to the set of flags or `ban-list=/home/monero/ban_list.txt` to the config file](https://libera.monerologs.net/monero/20241205#c468982). ## FAQs **1) What is the evidence that spy nodes run at these IP addresses?** The numerous spy node IP addresses are pretending to be distinct nodes, but the spying adversary is proxying a few nodes through a large number of IP addresses. That way, the spying adversary can spy on the node network, but does not have to pay the full cost of running one node per IP address. Unfortunately, the exact fingerprint of the spy nodes is not being released because the spying adversary might be able to fix the fingerprint and set up new spy IP addresses. However, a large number of the suspected spy IP addresses are the same IP addresses implicated in ["LinkingLion" spying on the BTC node network as far back as 2020](https://b10c.me/observations/06-linkinglion/). The spying adversary is likely using the same IP addresses to spy on BTC and Monero. Furthermore, most of the spying IP addresses are in a few "subnets", which are basically consecutive IP address numbers that can be purchased at a bulk price rate from IP address providers. Almost every IP address in the subnets have a suspected spy node, a status MRL is calling "subnet saturation". More details are in the [MRL GitHub issue](https://github.com/monero-project/research-lab/issues/126). **2) Can I tell how many spy nodes my node is connected to?** Yes. You can run the `peers.ip.collect()` function in the `xmrpeers` R package. See the "Examples" in the documentation [here](https://rucknium.github.io/xmrpeers/reference/peers.ip.collect.html#ref-examples). The function will also start to show the subnet saturation after running for about 24 hours. **3) What is the privacy issue?** Monero uses Dandelion++ for privacy of transactions relayed on its peer-to-peer node network. Dandelion++ provides strong privacy, but even its privacy can be weakened if there are too many spy nodes on the network. An adversary who controls a lot of spy nodes may be able to guess which user's IP address was the original sender of a Monero transaction. **4) Won't the spying adversary just change its IP addresses?** This is possible, but it's costly for the adversary. The LinkingLion BTC spying adversary is still using these IP addresses even though the spying has been publicly revealed for at least 21 months, which suggests that the adversary cannot easily change their IP addresses. **5) Are more universal fixes possible so that a specific ban list doesn't have to be used?** MRL will analyze the possible benefit of implementing an algorithm that chooses node peers to maximize diversity of Autonomous System Networks (ASNs), which are groups of IP addresses managed by the same entity. This algorithm could reduce the probability of connecting to too many potential spy nodes. In the long term, there may be ways for nodes to verify that their peers are truly running a node instead of just proxying one node through many IP addresses. **6) Why not block these IP addresses by default in the Monero node software?** Blocking the IP addresses by default is technically possible, but it would set a precedent of blocking IP addresses by a decision making process that is semi-centralized. MRL has decided to ask node operators to block these IP addresses voluntarily instead of by default.

My draft research note “Subnet Deduplication for Monero Node Peer Selection”:

pulls · March 27, 2025, 8:52pm

Hi all!

An author of Maybenot here and collaborator with Mullvad on DAITA. Thanks for the warm words @ania on Maybenot. Huge fan of Loopix

First, congrats Nym on all of your efforts in finally getting a mixnet to the masses! Very happy to see more people taking traffic analysis seriously by deploying things. We’ve discussed this for decades; it’s time to get shipping

I don’t want to derail the discussion to focus on DAITA, but there’s some confusion in the thread. Here’s a fresh blog post providing more details on DAITA defenses. In gist, @Ania’s early analysis does not consider relay-side machines and their interactions with the simple client-side machines in DAITA v1. (At no fault, these details have not yet been widely discussed, and the paper has not yet been published. My bad!) Things have also changed in DAITA v2, now live on all platforms, I’ve been told by friends at Mullvad. That said, v1 DAITA should be competitive with state-of-the-art padding-only WF defenses in the academic literature (based on Interspace). V2 is better!

@SaltyYogurtt, there is no harm in Ania looking around the open-source code and sharing impressions. That’s why it’s open. Publication and sharing of ideas move the space forward. Thanks for your concerns about harm reduction, though. I’m sure @ania would follow community safety guidelines if something serious came up.

We’re also comparing apples and oranges here, which are somehow placed under a VPN umbrella. Nym tweaks a mixnet to be more usable but inadvertently lowers security in the process. DAITA tweaks WireGuard to be more secure, reducing usability by adding overhead in terms of bandwidth and delay. We have different but closely related notions of security and intended use as well.

What matters is that we care about traffic analysis resistance and are shipping! Let’s spend our energy going after the 99+% of Internet connections lacking traffic analysis defenses.

Best,
Tobias Pulls

ania · March 28, 2025, 11:13am

Thanks for popping into the thread, Tobias — great to have you here! Really appreciate the kind words, and I’m very glad to hear there’s a DAITA v2 out! Excited to see continued evolution in this space — and fully agree, it’s great that we’re all pushing forward on traffic analysis defenses and getting things into users’ hands

cdiaz · March 28, 2025, 2:38pm

Hi and thanks a lot for all the additional info!

Regarding follow up discussions on the 2022 paper – would be better to transfer it to email (please do include my co-authors (piyushks@umich.edu and dgosain@cse.iitb.ac.in) as it’s a bit off-topic in this thread, and also Piyush and Devashish did all the implementation/experimental work so they are better positioned than me to go into the weeds of the experiments.

About the spies, that’s a tough problem! if the spies are really smart they may be able to stay undetected since these are passive attacks. However if they made some mistake or tried used multiple nodes running in the same place, well, removing or avoiding them seems a sensible thing to do (but they may come back better hidden though).

I haven’t had the time to look into Clover so I can’t say anything smart about it – though from what you say it seems an improvement over D++. What I can share is my general take on p2p anonymity designs. In my view such designs have inherently some shortcomings when used for network anonymity:

(1) conflation of roles: every peer is both a “user” (originating txs) and “infrastructure” (relaying txs for others). I believe this leads to a tension between privacy and service integrity / accountability. As user you want privacy, and thus prefer to not reveal information; while wanting to verify (to the extent that is possible) that the infrastructure routing your messages is doing so reliably and correctly. If peers reveal “more” of what they do, they may undermine their own privacy, while if they reveal “less” it may be hard for others to see that they are doing their job correctly. In that sense, I believe that client-server architectures, with distinct roles, are less problematic, as you now have two classes of entities each with its requirements (users want privacy while infrastructure should be as verifiable as possible).

(2) thin traffic and vulnerability towards network adversaries. If peers generate, say, 1 tx per minute, and every tx is routed via 10 peers, then each peer is routing on average 10 tx per minute. This means that there is little “aggregation” of traffic, which is beneficial for creating large anonymity sets. In contrast, in a client-server architecture you can potentially have thousands of packets (from thousands of users) mixed together in a server, making it hard to trace packets every time they go through a node. Furthermore, note that in p2p designs, an adversary observing the i/o of a peer can typically tell if the node is the originator of a tx: if nothing was recently received, and something is sent, chances are this is a new tx originated by the peer. Note that the “thin” traffic makes this easier (if the peer was routing thousands of txs it wouldn’t be so easy to tell, but in a p2p design that would require very long routes) .

That said, p2p designs are great for having decentralized functionalities (such as payments). I am just not too convinced that they are the best approach when it comes to network anonymity. That’s my 2 cents.

username0990 · April 8, 2025, 10:18am

Hi. You have explained here why NymVPN cannot be used with the manual configuration file at the moment. Would you consider releasing packages for routers and other embedded devices?

For example, the community-maintained tailscale and netbird packages are in the entware repository.

https://bin.entware.net/armv7sf-k3.2/tailscale_1.78.3-1_armv7-3.2.ipk
https://bin.entware.net/armv7sf-k3.2/netbird_0.35.2-1_armv7-3.2.ipk

@nym-product @ania

anonymous261 · April 13, 2025, 4:05am

Hello people at Nym (Nym-ployees)! During the free period before official launch, I tried your Android app’s Fast Mode (or Nym-ble Mode as i like to call it) for a couple days. It uses up a lot of battery, but I’ve really liked your product’s speed and the fact that Brave Search stops giving me CAPTCHAs because of your DVPN. Would you be able to consider these two suggestions (on top of considering further optimization of battery)?

While I am confident this fact has not gone over your heads, and that this suggestion is certainly easier said than done, I still feel this is worth mentioning. The paid nature of your services, particularly the Anonymous Mode (or Anon-Nym Mode as I like to call it), limits the userbase. This not only may restrict high risk individuals who need Anonymous/“Anon-Nym” Mode the most from accessing the service, but it may also limit the crowd’s size. A smaller group of Nym users would make it harder to blend in with the crowd, making users more unique and fingerprintable.

How about if you committed to making low risk, convenience features like Fast/“Nym-ble” mode, product support priority, adblocking, server preferences, and DNS customization the paid features? The high risk, anonymity features can be delegated as more accessible to the public, of course once adequate financial stability is achieved to support it.

I believe it would be the best of both worlds! An identifiable and reasonable source of income ensuring the user is not the product, and an open network to keep a very wide range of people safe.

For browsing with anonymity, could you put Mullvad Browser with Anonymous/“Anon-Nym” Mode as a recommendation on the Nym website or something?

It has strong fingerprinting protections out of the box, and telling users to use that service specifically will help them blend in with each other even more.

Thank you for your work, and stay Nym-mazing!