🆕 Software Suggestion | Lokinet #1940
Labels
No Label
🔍🤖 Search Engines
approved
dependencies
duplicate
feedback wanted
high priority
I2P
iOS
low priority
OS
Self-contained networks
Social media
stale
streaming
todo
Tor
WIP
wontfix
XMPP
[m]
₿ cryptocurrency
ℹ️ help wanted
↔️ file sharing
⚙️ web extensions
✨ enhancement
❌ software removal
💬 discussion
🤖 Android
🐛 bug
💢 conflicting
📝 correction
🆘 critical
📧 email
🔒 file encryption
📁 file storage
🦊 Firefox
💻 hardware
🌐 hosting
🏠 housekeeping
🔐 password managers
🧰 productivity tools
🔎 research required
🌐 Social News Aggregators
🆕 software suggestion
👥 team chat
🔒 VPN
🌐 website issue
🚫 Windows
👁️ browsers
🖊️ digital notebooks
🗄️ DNS
🗨️ instant messaging (im)
🇦🇶 translations
No Milestone
No Assignees
1 Participants
No due date set.
Dependencies
No dependencies set.
Reference: privacyguides/privacytools.io#1940
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
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 :-)
Has onion routing been launched yet?
@blacklight447-ptio Yes, following up on their planned schedule laid out in January.
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.
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.
@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.
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.
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.
@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.
Lokinet's Whitepaper
Provided some interesting viewpoint, maybe useful for research.
@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.
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):
Things that would probably work without modifcations (that i have not tested yet):
Also, a list of application protocols that won't work without a protocol fork (which can be done):
Lokinet has been rebranded to Oxen, as stated here.
Actually Lokinet is likely to stick with the name Lokinet, its just Loki, the cryptocurrency powering the Lokinet routing network will become Oxen.
Okay.
Lokinet/Session is based in Australia, which makes it a non-starter for PrivacyTools.io thanks to it's 2018 Access and Assistance Bill (AKA gov can force them to introduce vulnerabilities into their encryption tech and not disclose this) as well as the likely forthcoming Identify and Disrupt bill which allows hijacking darknet providers accounts (like Lokinet) if authorities believe serious crimes are taking place on it (i.e. every darknet provider in Australia is at risk).
Interesting
That forcing vulnerabilities is definitely a risk, though i'm not sure how doable that is with an open source app, like that would get noticed (does session have reproducible builds?). There needs to be kept an eye on this though.
Also, while lokinet is the developer of session, the network is not owned by them and run by volunteers, this together with the onion routing makes a network take-over unrealistic
Your interpretation of the Assistance and access bill is not consistent with our reading, and legal advice on the matter, you can read our full response here https://medium.com/hackernoon/lokis-response-to-the-assistance-and-access-bill-2018-f2a0143a584e
This bill has no particular relevance to our operations, we don't act as a centralised party in Lokinet which collects information on our users, so these powers don't really affect us. These bills seem to be designed to target SNApp or .Onion service operators, something which various governments around the world already do.
I'll also add to this that currently none of the Lokinet developers live or work in Australia, the Lokinet developers are based primarily in North America, its unclear to what degree any of this legislation would apply to them.
If given the order to add a backdoor I would most likely abscond to an off grid hideyhole and continue development from there if possible.
Fair enough it doesn't require breaking encryption, but you admit they can still force installing monitoring tools and gag orders on top of it:
"This bill does not require these companies to break the encryption of their systems, but there are plenty of other things these agencies could force companies to create and install, such as tools that would allow them to remotely pull information from a specific user’s device post-encryption, or gain access to these services’ servers where treasure troves of metadata could be harvested. Every ‘private’ messaging application out there could now be forced to send data back to intelligence agencies about who is communicating to who and when the communications are taking place."
I'd argue a keylogger or secret video recording are additional monitoring methods that could be forced and would compromise message content too without "breaking encryption".
My read on this is different, by being a provider of darknet technology you'd still be affected even if you do not host all of the nodes in the network. That said this would need a lawyer to breakdown the wording better when the bill is finalised to see how far it actually goes.
Management however can be compelled still as long as the organisation is based in Australia.
Whilst I think the model you've constructed your software under is the best that it could be invented for the threat model of a privacy-hostile government, I do hope you reconsider a different jurisdiction for operating out of.
Maybe a dumb question, but isn't this legislation applying to any communication service provider with a user investigated in Australia? Ie, doesn't this equally applies to Signal, Element, WhatsApp and others?
We hold no privileged position in the network, so where would the monitoring tools be installed without causing a systemic weakness? The only possible place I could think would be adding logging on the Lokinet website to collect users IP addresses when they download the Lokinet application, but beyond that you never connect to a centralised service again. Even then you don't have to get Lokinet through our website there's releases through the .deb package and Github.
I don't understand what your point is here? we can't be forced to include a keylogger/screen recorder in any of our apps, that would clearly meet the definition of a "Systemic Weakness" under the Assistance and Access bill which the legislation does not allow, and functionality like that would never get merged into the Lokinet codebase without the USA based devs or community contributors noticing and promptly forking the project and telling the media.
The Identify and Disrupt bill gives Police new types of warrants to target entities that have meaningful data or hold a privileged position in a network where they can monitor inflows and outflows of traffic. We don't have a privileged position in Lokinet, we don't see any of the traffic flowing between users and SNApps, that's all dealt with by the decentralised network of ~1800 Service Nodes.
Compelled to do what? The management team doesn't have the capacity to secretly install keyloggers into Lokinet without contributors noticing on Github, primarily the North American devs who review every PR that goes into Lokinet would immediately reject PR's to include a keylogging system.
For all intents and purposes right now the Lokinet team operates out of North America, management can't just tell NA devs to install keyloggers. I'll note also that USA and Canada are also privacy hostile countries, but that doesn't prevent developers creating well designed software which is somewhat impervious to stupid legislative attempts to re-centralise government power
About forcing install of keyloggers, Germany may pass a bill tomorrow to force the indiscriminate inclusion of trojans in softwares and potentially forcefully delivered through automatic updates: https://www.reddit.com/r/privacy/comments/nvy38l/germany_is_about_to_pass_a_law_that_allows_german/
Reproducible builds may become a necessity to circumvent that and future similar attacks by other countries.