SimpleX vs. Cwtch, who is right?

Two years ago, Sarah, one of the main people behind Cwtch, made this statement:

https://www.reddit.com/r/selfhosted/comments/s2hil6/comment/hsp09it/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

Then the founder of SimpleX replied to her, and this is where it ended.

This year, Sarah posted multiple posts about SimpleX on Mastadon:

So clearly one of these people is lying to us, but I don’t have the technical knowledge and capabilities to tell who is right and who is wrong.

It would be great if someone knowledgeable about this topic could step in to clarify these things for us.

It would also be interesting to hear what @epoberezkin has to say in response to these Mastadon posts.

3 Likes

After reading the toots originally I honestly thought they were talking about Session, not SimpleX.

SimpleX does still continue to lack automatic rotation of queues after years which I’d argue does act as an identifier.

Aside from the topic, I’d wish Briar and cwtch style projects were more successful.
Briar is approaching fifteen years old at this point and has had many funding rounds yet still lacks basics like images in group chats.
I don’t blame anyone in particular, I just question why this isn’t a “solved problem” at this point.
Instead we have a ton of fragmentation.
(and yes, I’m just complaining, feel free to disregard)

related:
standards

7 Likes

It’s sad that most people are using centralized messengers, including Signal.

We should all just pick a decentralized solution like Matrix or SimpleX and use it.

2 Likes

I’ve been pushing people towards XMPP for 12+ years now.
I have no doubt XMPP will be alive in another decade, I can’t say the same for these.

3 Likes

I haven’t tried XMPP. What are the selling points?

1 Like

XMPP is a federated chat protocol that has been around for ages. It’s main selling point is that it’s extensible. Despite being decades old, it has evolved to include double ratchet end to end encryption, multiple device support, bridges etc.

I’d argue it solves the same problems Matrix solves, but had been around for more than 10 years before Matrix started. It’s managed by the IETF and has plenty of client and server independent implementations. The server implementations are vastly lighter weight than Matrix’s. And while Matrix has very close ties to the for profit Element, where sometimes is hard to differentiate between the two, no one owns XMPP.

I wish all the funding and effort that have gone to Matrix, had gone to XMPP and Element had implemented their clients and built their business around XMPP.

2 Likes

XMPP is not metadata resistant (SimpleX and Signal both offer better protection of metadata).

Another problem with XMPP is usability. Signal is the easiest for non-tech users to adopt. “Hey download the app called Signal, sign up with your phone number and add me”

Instructing them sign up for XMPP requires them to:

  1. Find a suitable client for each device. There are different clients for various operating systems, some with varying features.
  2. Find which server they want to sign up with, create an account.
  3. Make sure the servers and clients both parties are using have the same features (ie if both clients and servers don’t offer encryption that is a problem).

Signal or SimpleX have a much clearer path to widespread usage than XMPP - which is already 20 years old.

There are other problems with XMPP too:

  • Server admin can see a lot of data plaintext
  • Message attachments might not be encrypted at all
  • Doesn’t use encryption by default (I believe this is a requirement for privacyguides secure messengers).
3 Likes

So clearly one of these people is lying to us, but I don’t have the technical knowledge and capabilities to tell who is right and who is wrong.

Not necessarily either of us is lying. People may simply have different opinions. I think it all boils down to two questions:

  1. whether a given solution delivers on the threat model it advertises. I actually think it would benefit Cwtch to have an explicit threat model, but maybe it’s somewhere there in the docs - please share if you saw something similar to this: simplexmq/protocol/overview-tjr.md at 1ac0068d22381781fca583ea5304c1fa4f107e46 · simplex-chat/simplexmq · GitHub

  2. whether this is a correct threat model for a given set of the end users.

While the first question is usually easier to settle, as long as threat model is clear and explicit, the second one is tricky - and I think this is the root of my disagreement with Cwtch design (I will elaborate on it below).

SimpleX does still continue to lack automatic rotation of queues after years which I’d argue does act as an identifier.

I agree that automatic queue rotation is important, and I see it as a problem related to queue redundancy - we will be solving both next year.

But I disagree that queue acts as a user identifier - it identifies a pair of users, a connection between them, but not the user.

So returning to the question of threat model adequacy, and whether relying on Tor’s threat model is a good idea for instant messaging, particularly in the model when onion network address is also used as a user identifier, as Cwtch does.

Tor anonymity guarantee relies on the assumption that all three nodes that provide the circuit are controlled by different parties - in case operators of these nodes collude and share the data, the user is not anonymous, and operator of these nodes can establish which IP address connects to which IP address - exactly what Tor is aiming to prevent.

