Jun 22, 2018
LOKINET
Loki’s Exploration into the Onion Routing Space
Note: This article was edited on Thu 27 Feb, 2020, to address the incorrect use of the term ‘mixnet’ in place of ‘onion router’. Our previous classification of Lokinet as a mixnet was incorrect. We apologise if this caused confusion or suspicion in the community, and we will strive to ensure we publish accurate information in the future.
We’ve been dropping some not-so-subtle hints that we have been working on a decentralised onion routing solution, and it’s finally time to reveal what we’ve been working on. This article, along with the soon-to-be-released version 3 revision of the Loki whitepaper, will get everyone up to speed on Lokinet.
Onion what-now?
An onion routing network is a form of overlay network that operates on top of the internet. You might have heard of Tor — well, Tor stands for The Onion Router, and it’s the largest onion routing network to date. So what’s the idea behind onion routing? 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 anonymous internet browsing very difficult. Online services that you connect to can use your IP address to work out your general location, and state-level actors can use legal processes to retrieve your IP address from web services and connect that address to your real world identity.
The solution to this problem is onion routing. Onion routing works 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 onion routing, 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, when you use an onion router, 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, which means they do not know who you are. This limits the information that even dishonest nodes can gather about you when you use an onion router.
Loki is building its own onion router.
Why? There are perfectly good onion routers out there right now, why don’t I just use those?
Well…
The problems with current onion routers
Although there are a number of onion routers currently in use, this article will focus on problems with the largest and most used: Tor. We will also discuss certain issues with I2P, another type of anonymous browsing overlay network.
Tor
Tor has been the most used onion router for more than 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). Based on these results, nodes are given more, or less, responsibility.
This high level of centralisation makes Tor vulnerable to attacks. In 2014, Tor received information of a credible threat to take down the Directory Authority servers [2]. Because the location of the Directory Authority servers is known, collaboration between the German and US governments, or the US and Dutch 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 significant instability of the Tor network, with new nodes being greatly diminished in their ability to interact with the network.
I2P
I2P takes a slightly different approach. Instead of using centralised Directory Authorities, I2P uses a “Distributed Hash Table” (DHT). In a nutshell, using a DHT means 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 means fewer 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 (i.e. exit node functionality). I2P only formally allows for accessing internally hosted websites, which they call “Eepsites”. This makes I2P significantly less useful for users whose primary intention is to browse the clearnet anonymously.
Another issue with I2P is that I2P is built so that the majority of I2P-connected clients also become nodes in the network. This is problematic because the resulting network often lacks sufficient bandwidth speeds to be able to build fast tunnels. Consequently, 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 collect information about all traffic passing through those nodes, significantly decreasing user 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, a network similar to 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 LLARP, the protocol on which Lokinet is built, provides solutions for the Tor and I2P issues discussed above (see below for more on LLARP). Lokinet operates without Directory Authorities and instead relies on a DHT compiled from blockchain staking transactions. These staking transactions permission each Service Node to act as a router on the network. In Lokinet, nodes are not sorted on performance by a centralised authority, but instead sorted by “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, through consensus, certain minimum standards for bandwidth, message storage, and blockchain storage. This means that when circuits are built through the network of nodes, packets will be sent and received significantly faster than on other onion routers that allow for slow nodes to route. Additionally, in Lokinet, every Service Node will eventually act 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 user clients to be nodes. Only Service Nodes (which by their nature are proven to be high quality) are allowed to be connected to the network. Lokinet actually disallows users from routing 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 initialise a Service Node. This translates to a greatly reduced chance that privacy on the network will be compromised by traffic correlation-type attacks.
Lokinet offers a strong array of incentives, more than any onion router currently in operation. Each Service Node is rewarded for the services they provide through receipt of a portion of Loki block rewards. Instead of relying on volunteers, Lokinet relies on Service Node operators who are financially incentivised to act honestly and provide high levels of service to the network, in order to increase the value of their stake.
Why should I care?
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.
Driving this powerful network is the Loki cryptocurrency, which will be implemented within the Lokinet browser (client software for accessing the network, similar to the Tor browser). Users who set up internally hosted sites (SNApps) will be able to accept payments anonymously, and these SNApps will 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 (Lokinet’s foundational routing protocol).
LLARP 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, 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’s working on Lokinet?
We’ve hired several network programming specialists. First, we have Jeff, who has a lot of experience working on onion routing protocols. 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 who has worked on 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 and 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.
