Nym mixnodes deep-dive
Learn more about how mixnodes secure privacy and unlinkability
Learn more about how mixnodes secure privacy and unlinkability
As their name suggests, ‘mixnodes’ are the nodes that make up the core of the Nym ‘mixnet’, and are therefore fundamental to the proper functioning of the entire Nym system. Mixnodes “mix and relay identically-formatted encrypted data packets — called Sphinx packets — multiple times, before forwarding these packets on to the final recipient of the original message” (read this blogpost for overview of all network actors).
This post will dive deeper into the work that mixnodes do, outlining how exactly they protect network traffic from observers, as well as describe some of the interesting parameters that node operators can tweak to customise their mixnode and offer greater anonymity protections for different types of applications.[1]
Mixing!
As shown in the diagram above, moving left to right, mixnodes receive Sphinx packets from gateways, which act as the interface between Nym clients and the mixnet. They then mix these, reordering them by adding randomized per-packet delays, before passing the packets on to the following mixnodes and finally to a gateway, who will pass the packets to the intended recipients.
The mixing protects against time-based correlation attacks and traffic analysis, making it nearly impossible to trace who is speaking to whom. Mixnodes also add ‘cover traffic’ if and when necessary for maintaining a steady amount of network traffic, making it even harder for an observer to trace data packets, providing “lost in the crowd” privacy.
The mixnet is organised into three distinct layers of mixnodes. Each packet will be mixed by a mixnode on each layer before being delivered to the appropriate gateway (the one connected to the recipient’s client) and forwarded to the recipient, where it will be decrypted. The path taken by packets is selected by the sender’s Nym client. The client encrypts the packet multiple times using the public keys of the three mixnodes that the message will be relayed to in its journey through the mixnet.
Ensuring unlinkability
One of the primary privacy features of mixnets is that they provide unlinkability between input and output messages. Unlinkability is “the inability to determine which pieces of data available at different parts of a system may or may not be related to each other”.[2]
There are in fact several mechanisms in the Nym mixnet that contribute to this overall feature of unlinkability. The main one is the use of continuous-time mixing by mixnodes, where the forwarding of each Sphinx packet is delayed by a variable amount of time. The aggregate effect of independently delaying each packet before forwarding it on is that, given two inputs arriving at different times, “the probability that the first output is any of the two inputs is equal, regardless of differences in arrival times”.[3] In more technical terms, continuous-time mixing creates “theoretically unbounded” anonymity sets: an attacker must keep track of incredibly large numbers of Sphinx packets as they travel through the mixnet in order to attempt something like a time-correlation attack to deanonymise a user — because the variable delay time for each packet and resulting anonymity is compounded with each mix in the path of the packet.
Now there are obviously limits imposed by practical usability on the duration of end-to-end latency. Instant messaging apps for example would be very frustrating to use if messages took tens of seconds to arrive! But this usability issue actually varies depending on the type of application that is using the mixnet. For example, for a file-transfer application, a few minutes of extra time delay does not severely affect its usability. Importantly, the range of time that a users’ packets will be delayed by each mixnode on their route is chosen by the Nym client itself, meaning that users are in control of the trade-off between increased overall latency and increased anonymity.
In fact, high-latency applications actually provide protection against network monitoring attacks for low-latency applications by acting as cover! The Nym network is designed to be generic in that it is able to offer anonymity for both low-latency applications (such as Lightning Network payment channels or instant messaging) and high-latency ones (such as email routing, or file sharing). The semi-unbounded size of the network’s anonymity set, coupled with cover traffic generated by mixnodes, allows for the more-easily distinguishable traffic fingerprints of low-latency applications to be hidden in the noise of the overall network traffic (as the per-mix delay times are themselves encrypted in the Sphinx packets by the client prior to it being sent into the mixnet).
Shrinking and expanding the mixnet
There are a number of more structural aspects to the architecture that also contribute to unlinkability, which also ensure an adequate scale of the mixnet and a good quality of mixing.
First off, the mixnet has distinct time periods called epochs, during which a certain network size and configuration is set (we are currently planning for these to be set to last an hour). This allows the network to adjust in size and configuration. A certain number of mixnodes will be the ‘active set’, performing the mixing and relaying of sphinx packets through the mixnet layers. Meanwhile other mixnodes will be idle, waiting to potentially be selected as active in the next epoch. This allows the network to retain capacity in reserve, and expand and contract to ensure resource-efficiency and meet demand.
Secondly, epochs also allows for the network to regularly reconfigure, adjusting the total number of mixnodes per layer and changing which mixnodes are assigned to each layer. This allows the network to remove underperforming or ‘dead’ nodes that have (e.g.) gone offline in the previous epoch in order to maintain the overall health of the network.
Last but not least, this per-epoch reconfiguration of the mixnet also makes it more difficult to construct a path of malicious mixnodes that might attempt to deanonymise traffic, as the constituent members of each layer change each time!
The selection process for nodes in the active and idle sets is randomised, but preferentially weighted according to the total stake delegated to these nodes: the greater the amount of stake delegated to a mixnode, the greater the chance that the node is selected to be part of the set of mixnodes that mixes traffic (or is ready to do so), and is rewarded for doing so![4] The randomisation of both inclusion into the rewarded mixnode set and which layer the mixnode exists in substantially reduces the possibility of an actor or actor(s) being able to control all or some of the relays that Sphinx packets would take, and deanonymise traffic.[5]
Mixnode incentives
Which brings us to the way that mixnode operators are financially incentivised to take part in the mixnet: network rewards. Mixnodes have to stake NYM tokens in order to be considered part of the network. The amount of stake will determine their likelihood of being selected to be part of the active set for that epoch. Anyone else with NYM tokens can also delegate stake to the mixnode, increasing its likelihood of being selected by adding to their overall stake, and earn a share of the rewards in return. This acts as a form of reputation ensuring good Quality of Service: people will be more likely to stake on well performing nodes because they will then be more likely to earn a higher share of rewards.
After an epoch of mixing, mixnodes in the active set receive NYM tokens from a reward pool for providing privacy by mixing and relaying sphinx packets. These rewards are distributed according to their total stake and their Quality of Service to the node operator and their delegators.[6] Quality of service (QoS) measurements are taken by the Nym validators. This measurement involves test-packets, which are routed through the various ports that the mixnode is assumed to have open. If these test packets pass through the mixnode to their destination, and the mixnode is responsive every time these measurements are taken (about once every 15 minutes), the mixnode will be seen as having a high QoS and be rewarded accordingly. Meanwhile mixnodes in the idle set also receive rewards from the pool for being ‘on standby’, although a smaller amount given that they are not performing any work.
Mixnodes have profiles on the Nym mixnet explorer, and can distinguish themselves from others in order to attract more stake and earn more rewards. They can do this implicitly by improving their QoS, and explicitly via both their pricing parameters, and any additional extras they wish to include. The sort of attractive parameters that nodes can offer to delegators include offering more competitive price-per-packet rates — the amount the node charges for mixing packets — and the reward margins that they offer to their delegators. They can also introduce other attractive externalities, such as giving some of the proceeds of their operations to a good cause, such as “free access” to Nym for human rights activists, which will resonate with some delegates on a less economic and more ideological basis.
All of the above points show just how complex mixnodes are — and they are simply one part of the Nym system!
Follow the work at Nym on Telegram or Twitter @nymproject.
[1] See Figure 3 on page 14 of the Nym Whitepaper for a diagram of the multi-layered encryption at work with the Sphinx packet format.
[2] https://nymtech.net/nym-whitepaper.pdf pg9
[3] https://nymtech.net/nym-whitepaper.pdf pg14
[4] This is reliant on the assumption that node delegation will act not only as a method of network incentivisation, but also as a form of soft governance, wherein those mixnodes that provide the best Quality of Service (QoS) gain more rewards than their peers in virtue of the fact that users delegate more of their own NYMs to them as they are seen as having a higher reputation than those with lower QoS.
[5] Thus, in a network with L = 3 layers, an adversary that controls 50% of the mix nodes (α = 0.5) would be able to observe 12.5% of messages in the most favorable topology configuration, while an adversary that controls 10% of nodes in each layer (α = 0.1) would only fully observe 0.1% of messages. If the number of layers is increased to L = 4, then an adversary that controls 50% of nodes would in the best case observe 6% of messages and an adversary that controls 10% would just see 0.01%, i.e., one message out of every 10, 000. Nym Whitepaper, page 13.
[6] Find specific formulas for this in the Whitepaper.
