VPNs, Tor, I2P — how does Nym compare?

NOTE: this post is more than a year old and might contain outdated information. For up to date and accurate information about the Nym mixnet architecture, please always refer to the Nym docs.

Online users who would like to enhance their privacy on the network-level can choose among various techniques, including centralized VPNs, decentralized VPNs, Tor or I2P. In this blogpost, I will discuss what level of privacy those solutions give you in comparison to Nym.

Centralized VPNs

In response to the danger of censorship and surveillance internet users are turning to various privacy and anonymity tools. One of the most popular means to enhance online privacy are Virtual Private Networks (VPNs).

In a nutshell, VPN software builds an encrypted tunnel between a client device and a server run by a VPN provider, which acts as a proxy that forwards the client’s communications. Hence, you’re able to browse the internet using the connection of the VPN server, which allows bypassing censorship or geolocation blocks. The encryption of network traffic done by the VPN is beneficial when you’re connecting to an untrusted network (e.g., a public WiFi) since neither ISP nor a malicious hacker sniffing your connection can see which websites you’re accessing.

Although the confidentiality of the network traffic is protected from the recipient website and ISP thanks to encryption, users can be still de-anonymized via the size and timing of the data packets. More importantly, the confidentiality of your network traffic with a centralized VPN is much less powerful than it appears.

Centralized point of control

Although VPNs offer enhanced internet privacy and protection against data hacking, they suffer from inherent weaknesses due to their centralized trust based model. A VPN provider acts as a trusted proxy and hence knows about all of the websites an individual is accessing. Hence, you and your communication are not anonymous vis a vis the VPN provider. While VPNs promise to keep users safe with no logs policy, many examples showed this is often not true [1]. For example, HideMyAss, the UK-based VPN service, handed logs and users’ information to the US authorities despite the company’s claim that it did not record any logs [2].

No Traffic Analysis Resistance

Moreover, even though VPNs shield our online activities, VPNs are ineffective in the presence of powerful network eavesdroppers, who can simply track the routed network traffic based on the size and timing of the data packets and thus easily correlate our IP address with the services we are visiting. Take for example the hacking attack on NordVPN, one of the largest VPN providers in the world: The central NordVPN server was breached back in 2018, allowing the attacker to monitor traffic and expose some of the browsing habits of the customers.

“Free of charge” VPNs for the price of your privacy

Due to the fact that the VPN providers charge for their service, they can easily link the users’ detailed history of online activities to their identities. On the other hand, there is also an increasing number of VPNs promising to keep you safe at no extra cost. Sounds sketchy? Well, such “free” VPNs have to somehow earn income from the users to maintain their software and servers. Hence, they ‘charge’ their users indirectly by for example embedding third-party trackers in their software to gather data on your online activity and sell it to the highest bidder [1].

Tor and I2P

In contrast to single proxy VPNs, Tor and I2P overlay networks build upon a decentralized network of nodes and forward traffic via multi-hop circuits, in order to hide route information from any single party. Hence, in contrast to central VPNs, a single Tor relay cannot link both the sender and destination of the communication, and so at minimum obscures the IP address of the sender.

Tor

Tor is currently the most widely used anonymous communication network attracting around two million users daily. Unlike VPNs, Tor forwards traffic via multi-hop connections. Each connected user opens a long-lived circuit, comprising three successive, randomly selected relays: entry guard, middle relay and exit relay. All communication (during the session) flows down via this predetermined sequence of relays in fixed-size cells. Once a circuit is created, it is alive for a session of ten minutes and then all data is rotated to a new circuit.

Each data packet sent via Tor is layer encrypted by the sender, and each onion relay upon receiving a packet removes a single layer of encryption. This onion encryption ensures that none of the relays has visibility on both the source of the traffic and the final destination, nor the content. The exit relay decrypts the innermost layer of encryption and forwards the original data to its destination without knowing the source IP address.

Even though Tor onion relays are run in a decentralized fashion, Tor relies on a very important semi-centralised component: The hand-coded directory authorities which collects and redistributes the view of the network and measurement statistics. These directory authorities are manually hard-coded into the Tor software and consist of seven to ten trusted friends of the non-profit that creates the Tor software.

Without any doubt Tor is a great tool for anonymous communication and by far the most popular anonymous communication network. Its design is far superior to centralized VPNs, and it should be used instead of centralized VPNs where possible. Tor’s usage of a circuit that forwards all data in and out in a first-in, first-out order allows Tor to maintain high speeds, while keeping a low latency. In theory, Tor’s latency should be not much more than a VPN, as in a VPN, traffic is doing one hope, while in Tor, three hops is used for anonymity. Although this adds some latency, Tor gains the ability to obfuscate the IP address of the user. Similar to VPNs, Tor is optimized to support low latency and high volume traffic such as web-browsing. Unlike VPNs, Tor’s diversity of routing makes it much more difficult to attack.

