Privacytools.io: 🆕 Software Suggestion | Lokinet

[KeeJef]

Basic Information

Name: Lokinet
Category: Self-contained Networks
URL: https://lokinet.org , https://github.com/loki-project/loki-network

Description

Lokinet is a public, open source, free-to-use onion router designed to facilitate anonymous IP packet transfer at the network layer.
The quickest way to understand Lokinet is by drawing a comparison to Tor, which I assume most readers of this issue will be familiar with.

OSI Layer

Tor - Transport layer - only routes TCP packets, which means Tor cannot provide anonymity for gaming protocols, streaming protocols, VoIP, and many other protocols built on top of UDP.
Lokinet - Network layer - Will route any transport layer protocol, including TCP, UDP, and others, which allows a much wider range of protocols to be routed.

Public routing network

Tor - Allows any party to run routers in the network; routers are run voluntarily without rewards given.
Lokinet - Routers can only be run by those who "stake" Loki cryptocurrency into the network. This creates a significant financial barrier to running a large percentage of the routers in Lokinet. Routers are rewarded financially for staking and providing service to the network. (Note: users do not need to buy or hold cryptocurrency to use Lokinet).

Network Structure

Tor - Network is centralized around the directory authorities, which measure bandwidth, assign flags, and distribute the list of available routers (the consensus).
Lokinet - Network is decentralized, registration is governed by a blockchain, and the network is self-policing: routers autonomously kick other non-compliant routers from the network.

Method of use

Tor - Provides a local SOCKS proxy for users to connect applications to; if an application does not natively support the specification of a proxy then a shim may be used, forcing the application to use the local SOCKS proxy.
Lokinet - Installs a local DNS resolver which automatically resolves requests to the .loki TLD; if an application supports hostnames it should support Lokinet without any modifications or shims.
For example, if Lokinet is running, Git clients (Tested Fork, Github Desktop and CLI Git) can use this Lokinet git repo normally, with no configuration changes: http://git.f59q8xa7m3bmkfi11oijuh4w77ar49hgx8pdexoqonehcywnifsy.loki/ .

Exiting the network

Tor - Large network of volunteer run Exit Nodes.
Lokinet - No public Exit Nodes as of 02/06/2020; however a market-based exit network is currently being built. This means Lokinet currently only supports SNApps (the equivalent of Tor Onion Services/Hidden Services).

---

If you want to test Lokinet, download it here https://lokinet.org/ and visit the Lokinet Wiki here http://dw68y1xhptqbhcm5s8aaaip6dbopykagig5q5u1za4c7pzxto77y.loki/wiki through any web browser. On the wiki, you can see some of the websites and web services that have been added to Lokinet. Be aware that other local DNS resolvers like DNSCrypt or VPNs may interfere with Lokinet.

Further documentation is somewhat limited at the moment, but we are working on the completion of a whitepaper, which I will post here once completed. I am happy to answer any further questions you might have.

Why I am making the suggestion

Lokinet is an important tool that can help to protect user and server privacy online. Lokinet offers specific advantages when compared with other privacy-preserving self contained networks.

My connection with the software

I am the CTO of the Loki Project, which is the primary entity developing Lokinet.

• [x] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

[lrq3000]

Congratulations on launching the lokinet network! I'll test that out when I get some spare time, very interested into seeing what are its capabilities and performance from a user POV :-)

[blacklight447-ptio]

Has onion routing been launched yet?

[lrq3000]

@blacklight447-ptio Yes, following up on their planned schedule laid out in January.

[lrq3000]

And from the last link (the plan in January), I get that Session only supports TCP communications for now. But UDP support is planned (or maybe already implemented?) and Lokinet does already support both.

[KeeJef]

Hey @lrq3000 and @blacklight447-ptio , onion requests on Session and Lokinet onion Routing are different things. onion requests (3 hop) are turned on in Session, and onion routing, on Lokinet has been turned on and working for a while now.

