[Video] Oxen Ecosystem: 2. Lokinet
2022 January 29
- Thoughts on the Oxen Ecosystem
This is the third video in a 5-video series on Oxen, Lokinet, and Session. This video is about Lokinet, a Tor-like anonymity network that runs on the the network of Oxen Service Nodes.
(majestrate's name is Jeff Becker. He doesn't list his name in his GitHub profile, which is why I call him by his username in this video.)
All original content in this video is dedicated to the public domain. Third-party resources included in this video are not necessarily public domain, but they fall into one of two categories:
- They are public domain or licensed under a license which permits commercial use without attribution.
- They are copyrighted works which I have not licensed but which I believe I am using in accordance with fair use.
Sources (in order)
- Tor Project. History. https://www.torproject.org/about/history/
- Tor Project. About Tor Browser. https://tb-manual.torproject.org/about/
- tommy. Introducing Bastet, Our New Directory Authority. https://blog.torproject.org/introducing-bastet-our-new-directory-authority/
- Tor Project. About Tor. https://support.torproject.org/about/#key-management
- The Invisible Internet Project. The Invisible Internet Project. https://geti2p.net/en/about/intro
- The Invisible Internet Project. Tor/Onion Routing. https://geti2p.net/en/comparison/tor
- Tor Project. Sybil attack. https://support.torproject.org/glossary/sybil-attack/
- R. Chirgwin. Tor takes aim against malicious nodes on the network. https://www.theregister.com/2016/02/29/tor_takes_aim_against_sybils_on_the_network/, February 2016.
- majestrate. LLARP – Low Latency Anon Routing Protocol. https://github.com/majestrate/llarp/blob/master/docs/high-level.txt
- The Oxen Project. Service Node deregistration. https://docs.oxen.io/using-the-oxen-blockchain/oxen-service-node-guides/service-node-deregistration#state-change-transactions
- The Oxen Project. Lokinet. https://docs.oxen.io/products-built-on-oxen/lokinet
- Oxen Project. Onion-routed video call demo (Lokinet). https://www.youtube.com/watch?v=SOdDoSt4Xdg
- The Oxen Project. FAQ. https://lokinet.org/faq
- The Oxen Project. How blockchains protect themselves from Sybil attacks. https://loki.network/2019/12/18/blockchain-protect-sybil-attacks/
- The Oxen Project. Oxen Service Nodes. https://docs.oxen.io/about-the-oxen-blockchain/oxen-service-nodes
- J. Ross, S. Harman, K. Jefferys. Loki Cryptoeconomics. https://loki.network/wp-content/uploads/2019/05/Loki_Cryptoeconomics-2-1.pdf
- The Oxen Project. Lokinet Exit Nodes: Onions Gone Wild. https://oxen.io/lokinet-exit-nodes-onions-gone-wild, November 2020.
- The Oxen Project. Oxen Name System (ONS): The Facts. https://oxen.io/oxen-name-system-ons-the-facts, March 2020.
- lokinet wiki. http://probably.loki/wiki/index.php?title=Main_Page
This video assumes you're already familiar with Oxen, specifically the network of Oxen Service Nodes and the Oxen Name System. These concepts will be referenced without explanation in this video.
In order to understand Lokinet, as well as why Oxen works the way it does, we first need to understand Tor and I2P.
The concept behind Tor, The Onion Routing system, goes back to the 1990s. Researchers at the United States Naval Research Lab designed a system called "onion routing" to protect privacy on an internet that offered none. Tor itself, a Naval Research Lab project that continued the work of the original onion routing design, was started in the early 2000s. It was called The Onion Routing (or Tor) to differentiate it from other onion routing projects being developed at the same time.
220.127.116.11. Onion Routing
Let's look at the basic idea of onion routing.
When you use the internet, you're connecting to other computers that are also connected to the internet. Often these are servers run to provide some service, such as a website. Normally, you connect directly to these computers. Suppose you visit a website by connecting to a server. This action produces certain data:
- Someone observing your internet traffic (such as your internet service provider or ISP) knows which site you're visiting.
- The server (or someone observing the server's internet traffic) knows who you are.
- If the traffic is unencrypted, an observer also knows what is being said.
With onion routing, you instead encrypt your traffic in layers of encryption, like an onion and route your internet traffic through multiple other computers (which we'll call "nodes") to obfuscate the connection. Now, let's look at who knows what:
- Someone observing your internet traffic only knows that you're sending encrypted data to the first node.
- The first node knows your identity and the identity of the next node, but it doesn't know which site you're visiting.
- The last node knows the identity of the previous node and which site is being visited, but not by whom.
- Any nodes in the middle (this will be 1 node for Tor) know only the identities of the previous and next nodes.
- The server (and its ISP) know the identity of the last node, but not your identity.
- As before, if the traffic itself is unencrypted, an observer also knows what is being said, but here the point where observation may occur is the connection from the last node to the server. Your own ISP can't read your onion-routed traffic.
Put simply, with onion routing, an observer might know 1. who you are, OR 2. what you're doing, but not both.
Tor is decentralized by design and available for anyone to use. It needs to be decentralized for it to work; if all the nodes you use are run by the same person, they can combine the data they know to deanonymize you. However, there is some centralization involved in the form of Directory Authorities – "dedicated servers which tell Tor clients which relays make up the Tor network". Tor nodes can be run by anyone, and users of the Tor network need to know which ones exist so they can use them for onion routing. By asking a hardcoded list of 10 directory authorities, Tor clients can get this information, making Tor quick and easy to start using. This centralization also helps Tor deal with Sybil attacks, which will be explained later.
18.104.22.168. Exit Nodes
Tor can be used to access the regular internet (which I'll call the "clearnet"), but it also has its own separate network of "hidden services". (I'll call this separate type of network a "darknet" because that's a common term, but it should be noted that that word carries a lot of baggage, and some people don't like it.) In the case of Tor specifically, these are also called "onion services", but I'll use the term "hidden service" here because we're also going to talk about them with other networks.
When you access a clearnet site using Tor, you create a circuit with 3 Tor nodes and route your traffic through that circuit. The last node in the circuit is called the "exit node" because this is where your traffic exits the Tor network.
To understand how hidden services work, consider the previous example where the client uses a circuit with 3 Tor nodes to obfuscate its traffic. This time, the server does the same. Now, we have the client, then 6 Tor nodes obfuscating the route, then the server. These hidden services can only be accessed through Tor, and they offer a number of advantages over clearnet services. For example:
- The server can be anonymous as well as the client.
- They're free and way easier to set up.
- They offer better cryptographic protections like mandatory end-to-end encryption and built-in authentication.
I2P, or the Invisible Internet Project, is largely similar to Tor, although the two often use different words for similar concepts. I find the best way to talk about I2P is to explain how it's different from Tor. I'll focus here on properties that are actually relevant as background on Lokinet, so look up I2P yourself if you want to learn more about it in general.
I2P uses "garlic routing" rather than "onion routing". The differences between these two things are outside the scope of this video, but understand that if I refer to garlic routing in this section, it's like onion routing.
I2P's design is more decentralized than Tor's. The first time you connect to I2P, you have to ask one of the central "reseed servers" for more information about the network, but from then on, you discover more nodes through "exploratory" tunnels. Furthermore, Tor creates a separation between volunteer-operated nodes for routing and clients which route their traffic through these nodes, while I2P encourages regular users to also serve as nodes in the network. This contributes to the decentralization and anonymity but also means there are a lot of low-performance nodes slowing down the network.
22.214.171.124. Exit Nodes
I2P is specifically intended for using hidden services, not for accessing the clearnet. There exist exit nodes which allow you to access the clearnet, but these are centralized services, and I2P is not optimized for these. Connecting to the clearnet using I2P looks like this: You construct a regular hidden service connection: the client, then 6 I2P nodes, then the I2P exit. Then the exit connects to the clearnet server.
126.96.36.199. Protocol Support
Without getting into too much technical detail, I2P supports more types of internet traffic than Tor does. I2P supports applications like BitTorrent and audio calls which are not properly supported by Tor.
2.1.3. Sybil Attacks
Like I said before, if all the nodes you use are run by the same person, they can combine the data they know to deanonymize you. If someone controls a large percentage of the nodes on the network, then it is likely that multiple of their nodes will be selected when building a circuit. A Sybil attack is when someone sets up a bunch of nodes to gain influence over the network, such as in this way.
Tor has some defenses against this type of attack, but they harness the centralized directory authorities. I2P's ability to defend against Sybil attacks is very limited.
In 2017, majestrate, a developer and blogger involved in I2P and other similar projects, started a new project called LLARP, or Low Latency Anon Routing Protocol. The goal was to take the good parts of Tor and I2P and not the bad parts.
Here are some key properties LLARP tries to take from each:
- majestrate wanted the decentralization of I2P without Tor's centralized directory authorities.
- majestrate wanted Tor's separation between users and servers (or nodes). It makes the network easy to use and performant. "This promotes a healthy network shape of high capacity servers serving low capacity clients that "dangle off of the side" of the network."
Here are some key properties LLARP wants to avoid from each:
- I2P used outdated cryptography which was taking a very long time to update.
- I2P could not protect against Sybil attacks.
- Tor only supported certain types of internet traffic, which limited its usefulness, especially for real-time communication.
majestrate stated that another goal was allowing LLARP hidden services to be accessed from the clearnet and allowing clearnet access over LLARP.
Lokinet is the reference implementation of LLARP which seeks to fulfill these goals. Lokinet runs on top of Oxen, using the Oxen Service Nodes as the nodes for the network. Let's explore how each goal can be met this way.
Lokinet inherits decentralization from Oxen's blockchain. Oxen Service Nodes are registered, deregistered, etc. through the publication of transactions, so anyone can query the public blockchain to learn which Service Nodes are available to use. There's no need for central directory authorities.
(Of course, Lokinet is only as decentralized as Oxen is.)
188.8.131.52. Separation Between Users and Servers
By using Oxen Service Nodes, Lokinet provides servers that users can connect to without having to run their own nodes. Also, Oxen Service Nodes are required to perform well, and they are rewarded for their service. (In fact, the Oxen team recently demonstrated that it is possible to have an onion-routed video call using Lokinet!) This is not the case with Tor and I2P, where nodes are run by volunteers or users, and the networks can be very slow and error-prone.
By just being built as a new thing, Lokinet avoids the baggage of existing code with outdated cryptography.
Lokinet supports all types of internet traffic.
184.108.40.206. Protection Against Sybil Attacks
The use of Oxen's blockchain is intended to protect Lokinet against Sybil attacks by making them expensive.
There are two arguments for why a proof-of-stake system should be resistant to Sybil attacks:
- When dishonest nodes are detected by the network, they lose part of their stake and the ability to stake in the future. This means the costs of acting dishonestly exceed the rewards.
- Since you have to have at minimum 3,750 $OXEN for each node you run, launching a Sybil attack requires a well-funded adversary. Additionally, according to Oxen,
[A]s an attacker accumulates $OXEN, the circulating supply decreases, in turn applying demand-side pressure and driving the price of $OXEN up. This effect spirals, making it increasingly costly for additional $OXEN to be purchased and thus making an attack prohibitively expensive.
To maintain this protection, Oxen encourages active suppression of the circulating supply. In particular, the emissions curve and staking requirement have been designed to ensure enough circulating supply is locked (and reasonable rewards are provided to operators) to ensure Sybil attack resistance.
I'm a computer scientist. I'm not going to pretend to understand economics well enough to evaluate this claim. There's a paper on Oxen so-called "cryptoeconomics", if you're interested in reading about it yourself.
220.127.116.11. Exit Nodes
In terms of exit nodes, Lokinet works like I2P: By default, it's only used to access hidden services (which Lokinet calls SNApps or Service Node Apps), but there are also centralized exit nodes which provide a gateway to the clearnet. Since Lokinet can carry any type of traffic, this allows Lokinet to be used like a VPN.
As far as I'm aware, there is not yet a way for users of the clearnet to access Lokinet sites without themselves using Lokinet.
18.104.22.168. Lokinet and ONS
Domains on Lokinet are long and difficult to type and remember. Users can optionally register shorter domain names which map to these longer names. Lokinet domains, unlike Oxen wallet and Session usernames, are not permanent and must be periodically re-registered. This is to prevent domain squatting and to make domains available again in the event that someone loses their keys.
2.2.2. Using Lokinet
Now that we know what Lokinet is, let's look at actually using it.
In practice, Tor and I2P are run on the system as proxies. Individual applications such as web browsers can then be configured to route all traffic through these proxies, which provides some protections. Since Tor is designed to work with clearnet traffic, if you visit a clearnet site in a Tor-enabled browser, your connection to that site is routed through a Tor circuit. Since I2P does not support clearnet requests by default, it simply blocks these request.
Lokinet, on the other hand, is configured system-wide. The default behavior is to route only traffic to and from .loki domains through Lokinet and let the system handle all other types of traffic as per usual. This feels very dangerous to me. If a user doesn't use an exit node to route their clearnet traffic through Lokinet as well, a loki site can trivially determine their real IP address by including third-party clearnet content on the site.
Lokinet is a relatively new network, and there's not a lot of content on it yet. There's a Lokinet wiki on probably.loki, which lists some sites. So far, there's nothing that particularly interests me that isn't also available on other networks, but that may change with time.
Lokinet with an exit node works like a VPN: all traffic is routed through an onion-routed connection to the exit node. Currently, there are only 4 public exit nodes that I'm aware of. Torrenting is possible using these exit nodes. It's not obvious what happens if the connection to the exit node drops or the proper way to set up a killswitch. This also makes Lokinet feel unsafe to me.
So far, I don't have a lot of use for Lokinet, but I think it has potential.
To recap: Lokinet is an anonymity network which seeks to solve issues with Tor and I2P. It aims to resist Sybil attacks by using the Oxen network, where running a node is expensive.
In the next video, we'll look at the encrypted messaging app Session.