Loki’s Exploration into the Mixnet Space
We have been dropping lots of not-so-subtle hints that we have been working on a decentralised mixnet, and it’s finally time to reveal what we’ve been working on. This article, along with the soon-to-be-released white paper version 3 should get everyone up to speed on Lokinet.
MIX WHAT?
Mixnet is a term used to describe an overlay network that operates on top of the internet. You might have heard of Tor or I2P- these are both mixnets. So what’s the idea behind a mixnet? Typically, when you make a connection to a website, your IP address is visible to the web service you connect to. Internet IP addresses are similar to street addresses in the physical world; they identify where information (known as ‘packets’) should be sent. The problem is that every time you connect to a web service, you give away your IP address. This makes internet browsing anonymously very difficult. Services you connect to can use your IP address to work out your general location, and state level actors can use legal processes to extract your IP address from web services and connect your IP address with your real world identity.
The solution to this problem is a mixnet. Mixnets work by using groups of nodes (other computers) all around the world. Instead of your connection going directly to the web service, it first hops through multiple nodes selected at random. These nodes are typically called ‘relays’ or ‘routers,’ and the path you create through them is called a ‘circuit’ or ‘tunnel’.
When using a mixnet, your connection to a web service does not look like it is coming from you. The web service only sees the IP address of the node that is the last hop in your circuit. Similarly, your internet service provider (who can usually see the connections you make to web services) only sees your connection to the first node in your circuit. To make things even trickier, most mixnets use techniques called “Onion Routing” and “Garlic Routing.” With these techniques, each hop in your circuit only knows the previous node (where the packet came from) and the next node (who they need to send the packet to). They do not know where the packet originated from, which means they do not know who you are. This limits the information that even dishonest nodes can gather about you when you use a mixnet.
Loki is building its own mixnet. Why? There are perfectly good mixnets out there right now, why don’t I just use those?
Well…
THE PROBLEM WITH CURRENT MIXNETS
Although there are several mixnets currently in use, this article will focus on problems with the two largest and most used: Tor, and I2P.
Tor
Tor has been the most used anonymous mixnet for the past 10 years. The Tor network maintains a high level of censorship resistance, and is a valuable tool for preserving internet privacy. Tor, however, is not a decentralised network. Tor is reliant on a group of “Directory Authorities,” which are centralised servers operated by a group of volunteers close to the Tor Foundation [1]. These Directory Authorities perform two main functions; they provide a list of all of the nodes so that users can create circuits, and they categorise nodes according to their speed (fast or slow). Nodes are given less or more responsibility based on these results.
This high level of centralisation means Tor can face attacks. In 2014, Tor received information of a credible threat to take down the Directory Authority servers [2]. Since the location of the Directory Authority servers is known, collaboration between the German and US governments or the US and Netherlands Governments would be enough to shut down five of the ten Directory Authority servers. A take-down of five or more Directory Authorities would result in a highly unstable Tor network, with new nodes being greatly diminished in their ability to interact with the network.
I2P
I2P takes a slightly different approach to a mixnet. I2P doesn’t use centralised Directory Authorities, it uses a “Distributed Hash Table” (DHT). A simplified explanation of how a DHT works is that each node holds a table that specifies every other node on the network, and how to contact them. This means no centralised authority is needed, which in turn offers less single points of failure. However, because of this weaker consensus model, nodes in I2P can hold different versions of the state of the network. This can create confusion when circuits are created and can result in unreliable circuits.
Unlike Tor, I2P lacks formal support for accessing the internet anonymously. I2P only formally allows for accessing internally hosted websites, which they call “Eepsites”. This has greatly reduced the ability for the I2P network to reach users whose main purpose for using anonymising networks is to access the wider internet. I2P is built so that the majority of users that connect to the I2P network also become nodes in the network. This is problematic as the resulting network often lacks sufficient bandwidth speeds to be able to build fast tunnel, and because the tunnel speed in I2P is bottle-necked by the least capable node, this results in reduced performance for the end user.
PROBLEMS WITH BOTH
Neither I2P nor Tor have fully mitigated Sybil attacks. A Sybil attack occurs when sufficiently motivated attackers (who have enough time and capital) buy large numbers of nodes in the system and perform attacks where traffic is correlated between nodes. This significantly decreases privacy [3]. Additionally, both networks are operated entirely by volunteers who donate both their time and money to the operation of nodes.
We believe that if the correct incentives are provided, networks like Tor and I2P can be grown and strengthened against attacks, and potentially provide a better service that extends beyond volunteering.
WHAT LOKINET DOES DIFFERENTLY
The combination of the Loki Service Node network and the underlying protocol of Lokinet (LLARP) provides a solution for the issues discussed with Tor and I2P. Lokinet operates without Directory Authorities and instead relies on a DHT built from blockchain staking transactions, which permissions each Service Node to act as a router on the network. In Lokinet, nodes are not sorted on performance by a centralised authority, but as the result of “Swarms” (groups of other service nodes) that assess each node and make judgements on their performance.
This process of decentralised registration in order to become a node on Lokinet also extends to de-registration. Lokinet enforces (by consensus) minimum standards for bandwidth, message storage and blockchain storage. This means when building circuits through the network of nodes, the speed at which packets will be sent and received will be much faster than other mixnets that still allow for slow nodes to route. Additionally, in Lokinet every Service Node also acts as an exit node allowing access to the wider internet, and not just internal services (which we call SNApps).
This high bandwidth low latency network architecture is achieved by not requiring Lokinet users to be nodes. Only Service Nodes (which, by their nature are proven to be high quality) are allowed to be connected to in the network. Lokinet actually disallows users to route packets in the system, meaning that Lokinet exposes a much lower attack surface for a Sybil attack due to the significant capital outlay required to begin Service Node operation. This means there will be a greatly reduced chance that privacy on the network will be compromised by correlation attacks.
Lokinet offers a strong array of incentives, more than any other mixnet currently in operation. Each Service Node is paid for the services they provide through block rewards, and instead of relying on volunteers, Lokinet relies on Service Node operators that are financially incentivised to act honestly and provide high levels of service to the network, increasing the value of their stake.
WHY DO I CARE ABOUT ANY OF THIS?
We can build a system that provides users with a way to access the internet and internally hosted sites, faster and more anonymously than ever before.
Powering this whole network is the Loki cryptocurrency which will also be implemented right into the Lokinet browser (similar to the Tor browser). Users who set up internally hosted sites will be able to accept payments anonymously and will also be contactable through the the Loki browser without ever having to leave the network.
HOW FAR ALONG ARE YOU?
Over the last 3 months, we have been working hard on LLARP (the underlying routing protocol).
For those curious about the acronym, it stands for, “Low Latency Anonymous Routing Protocol”. Currently most of the code is infrastructure code, and our progress can be seen here.
Lokinet is still quite a while away, and as always we will keep everyone updated on our progress. Additionally, if you’re a developer or a keen code monkey, please reach out to us or start contributing by making a pull request, issue etc. We have bounties set aside for open source development.
WHO IS WORKING ON THIS?
We’ve hired a couple of network programming specialists. First, we have Jeff, who has a lot of experience working on mixnets. You might have seen him roaming around in the Loki discord. He has worked on I2P extensively (specifically the C++ implementation of I2P called I2PD), and he also worked briefly on Kovri. Second, we have Ryan, who is a network application developer and has worked across a number of low latency streaming platforms with a focus towards network engineering. You can check out both of their github profiles below.
I WANT MORE DETAILS! GIVE ME THE PROTOCOL DEFINITION & THE DESIGN DOCS!
What a specific request… SURE! You can find both here, in the readme.
[1] “Tor Project: Docs.” https://www.torproject.org/docs/faq#KeyManagement. Accessed 12 Jun. 2018.
[2] “Possible Upcoming Attempts to Disable the Tor Network | Tor Blog.” 19 Dec. 2014, https://blog.torproject.org/possible-upcoming-attempts-disable-tor-network. Accessed 12 Jun. 2018.
[3] “Identifying and Characterizing Sybils in the Tor Network.” 25 Feb. 2016, https://arxiv.org/abs/1602.07787. Accessed 21 Jun. 2018.