Unfortunately, Tor provides no way to establish node operators - on the opposite, it aims to provide operator anonymity. And from the recent history we see that a party that operated a large part of Tor infrastructure was the same party that sells Internet traffic monitoring: Tor Project Moves Away from Infrastructure Ran by Internet Monitoring Firm. While this was a great news, I do think that to increase Tor’s anonymity requires more transparency about Tor node operators, so that the clients can choose nodes controlled by different operators when building the circuit.

Tom Ritter published great slides about Tor - I really recommend reading them all attentively if you use Tor. The most important part for our case is slide “Guards - maths” - it estimates probability of the user being de-anonymised in case the attacker controls 2% of Tor nodes, and the client choses entry and exit node randomly. The paper slightly overestimates this probability putting it at 50% of being de-anonymised after 1250 random circuits. A more precise calculation shows that it requires 1700 random circuits, but it’s beside the point - if you create many enough random Tor circuits, the probability that one of them won’t provide anonymity and would allow linking IP addresses becomes really high. To reduce it requires choosing entry node non randomly, but it is not something most users do, and it has its own downsides.

This probability is acceptable if you simply browse the web - first, you don’t have a fixed Tor identity in this case, and you also connect to different web servers, so except GPA attacks that Tor does not protect from, occasional de-anonymisation of the web traffic is acceptable and Tor overall provides great anonymity probability, even in the presence of the attackers that control a small share of the nodes.

But if you use Tor hidden service as your client address for instant messaging, then sooner or later you will connect to your contact via a compromised circuit - you just need to use it for a long enough time. From that it logically follows that an attacker who controls a small share of Tor nodes and observes Cwtch traffic over Tor nodes that it controls for a long enough time will be able to build connection graph of many Cwtch users, and I don’t see anything in Cwtch’s or Tor’s design that would prevent it - happy to be corrected about it.

So I think that using Tor addresses as persistent user addresses for instant messaging network is a bad idea, and it cannot provide an adequate anonymity of the network users. From this does not follow that using Tor is a bad idea - it is only a bad idea to use Tor addresses for instant messaging, and I am really sorry to say that, but it does make Cwtch design bad for anonymity of the contacts, if all my logic is correct…

That’s the reason I believe instant messaging requires an alternative model for onion routing, independent from Tor that was built for web browsing, the model where the network operators have no anonymity - on the opposite, they are identifiable to the users’ clients, so that they can choose different operators for message routing and to reduce the risks of the operators collusion.

Also, unlike Cwtch, SimpleX does not assign persistent identifiers to the users themselves, and instead assigns them to connections between the users - so all network operators can see on the protocol level is connection graph edges (messaging queues) and not vertices (users). NIST calls it “anonymous pairwise identifiers” and recommends it as a privacy-by-design principle.

There is a picture on the site that explains that: SimpleX Chat: private and secure messenger without any user IDs (not even random)

At the same time, there is nothing wrong in using Tor to connect to SimpleX network - many people did that before we added private message routing (a SimpleX network onion routing) and many will continue doing it even after that - it provides additional layer of anonymity protection, without creating a fixed user identifier in Tor network. So for some threat models SimpleX via Tor would be a better fit than SimpleX without it - we are not trying to replace Tor in any way.

Hope it all makes sense, happy to answer any questions.

12 Likes

Thanks for the explanation, good to know that moving my relatives to SimpleX was a good idea.

3 Likes

Simplex does not have good linux app having a good native app can increase the userbase

2 Likes

… and its still not using UnifiedPush, causing huge battery drains caused by that decision.

1 Like

The battery consumption is really dramatic. However, it is worth mentioning that the client released for android devices in the notification about enabling constant updates refers to the fact that the push option is less secure, offering its own implementation of constant updates. Is there a way out of this situation besides push so that the charge consumption is not so aggressive? To this of course is also added the work of VPN for most users who chose SimpleX.

please support simplex desktop on wayland

2 Likes

To extend on my comment above.

The assessment in the linked presentation is somewhat outdated when it comes to hidden services. Since then Tor added mitigations for hidden service discovery: Announcing the Vanguards Add-On for Onion Services | The Tor Project

This post shows that prior to these mitigations the situation was worse than my analysis, and it is still not ideal:

the addition of second layer guard nodes means that the adversary goes from being able to discover your guard in minutes by running just one middle node, to requiring them to sustain the attack for weeks or even months, even if they run 5% of the network.

So, if a potential attacker that can control 5% of Tor network is seen as a viable threat, having a long-term fixed address for an anonymous hidden service can lead to discovery, that could be mitigated by the regular rotation.

I think Cwtch should share this analysis with the users, and recommend not to use the same address for a long time for the most sensitive communications.

3 Likes