However, by design Tor can defend only against local network adversaries who do not have visibility over large parts of the network. Tor’s threat model is defending the user against websites that track a user as well as enemies that can observe only a small part of the network, such as the user’s ISP or a Tor exit node As stated in the Tor paper:

Tor does not claim to completely solve end-to-end timing or intersection attacks.

Since there is no reordering of the packets, the global network adversary that can watch the entire network can successfully deploy end-to-end correlation attacks on traffic flows, and in result link the source and destination [7,8,9,11]. Moreover, Tor is also susceptible to website fingerprinting techniques which exploit distinctive traffic patterns of web traffic that the Tor network leaves unaltered [10, 12, 13]. Furthermore, circuit connections are also vulnerable to flow correlation attacks, as all nodes in the path, including malicious ones, can observe patterns of requests and response [14, 15, 16, 17, 18, 19, 20].

I2P

I2P (Invisible Internet Project) is a peer-to-peer alternative to Tor, in which each participant acts both as a client and as a router. While the primary use case for Tor is enabling anonymous access of the public internet with hidden services supported as an additional benefit, I2P is designed as a closed ecosystem for accessing hidden services integrated within it.

While Tor adopts the directory-based approach, I2P replaces directory authorities with distributed hash tables (DHT) and peer selection. This approach intuitively seems more appealing to blockchain developers pursuing peer-to-peer networks, as it is less centralized than Tor. This intuition led to the attempted integration of I2P with Monero with the Kovri project, which tried to reimplement I2P from scratch due to issues integrating I2P directly with Monero.

Unfortunately, I2P is not clearly documented with a threat model and properties it’s trying to achieve, and new attacks keep appearing despite the fact the network is much less well-studied than Tor. Although I2P’s approach avoids a semi-centralized point to manage the overall view of the network, DHTs are by default vulnerable to various attacks on the lookup mechanism that damage the privacy and security of the network [3]. For example, the attacker can intercept lookup requests and return a parallel network of colluding malicious nodes, which can then deny service or learn about the behavior of clients [4, 5].

As in Tor, I2P clients send layer encrypted connections via multi-hop paths. For encryption, I2P uses garlic-encryption, an extension to onion routing, in which multiple messages are bundled together. However, I2P is packet-based and uses short-lived unidirectional channels, instead of long-lived bidirectional circuits. This improves load balancing and limits the amount of can data flowing in one direction, which reveals less information.

Similarly to Tor, upon close inspection I2P defends only against local network adversaries, but cannot protect users’ anonymity against more sophisticated adversaries performing traffic analysis. Unlike a mixnet, there is no per packet mixing. It is pointed on the I2P project website that the mixing strategies are necessary to prevent traffic correlation [6].

Incentives in Tor and I2P

Both I2P and Tor nodes are volunteer-driven. Tor in particular relies primarily on donations, government funding, non-profit grants and contracts. Hence Tor and I2P suffer from the lack of economic incentives for operators. As there are no economic incentives to run a node, the volunteers have to cover the cost of running and maintaining it. This can lead to poor performance and even scaling problems.

Although the number of nodes running Tor is large, the number of Tor nodes has been around 8,000 for the last two years without growth, despite spikes in demand. I2P has as many as 45,000 nodes. However, this does mean that I2P is larger than Tor, as I2P clients also count as nodes. In contrast, Tor has about two million users, which provides a large amount of diversity and so better privacy in their traffic. However, user growth on Tor has remained around 2 million since 2016, while other privacy apps like Signal had two million users in 2016 but are now scaling to tens of millions. It is unclear how large purely voluntary networks can scale and also how they can achieve sufficient geographical diversity.

Loki

A fork of Monero (with the “master node” concept from Dash thrown in), Lokinet is a fairly new project which introduces the incentivized LLARP (Low Latency Anonymous Routing Protocol) network-level protocol, a hybrid between Tor and I2P. Like Tor, the traffic within the Loki network is onion encrypted. Like traditional I2P, Lokinet relies on DHT instead of directory authorities. It also uses packet-switched based routing instead of circuits, which prevents the flow correlation. However, Loki still inherits several limitations from Tor and I2P, including (1) DHT privacy vulnerabilities and the (2) the lack of packets reordering still allows for easy traffic analysis. Therefore, it is best to consider Loki an attempt to hybridize Tor and I2P, but with an incentive structure.

