[Discussion] Multi-hop routing

[serrq]

The idea came to me because it is present in Proton VPN.

This makes it difficult, if not impossible, to track a certain transmission or reception channel.

Currently we can configure one only tx and rx server.

What if each it makes bounced the packet to other SMP servers (if available) before delivering the message to the recipient?

So some hops for Tx, and some hops for Rx.
Totally optional, of course.

Would that be a security advantage?

PS: I want to add that I am a complete incompetent in IT and network, so take my considerations as simple curiosity of a non-expert person.

[epoberezkin]

That would make it more difficult to discover the message route, indeed, that's a classic mix network design. We consciously chose single-hop for several reasons:

1. simpler, lower latency, more reliable - so it's a better user experience, overall
2. servers do not need to be aware of other server existence - that provides better protection from network-wide attacks (as the network is simply a client-side consensus, on the server level there is simply no network).

The design you consider has its merits, but we believe that the current design is overall a better trade-off that the traditional mix-network with multi-hop nodes. Also, it's technically possibly to implement client-side mix network - somebody can do it - e.g. a client you run somewhere in the cloud can be programmed to forward messages to different clients, depending on the sender.

[serrq]

I hope it will also be useful and helpful for other people who have had, or have, my same curiosity about this topic.

We could, theoretically, create a FAQ tab where users meet the dev team around technical topics that they need a more technical opinion.
And thus leave a trace of such topics for future consultations because at best this thread will end up in the trash (closed) and no one will be able to add other opinions or new technologies that are appearing in the IT world in future.

Thanks for the technical explanations and for spent your time to considering an answer.

[chen-chan]

Why not just use it over I2P or Tor?

[alexandrestein]

Those tools on smartphones consume way too much power to be really partctical IMHO.

[serrq]

Another interesting design. I leave the discussion to the experts in the field.

https://tailscale.com/blog/tailnet-lock/

[alexandrestein]

Interesting maybe but it's a totally different topic from where I stand.

This would be more related to people introduction.
For example, when Bob introduces Alice to John and Alice and John want to make sure Bob is the introducer.

The goal of mixing the traffic is to make difficult to track packets on the way from sender to recipient.

SimpleX-chat AFAIK already has some features to help mixing traffic :

• fixed size messages
• in future delay transmission once landed on the server (future)

[alexandrestein]

I'm not sure whats possible to do without changing too much the existing code. Please let me know.

I'm considering an approach where the other peer is not considered a threat and it shares with us the node he will read our messages from.

I expect server to have little modifications to be cable of forwarding incoming packet to the the next hop.
All encryption and routing is the responsibility of the client.
It would look something similar to this:

Because every messages have a fixed size. It would trigger quite a lot of noise which would make very hard to track/time messages.

Most of the work is on the client (salable) and the servers is more or less already doing it (client <-> server and not server <-> server).
Maybe some key agreements needs to be specific for this purpose because of the scalability and the anonymity. (if clients identify them selfs to middle and final hop the all thing is much less relevant because the servers know origin of messages)

I guess this will trigger some discussion and probably push-back from engineering. 😃

[trymeouteh]

If this is added. Please have the setting to disable hopping since some users will already be using a VPN or Tor and will not need the unnecessary hopping between SimpleX servers.

[alexandrestein]

I use VPN all the time to hide my exact location.
But because I don't leave in cave global organisation would be able to identify me (when I connect to GitHub for example) and possibly easily track my communications.

For me even with VPN I would keep the feature enable.

But having the possibly to enable/diable it would be very nice.

[Darin755]

Would it be possible to add federation between servers? It wouldn't provide the same level of security as onion routing but it could help spread out the service so that their is no central point of failure

[cyrneko]

SimpleX is SPECIFICALLY designed to let servers not know of eachother's existence.

At no point should any of the servers, hosted by SimpleX or anybody else know that other servers exist at all.

Federation would break this core concept of SimpleX without much benefit.

Either way, because all servers are completely independent, there already isn't a single point of failure.

[alexandrestein]

SimpleX is SPECIFICALLY designed to let servers not know of eachother's existence.

At no point should any of the servers, hosted by SimpleX or anybody else know that other servers exist at all.

Federation would break this core concept of SimpleX without much benefit.

Either way, because all servers are completely independent, there already isn't a single point of failure.

I agree federation would not help, but I disagree with single point of failure.
The single/only route between clients is a single point of failure.
If the server "disappears" link between the clients is lost.

Route redundancy would be quite a big improvement I think. Regarding the SPOF and reliability. (Single Point Of Failure)

[cyrneko]

And if a link is lost, you're supposed to change your receiving/sending addresses.

Again, at no point should servers know of each other.

[alexandrestein]

Well yes of couse, because the link is broken a new handshake is needed. (because existing route broken)
SPOF has for me a very specific meaning and having only 1 route is definitely a SPOF to me.

That's all I wanted to say :-)

[epoberezkin]

while we certainly don't plan multi-hop routing, because it requires a network-wide consensus about the list of participating servers, and it creates a point of centralisation, we do plan two-hop routing: https://github.com/simplex-chat/simplexmq/pull/760/files

[epoberezkin]

It solves the current problems with transport anonymity (lack of it) without any downsides of multi-hop routing.

[alexandrestein]

I think the main issue here is how Simple-x is tackling centralisation. (it should be discussed in a separate thread, maybe it even exist I haven't checked)
Your current design will be quite centralized because nothing is made into the app to make it decentralized (client <-> client exchange of servers list actively or passively) and you refuse to became an authority (similarly to Tor where the maintainers are a central part of the ecosystem).
I guess this is because you want to make a commercial project and not a community project. (which I really regret)

I don't see why having an other type of server would make it better than just implemented such thing inside existing server code base.
I don't see either why servers would need to know about any other.
They could behave as any other "regular client" to other server and the routes would be provided by the client (as we already have a list of possible servers to use)

In the document you pointed you refer to less latency compare to Tor.
Why ? Because less number of hope? By design you are doing the same (relaying), so this statement seems wrong to me. Adding hopes will add latency by design. So I don't see why you would do significantly better.

In the section: 'Implementation considerations'.
No raison to make a choice of point 2 on the implementation level but better to have it configured on client.