🆕 Software Suggestion | Session (ex-Loki Messenger)

[lrq3000]

Basic Information

Name: Session (ex-Loki Messenger) Category: Encrypted Instant Messengers - Decentralized URL: https://getsession.org/ Platforms: Desktop (Mac, Linux, Windows), Android, iOS

Description

Session (new name of the Loki Messenger) is an anonymous text messenger initially forked from the Signal messenger but completely reworked 3-hops onion routing protocol on top of asymmetrically encrypted messages to anonymize all interactions. E2EE is always enabled and only lokinet users can be contacted through the app. Supports 1-on-1, private groups and public rooms text chats. No phone number nor any private information is required to register. App is cross-platform, available on Windows, Linux, Android, iOS. All open-source, including clients.

In the future, Session will migrate to the Lokinet network (ex LOKI blockchain), a blockchain initially forked from Monero which works over a LLARP (Low Latency Anonymous Routing Protocol) onion routing layer using faster UDP packets, that will allow voice calls. Indeed, Session currently only supports text messages for now due to using a TCP onion routing, but voice calls and maybe video are planned for later after migration to Lokinet (but no exact date planned)). It seems the blockchain is already online since years, but it's still in beta due to the LLARP protocol being tested out, whereas the blockchain technology used is relatively well established, the LLARP protocol is new and needs to be ironed out.

Why I am making the suggestion

Seems like a concurrent to BCM #1662, but it is entirely opensource (here for the messenger). The LLARP onion routing protocol is explained here and compared succinctly to TOR and I2P here (TL;DR: the goal is to retain the strong anonymity and security guarantees of both networks but with faster speed and easier network management - I can't describe more precisely as I am no expert). The messenger (Session) is discussed here. Blokt and SecureChatGuide reviewed it last year under beta (it still is but seems to be soon reaching the first stable release).