Yet the incentive structure seems disconnected from the provisioning of bandwidth, as the “service nodes” that do the routing (equivalent to “master nodes” in Dash) get a portion of the reward from blockchain mining. Loki does not have a description of how quality of service is maintained, the whitepaper states: “Bandwidth is not monitored or recorded in the DHT. Instead, bandwidth measurement and triage result from swarms that bassess each node and make a judgement on the nodes ability to provide appropriate bandwidth to the network,” where swarms are groups of service nodes.

Although Loki launched only at end of 2018, they now have approximately 900 nodes, which is fairly rapid growth for a new experiment. While service providers do have to route network traffic, they also must maintain full nodes of the entire traditional proof of work Loki blockchain, as well as “instant confirmations” via quorum of service provider nodes (just like Dash’s master nodes). Therefore, it is unclear how many users are actually non-LOKI transactions traffic (such as the kind of traffic normally carried by Tor or a VPN) through the Loki network and how much resources this consumes.

Decentralized VPN

A fairly new trend, motivated by the trust and privacy concerns of VPNs, are the decentralized VPNs. dVPNs are a new form of virtual private network with no central authority. In dVPNs users are both clients and servers, hence each participant offers a portion of their bandwidth to carry traffic for others. With no central point of control and failure, the dVPN system is naturally made fairer and more secure.

The recent blogpost by Brave summarizes the trust and reliability requirements of dVPN designs. A dVPN design by Brave researchers called VPN⁰ pairs the clients with nodes currently available to serve their traffic using a DHT like I2P, but so inherits the same DHT security and privacy problems that plagues other decentralized systems [3]. VPN⁰ still seems to be a research project and not in production, and does not yet feature an incentive scheme attached using Brave’s BAT token.

In general, dVPNs are all powered by blockchain technology in order to provide payment to the VPNs. The concept is that users share bandwidth in exchange for crypto-tokens, and most of the dVPN projects have a specialized utility token that users must pay the dVPN service in, even if the user has the freedom of choosing their own VPN node in the decentralized network. The first dVPN project funded by a token sale was Mysterium in 2017, followed by other projects like the Cosmos-based Sentinel in China and Ethereum-based Orchid.

In 2019, dVPNs actually started launching. It is hard to measure their uptake in terms of actual usage compared to centralized VPNs and Tor. Mysterium and Orchid seem to have around 5,000 token holders of their MYST and OXT tokens, with Sentinel’s SENT having around 2,000 holders. The connection of Mysterium to their tokens seems relatively tenuous except to guarantee some kind of identity registration. Sentinel builds on Cosmos and seems to work well in China. Orchid’s dVPN works well and has a cutting-edge payment infrastructure, based on Rivest’s Peppercoin [21], attracting partnerships from major centralized VPNs.

For encrypted secure tunnels Sentinel users can currently choose between OpenVPN and SOCKS5, which similar to ShadowSox, works well in China as long as the number of users remain low. Mysterium and Orchid integrate OpenVPN and WireGuard, the latter which uses more efficient modern cryptography. Given this explosion of interest in dVPNs, let’s take a quick look at what properties dVPNs offer.

No logging

In order to limit the amount of logs of users’ traffic stored by a single entity (the main issue of centralized VPNs), Sentinel introduces the possibility to mask the users’ activities by forwarding their traffic through a series of nodes. Users can customize the number of relay nodes that should be involved in the connection. With Orchid, clients can construct single or multi-hop circuit by selecting randomized VPN nodes, from a global pool of providers, weighted on their stake.

In general, these approaches distribute traffic between multiple VPN providers, so the risk of centralized logging is eliminated, as in Tor. Unlike Tor, these designs allow single-hop routing, and so dVPNs should have possibly even lower latency than the multi-hop Tor, but at the cost of less privacy from randomly chosen dVPN node.

Traffic analysis still a risk

Although the idea of multi-hop VPN routing makes strides towards obfuscation of the information about users’ activities, it only allows to obfuscate the users’ IP and limit the amount of the amount of information proxy nodes can collect, but it is not yet enough to resist the traffic analysis attacks like intersection, fingerprinting, statistical disclosure, end-to-end correlation etc. attacks. In this regard, dVPNs share much of the same attacks to which Tor is also vulnerable. Orchid explicitly places traffic analysis in future work, although a user can send dummy traffic via “bandwidth burning,” where a user buys extra bandwidth with their tokens. The addition of payment infrastructure based on (at best) pseudonymous on-chain transactions (even with Orchid’s “probabilistic nanopayments”) means also that an adversary can easily de-anonymize VPN users by observing on-chain financial transactions between dVPN nodes and user accounts.

Exit node liability problem