Session onion requests use a modified ZMQ interface to send all requests and posts for messages through a number of hops, ZMQ does not really support the transmission of UDP packets. Session onion requests still use the Service Node network.

Lokinet onion routing, is on a lower level of the OSI stack, establishing network layer tunnels which allow for the transmission of any IP based packets. Lokinet onion routing uses the same routers as onion requests do.

The main reason we have built two onion routers is that integrating Lokinet in mobile platforms is much trickier than integrating onion requests. Mobile platforms require we integrate with the VPN API and port parts of the C++ Lokinet code to natively on each mobile OS. This is the long term plan since it will add the ability to use Lokinet on a phone and also add the ability for Session to make voice calls, however its easier for us right now to use onion requests because of their relative simplicity.

[lrq3000]

@KeeJef Thank you for the clarification! Just an additional question: can Lokinet onion routing have more than 3 hops then?

[KeeJef]

Thank you for the clarification! Just an additional question: can Lokinet onion routing have more than 3 hops then?

Yes hops are fully configurable through the lokinet.ini file for SNApps and clients, although in most cases the defaults are sensible and shouldn't be changed without knowing what the potential affects on privacy are.

[subsys-R9boq8]

The financial status of Lokinet and Loki Foundation sounds a bit strange for me. On the official Loki Network Team Page it showed several capital funding companies. This also raise suspicion to other privacy enthusiasts.
In what level can those capital funding companies affect the decision of Lokinet dev. (and probably the decision) team, or are they just investors with no real power to make decisions in the Loki Network dev./decision team? This should be considered with care and with thorough background investigations, if necessary.

[subsys-R9boq8]

For the political stand of the main dev. (discussed here in #1678 ) , to be frank, I don't quite care. The software should be viewed separately from the developer's political point of view, as long as the dev.'s political standpoint does not affect the quality and trustworthiness of the software/code.

[KeeJef]

@subsys-R9boq8 Funding was received from a number of venture capital firms for the presale of the Loki cryptocurrency, which underlays the Sybil resistant properties of Lokinet. However the presale was conducted over 2 years ago the Loki Foundation as i understand it has no ongoing financial , legal or shareholder ties to any of these venture capital firms. Speaking from the role of CTO we value all community feedback including investor feedback the same, we would never change the direction of Session or Lokinet because a VC firm or large investor told us to do so.

[subsys-R9boq8]

Lokinet's Whitepaper
Provided some interesting viewpoint, maybe useful for research.

[KeeJef]

@subsys-R9boq8 thats not quite the Lokinet whitepaper, its the Loki whitepaper which does touch on the general idea of Lokinet but only really goes into a small amount of detail about it, we have another paper specifically focusing on Lokinet but its still under development.

[majestrate]

Lokinet - Network layer - Will route any transport layer protocol, including TCP, UDP, and others, which allows a much wider range of protocols to be routed.

a clarification, lokinet supports basically anything that can be put into an IP packet. however some upper layer protocols may not play nice because it assumes both ends have the same IP addresses. This is not the case in lokinet as a user defined local ephemeral range is used and upper layer checksums are rewritten to make it work. We have this for TCP, UDP and ICMP but not SCTP as that is a lot more work and no one has complained loud enough about supporting it (yet). GRE does not need any upper layer checksum rewrites.

Things that do work over lokinet without modifications (and that i have tested):

• ssh
• http
• smtp
• nntp
• irc (no dcc)
• mumble (i use this every day and the latency is usable)
• openvpn
• GRE tunnels (IP, IPX, etc)
• tor (with bridge node w/o exit and defaults using exit)
• i2p (using exit)
• lokinet (using exit, and yes you can nest this a few times)

Things that would probably work without modifcations (that i have not tested yet):

• sip
• ipfs
• xmpp

Also, a list of application protocols that won't work without a protocol fork (which can be done):

• ftp
• bittorrent
• direct connect
• irc xdcc
• webrtc