I think the messenger is the most directly useful part of the project right now, and hence the focus of this ticket, but the LOKI/LLARP network could also be added as an entry in Self-contained Networks (as suggested before #924) if someone with more expertise than me can understand the provided docs.

/EDIT: a technical preprint is available since 11/02/2020: https://arxiv.org/abs/2002.04609

/EDIT: Session's code was independently audited in April 2021: https://getsession.org/session-code-audit/

My connection with the software

No link, I am just interested in privacy protecting networks.

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

[subsys-R9boq8]

We have never actually used Firebase analytics in a production version of the application, these static code analyzers seemed to be picking up the inclusion of the Google Firebase library (Used for FCM) as and flagging that, but as of last week we have excluded those parts that were getting flagged by Exodus and now we are passing https://reports.exodus-privacy.eu.org/en/reports/network.loki.messenger/latest/.

You can see the PR here loki-project/session-android#219

Regarding FCM for push it is only ever used if the user opts in to use it,and there is a big onboarding screen explaining the consequences/benefits, you can use Session Google free if you just use background notifications.

Just checked the latest release and it's free of Firebase Analytics, thanks for the clarification!

[ph00lt0]

thanks for clarifying @KeeJef

[net-zero-day]

Seems ok, the only thing I don't trust is that it's based in Australia. https://loki.network/2018/12/10/lokis-response-to-the-assistance-and-access-bill-2018/

[th3m]

A political view research regarding the loki network, that i believe it's important to be mentioned and taken into account: https://nitter.net/WPalant/status/1281540005190672384

[dngray]

I did look at the ABC article. It looks to be a similar situation to where the Tor Project find itself. Bad people can use good technology?

As we really don't know what was said, we can never determine to what extent "they helped". The word "inadvertent", might reflect they did not know who they were before helping them.

This German-language video shows Loki Network's main developer (Jeff/majestrate) pitch his baby on 8chan and being celebrated by the alt-right for it (at 27:46). For reference, Loki Network is the foundation of Session and developed by the same startup.

I did watch that video, and the only reference was this frame:

How do we actually know it was written by @majestrate and not copy pasted from somewhere else?

[lrq3000]

I am not convinced by the point raised either. First because I don't see any proof, only claims in the linked twitter thread, but also because that's basically the timeless security vs liberty philosophical and political problem. For example, medicine has always been used to conduct unethical experiments including torture or worse. This unfortunately shows that even the most honorable tools can be misused. Should we blame the tool, or the user who misuse?

IMO, the technical side also matters in this question. I think that as long as the tool is not operated by the developer and is opensource, who the developer is is ultimately irrelevant.

PS: thank you for making me discover nitter, didn't know this open front-end to Twitter, I guess we should re-examine #1402 now that Invidious is being added as a Worth Mentioning in #1974?

[subsys-R9boq8]

Guys, some of you have gone OT for very far, any issues that relate more to LokiNet than Session should be discussed at #1940 (Lokinet) but not #1678 (here).

[majestrate]

just to die up a loose end (further mud flinging can go into #1940 )

How do we actually know it was written by @majestrate and not copy pasted from somewhere else?

the aforementioned post was on a former contributor's imageboard, and since imageboards love to steal each other's style sheets it makes sense that it was confused with 8chan. original post from the screenshot is from https://endchan.net/tech/res/12870.html

[dngray]

@majestrate thanks for clarifying that. I got this feeling from that CCC speaker that it felt like he just wanted to show a bunch of alt-right propaganda/meme/shock material to viewers, I think it could have done with a lot less of that and still gotten his point across.

We should get this back on-topic.

[subsys-R9boq8]

I might have missing some function, but I didn't see anything like Signal's "safety number". Why is that? Can session or the lower LokiNet platform prove that I am talking to the person with no insider interference (Like MITM), or is the platform naturally immune to this kind of attack?

[KeeJef]

@subsys-R9boq8 We do have the ability to view a users safety number on desktop, it should be on all platforms, not sure why it got removed. However the security model is quite different than Signal, since Signal users can change their underlying key pairs without breaking a session (Phone number is ultimate truth) whereas your identity (SessionID) in Session is actually your public key meaning you cant change it.

This means that if you talk to someone with X session ID, you know you are speaking to them and there is no TOFU or MITM attack possible (as long as the out of band Session ID sharing is done properly). However it still makes sense to have safety numbers because someone out of band might claim to be X person when they are Y person, if you speak to X person in real life or through some secure means then you can either compare Session ID's or safety numbers, however safety numbers are a little easier to compare (Have a QR code and nice formatted representation)

[ghost]

Why are you using legacy GPG version 1.4? https://github.com/loki-project/session-android/releases

[KeeJef]

@ZarusMods No particular reason, is there a compelling reason to update? CVE or something?

[LorisTecnology]

i use it is great and is even better now that have added multi device sync

[ghost]

Session's code audit is done: https://getsession.org/session-code-audit/

[KeeJef]

I don't think Session should be omitted from the Privacytools.io site, just because it doesn't have voice calls, there are a few things that we want to do before recommending that Session is listed on the site

• The app is added to F-Droid
• The cross platform refactor is finished (This is about 2-4 weeks away) this will vastly improve message sending reliability, especially when dealing with multi device functionality
• Full three hop onion routing is enabled in Session, instead of one hop proxy routing.
• Closed group size is expanded

All of this is finished now, took us a lot longer than expected 😂 Session is now much less buggy than it was a year ago, i don't know exactly how this process works but i think moving forward on further research or putting a recommendation into https://privacytools.io now would be great

[lrq3000]

Thank you for the update @KeeJef. Very exciting news! I'm very happy to see this much progress and work!

Adding on privacytools is on a volunteer basis, so it just depends on whether someone decides to make the adequate file modifications and then if peers accept the changes after review.

I have a few questions before I see if I can make the changes:

1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance).
2. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route.
3. Who runs the nodes used in the onion routing?
4. Do you have an estimation for the migration of Session onto the Lokinet network?

[lrq3000]

Also BTW I have tested the app both on desktop and Android, and I must say the stability and reliability has indeed vastly improved, same for the registration process which creates a private key very easily and transparently, so I can confirm the app is ready for non-technical end user use as a text messenger (voice calls not available until Session migrates to the Lokinet network using UDP instead of TCP). It also now supports both public and private groups.

The app on Android also asks on registration or first launch whether to use Google notification servers or not, in the latter case the notifications aren't immediate as the app needs to fetch updates itself, but it fully protects all metadata then. Very nice to have implemented this suggestion :D

@KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.

[KeeJef]

1. I see that the 3-hop onion route can be displayed on mobile (tested on Android). Is it possible too on desktop? Showing the route is imho necessary for transparency and it reassures the user (and also can allow to debug and assess one's own threat model - eg, if the route is not satisfactory because passing through countries that the user may deem dangerous in terms of surveillance).

Yes, its actually something that we have an intern assigned to now, this issue should track progress https://github.com/oxen-io/session-desktop/issues/1492

2. Is it possible to change the route if the user deems it unsatisfactory? It's not necessary to be able to pick up exactly the route we want but just to be able to force a change, reshuffling the route.

Theres no button in the app to do this, since we tend to prefer to continue to use good random routes rather than rotate users into potentially unstable routes, and depending on a users preferences for route selection allowing then to change their route could offer potential for some more subtle attacks.

3. Who runs the nodes used in the onion routing?

Routers are Service Nodes in the Oxen blockchain network, the number of nodes and distribution can be found here https://oxendashboard.com/#5

4. Do you have an estimation for the migration of Session onto the Lokinet network?

Its going to take some time, we have just finished the core of liblokinet which should allow the mobile applications to more easily integrate with Lokinet, but its still going to take work, so its hard to give an estimation. For now we are OK continuing to use Onion requests, but we will need Lokinet integration for features like voice calling.

[KeeJef]

@KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.

Hmm this might be something we look into, if you wanted to file an issue for that we could look at it in an upcoming release

[lrq3000]

Ok thank you for your clarifications. I think it's time to make a PR, we'll see what the peer reviews says.

To mabe my job easier, could you please clarify the following:

About forcing a new route, i meant to do something like Tor Browser is doing, such as simply relaunching the whole client to force generate a new random route. I understand the security issuks otherwise. The issue you linked to already asked for this feature for performance reason (ie, unreliable network) instead of security but implementing it will fit both.

About the nodes, i can see thad they are well distributed over the world, nice charts. Can you precise who are currently running these nodes? Users of the Oxen blockchain who are incentivized by the proof of stake algo or are most nodes yours at the moment?

Finally, could you please clarify how the whole ecosystem is connected and what each piece is doing in the big picture? Before i think lokinet was supposed to be the blockchain and llarp combined, but now it seems that Oxen is the blockchain which provides TCP onion routing and encryption , Lokinet which will be the llarp fast udp onion network that will work in tandem with Oxen. Session uses Oxen only for now and in the future will use both Oxen and Lokined, switching transparently when fast data transfer is needed. Is that an accurate overview?

Le mar. 11 mai 2021 à 05:49, Kee Jefferys @.***> a écrit :

@KeeJef https://github.com/KeeJef I have one suggestion about the registration process on desktop, it doesn't require the user to copy/save the private key as it does on mobile, so non technical users may unknowingly lose their account if they create one on desktop and aren't aware of how blockchains work.

Hmm this might be something we look into, if you wanted to file an issue for that we could look at it in an upcoming release

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/privacytools/privacytools.io/issues/1678#issuecomment-837745751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIRFXUONJAQBF4IWYSVPPLTNCSLDANCNFSM4KOP2STA .

[KeeJef]

About the nodes, i can see thad they are well distributed over the world, nice charts. Can you precise who are currently running these nodes? Users of the Oxen blockchain who are incentivized by the proof of stake algo or are most nodes yours at the moment?

The vast majority of nodes in the network are run by community members, the largest single operator of Service Nodes in the network is the OPTF who runs about ~9% of the networks Service Nodes. Anyone can start a Service Node and begin earning rewards if they have the required stake to do so.

lokinet was supposed to be the blockchain and llarp combined, but now it seems that Oxen is the blockchain which provides TCP onion routing and encryption , Lokinet which will be the llarp fast udp onion network that will work in tandem with Oxen. Session uses Oxen only for now and in the future will use both Oxen and Lokined, switching transparently when fast data transfer is needed. Is that an accurate overview?

Session currently uses a system called onion requests for onion routing, which is TCP based, this system still uses the ~1750 Service Nodes to onion route all messages, but it doesn't use Lokinet. Onion requests are single shot, which means you send a request and get a response, they don't allow a user to hold a onion routed connection open with a Service Node or other Session client.

Lokinet is a different onion router which can route any IP based protocol, it also uses the Service Node network to create routes through the network, however because Lokinet can route any IP based protocol it is much more versatile, and it can keep connections open with the Service Node network to be able to stream data. Lokinet is slated for future implementation, since it will help us provide voice calling and other functionality.

[lrq3000]

Thank you @KeeJef for the additional clarifications.

I have opened a PR at #2293, it's going to take some time for review, hopefully the editorial board will greenlight it.

[lrq3000]

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

[KeeJef]

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

This is only really relevant for Lokinet, Session traffic doesn't exit the network in any way where it could be hijacked, Lokinet does have exits but doesn't have a publicly incentivised infrastructure yet, but yes we are aware of these issues in Tor.

[majestrate]

@KeeJef FYI as Oxen/Lokinet fits the criteria (crypto + onion routing) to be a future target of such attack vector: https://www.techradar.com/news/cryptocurrency-users-targeted-by-tor-network-exit-nodes

i agree it could be a problem but it is probably far less of an issue as lokinet exits are not picking from a giant pool of randos, you manually choose your exit so if some bad actor is running an exit no one will use it (free market regulating itself etc), additionally as @KeeJef pointed out, session wont be using exits anyways so it is probably not an attack that is in scope for it.

[Victor239]

Lokinet/Session aren't suitable for PTIO:

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).

https://github.com/privacytools/privacytools.io/issues/1940#issuecomment-853722071

[lrq3000]

Please read the discussion pointed by @Victor239 but I don't think that this legislation impacts Lokinet/Session any differently than other communication softwares, so I'm not sure why this would make Session unsuitable for PTIO compared to competitors, if anything Session appears to be more resilient given its onion routing architecture that others lack.