Another issue regarding peer-to-peer dVPNs is that the users risk that their machine will be used to transmit possibly illegal network traffic and they will be held liable and might face repercussions from the authorities. This is a similar issue to those facing Tor exit nodes, since exit nodes connect directly with an open web.

Mysterium claims to use the feature of whitelisting to allow users to forward whitelisted traffic only (of course they can still choose to accept any kind of traffic at their own risk). However, as the nodes have to be able to distinguish the “clean” whitelisted traffic from illegal, it introduces a tradeoff between privacy and safety. Similar whitelisting, currently on-chain with trusted VPN providers, is actually provided by Orchid. Eventually, third-parties in Orchid could create their own whitelists.

Where is Nym placed on the map?

Onion routing, I2P, Loki, dVPNs, and even centralized VPNs all can enhance our online privacy, much better than not using any encrypted proxy to the wider Internet, all these designs essentially provide the same functionality: obscuring an IP address while maintaining relatively low latency connections. The real question that faces work on dVPNs is whether or not incentives can provide the ability to scale, or is the non-incentivized Tor the best design possible? Only time will tell.

How does Nym compare to the privacy properties offered by those systems? Nym is not an onion routing system, it is not a decentralized VPN. Nym is a mix-net meant to stop precisely the traffic analysis attacks that Tor and dVPNs are vulnerable to. Therefore, Nym is an orthogonal design that maintains better privacy and can support anonymity, although usually with a cost in terms of latency. For a review of mixnets, see the previous blog post on how Nym compares to traditional mix-net design.

Decentralized

Nym is building a fully decentralized network, with no trusted parties, centralized components, or single points of failure. All functionalities of Nym are performed in a decentralized and distributed manner, and like in dVPNs there is no possibility to enable centralized logging.

Data confidentiality

Nym guarantees the confidentiality of all the data traversing the system. Only the source and the designated destination learn the content of the exchanged data, but no intermediate node or third-party entity can infer the content of the communication. To ensure that Nym uses the unlinkable Sphinx packet format (article here) in order to gain better anonymity rather than the onion-routing design used by Tor or VPN proxies like OpenVPN or Wireguard.

IP hiding

Only the immediate successor of the sender (i.e., first mix node) is aware of the IP address of the user who has initiated the communication. In this regard, Nym obfuscates the IP and is similar to Tor, I2P, or multi-hop dVPNs. Single-hop dVPNs are equivalent to centralized VPNs and only hide the IP from the website that is being visited, but the VPN itself can still determine your IP address and the IP address of the recipient.

Traffic analysis resistance

In contrast to Tor and dVPNs, Nym is the only currently deployed design which guarantees the anonymity of users communication, even under powerful surveillance and sophisticated traffic analysis techniques. Even if the adversary has a global view of the network Nym protects your communication. Moreover, in contrast to circuit-based designs, Nym mixnet routes each packet independently, through a different route, and re-ordered. This ensures resistance to end-to-end flow correlation, hence the attacker cannot identify or correlate traffic patterns at the initiator and receiver.

Incentives

Nym uses token-based incentives to provide the foundations for a sustainable ecosystem of privacy-enhanced services, unlike Tor and like dVPNs. Nym mix nodes and services stake in order to participate in the network.

A special incentive protocol which combines the usage of a VRF (Verifiable Random Function) to create a “proof of mixing” scheme ensures that honest mixes are rewarded for their work, while nodes acting in a malicious or dishonest way are penalised. This provides a much stronger connection of the incentives to the bandwidth provided than most dVPN systems, making Nym more similar to “proof of work” systems like Bitcoin.

Sybil attacks resistance

Thanks to the combination of selective disclosure credentials and incentives, Nym network is resistant to sybil attacks and denial of service measures.

No logging

In Nym, the intermediate nodes forwarding the communication cannot learn any information encapsulated within Sphinx packets, and they only see their immediate predecessor and successor. Hence the only data which they can potentially log is how much traffic they observe going through them, nothing more.

No exit host reliability

In Nym the exit nodes pass the network traffic to service providers, not directly into the open web, hence there is no risk of exit node liability. This does of course limit the kinds of services that can be run, and a generic TCP/IP gateway to the internet could be made, but that risk would be a risk taken by the service provider, not any nodes in the Nym network.

No identity registration

Thanks to the use of Nym selective disclosure credentials users can authenticate to any application or service within the ecosystem without revealing any information about themselves. Therefore, there is no need for “identity registration” or any other privacy-invasive identification.

Privacy-enhanced authentication and payment

Nym does not force payment by users in a token that can then be used to easily de-anonymize users. Instead, important information around payments and identity can, if needed, are done off-chain via anonymous authentication credentials to ensure privacy.

