Onion requests: Session’s new message routing solution

When the Loki Project set out to build Loki Messenger, the app that became Session, we knew that anonymity, security, and freedom needed to be at the very core of the app. And it seemed that the best way to accomplish that was to build Session on top of Lokinet, our bleeding-edge anonymous onion routing network. We knew that routing Session messages over Lokinet would provide total user anonymity and class-leading security.

However, as Session’s development progressed, we began to realise that Lokinet might not be the perfect fit for Session at this point in time.

Lokinet does offer the security, features, and versatility necessary for Session to succeed in its goal of providing secure and truly anonymous communications. However, as we worked to implement Lokinet on Android and iOS, it became clear that the changes required to get Lokinet working on mobile devices would not be trivial (see: https://github.com/loki-project/loki-network/pull/869 https://github.com/loki-project/loki-network/pull/542), and even once Lokinet was successfully implemented, Session still wouldn’t be guaranteed to get approval for the iOS App Store and, to a lesser extent, the Google Play store.. Additionally, Lokinet has been undergoing some growing pains after its move to a much larger router network earlier this year, and the DHT and router discovery will need to be reworked before it is reliable. While these changes are underway now, they will not be completed in time for Session’s launch.

Lokinet is powerful — extremely so. But Session doesn’t need a network as versatile as Lokinet to get messages from A to B securely.

Due to the nature of Session, we realised that the same protections could be provided with a much simpler onion router. Session’s new routing solution, onion requests, will accomplish this goal. Onion requests work by selecting three random Service Nodes (the user-operated servers on the decentralised network Session runs over)  and building an onion-encrypted path through them. Encryption is handled using the existing X25119 keys held by each Service Node Storage Server, and each onion request is processed by the Loki Storage Server.

There is no privacy loss with onion requests (compared to a Lokinet-based implementation) because onion requests are still based on the Sybil-resistant Service Node network, and 3 hops are still taken between origin and destination nodes. The major change is the reduced complexity of the system. The onion request system doesn’t support UDP streams or exit node functionality, so implementation will take weeks, compared to the months which would have been spent making Lokinet functional on mobile platforms.

Effects on the Lokinet and Session roadmaps 

The decision to move Session from Lokinet to onion requests does not affect the Lokinet roadmap. If the completion of the DHT and router discovery improves Lokinet’s stability, and we can build out the appropriate Lokinet mobile clients, then we would want to switch Session from onion requests back to using Lokinet, since Lokinet offers better ways to synchronously communicate with users, as well as allowing for potential future Session features such as onion-encrypted real-time voice chat.

So, taking all of that into consideration, how does this change affect the Session roadmap? At launch, Session will still be using the interim proxy routing solution discussed in the Session FAQ. But within weeks of launch, we will move to using onion requests, heightening both security and anonymity for all Session users. At the end of the day, moving Session’s message routing from Lokinet to onion requests will significantly cut down development time, with no negative impacts on security, anonymity, metadata protection, or user experience — the very definition of a win-win solution.

For an extended look at the new onion request system, watch Loki CEO Simon Harman and CTO Kee Jefferys explain the change on our YouTube channel.