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