Mixnets and dVPNs — Summary

Mixnet is an anonymous overlay network that is based on packet-based routing and packets re-ordering. Hence, mixnets are best suited for asynchronous applications such as cryptocurrencies, messaging, and privacy-enhanced corona-tracing. Mixnets are an entirely different architecture from onion-routing systems like Tor, I2P and various other dVPN proposals: Despite their superficial differences, both Tor and dVPNs are fundamentally based on low latency circuit-based streaming of packets. Mixnets tradeoff latency for anonymity, while Tor and dVPNs tradeoff anonymity for speed. Although traditionally mixnets were designed to carry only latency-tolerant communication, the Nym mixnet is based on modern design which enables tunable tradeoff between latency and the volume of traffic.

At the present moment, it is best to consider dVPNs and Tor as complementary and ultimately different form of technology for mixnets. We can easily imagine a world where web traffic goes through a dVPN or continues going through Tor, while other apps based on messaging that require a higher degree of privacy — like cryptocurrency — use a mixnet like Nym. The key is while we have had a new host of dVPN projects in the last year and Tor has been obscuring IP addresses for going on two decades, now is the time for new decentralized technology that can provide resistance against powerful adversaries that can monitor an entire network.

References

[1] Khan, M.T., DeBlasio, J., Voelker, G.M., Snoeren, A.C., Kanich, C. and Vallina-Rodriguez, N., “An empirical analysis of the commercial VPN ecosystem”

[2] Martin, Adam LulzSec Hacker Exposed by the Service He Thought Would Hide Him. 2011.https://www.theatlantic.com/technology/archive/2011/09/lulzsec-hacker-exposed-service-he-thought-would-hide-him/337545/

[3] aTroncoso, C., Isaakidis, M., Danezis, G., & Halpin, H.. Systematizing decentralization and privacy: Lessons from 15 years of research and deployments. PETS 2017.

[4] Sit E., and Morris R., “Security Considerations for Peer-to-Peer Distributed Hash Tables“

[5] Wallach D.S., “A survey of peer-to-peer security issues”

[6] https://geti2p.net/en/comparison/tor

[7] Paul F. Syverson, Gene Tsudik, Michael G. Reed, and Carl E. Landwehr. “Towards an Analysis of Onion Routing Security”, International Workshop on Design Issues in Anonymity and Unobservability, 2000

[8] Steven J. Murdoch. “Hot or not: revealing hidden services by their clock skew”, CCS 2006

[9] Steven J. Murdoch and George Danezis. “Low-Cost Traffic Analysis of Tor”, S&P 2005

[10] Xiang Cai, Xin Cheng Zhang, Brijesh Joshi, and Rob Johnson. “Touching from a distance: website fingerprinting attacks and defenses”, CCS 2012

[11] Juan A. Elices and Fernando Perez-Gonzalez.“Fingerprinting a flow of messages to an anonymous server”, WIFS 2012

[12] Jamie Hayes and George Danezis.“k-fingerprinting: A Robust Scalable Web- site Fingerprinting Technique”, USENIX 2016

[13] Juan A. Elices, Fernando Perez-González, and Carmela Troncoso, “Finger- printing Tor’s hidden service log files using a timing channel”, IEEE WIFS 2011

[14] Aaron Johnson, Chris Wacek, Rob Jansen, Micah Sherr, and Paul Syverson. “Users get routed: Traffic correlation on Tor by realistic adversaries”, ACM CCS 2013

[15] Brian N. Levine, Michael K. Reiter, Chenxi Wang, and Matthew Wright, “Timing attacks in low-latency mix systems“, Financial Cryptography 2004,

[16] Steven J. Murdoch, and Piotr Zielinski, “Sampled traffic analysis by internet-exchange-level adversaries”, PETs 2007,

[17] Z. Ling, J. Luo, W. Yu, X. Fu, D. Xuan, and W. Jia, “A new cell-counting-based attack against Tor”, IEEE/ACM Transactions on Networking 2012,

[18] Rebekah Overdorf, Mark Juarez, Gunes Acar, Rachel Greenstadt, and Claudia Diaz, “How unique is your .onion?”, ACM CCS 2017

[19] Andrei Serjantov and Peter Sewell, “Passive-attack analysis for connection-based anonymity systems”, International Journal of Information Security 2005

[20] Vitaly Shmatikov and Ming-Hsiu Wang, “Timing analysis in low-latency mix networks: Attacks and defenses”, ESORICS 2006

[21] Ronald Rivest. “Peppercoin micropayments.”, International Conference on Financial Cryptography, 2004.