simplex.chat
You ask the authors how they solved the problem of server needing to know to which client connection an incoming ciphertext needs to be forwarded, and they'll run to the hills.
They're lying by omission about their security, and misleading about what constitutes as a permanent identifier.
You understand the design quite well, from our past conversations, you simply don't like the fact that we don't recognise user IP address as a permanent user identifier on the protocol level. It is indeed a transport identifier, not a protocol-level identifier that all other messaging networks have for the users (in addition to transport identifiers).
Message routing protocol has anonymous pairwise identifiers for the connections between users (graph edges), but it has no user identifiers - messaging servers have no concept of a user, and no user accounts.
Also, recently we added a second step in message routing that protects both user IP addresses and transport sessions: https://simplex.chat/blog/20240604-simplex-chat-v5.8-private...
In general, if you want to meaningfully engage in the design criticism, I would be happy too, and it will help, but simply spitting out hate online because you don't like something or somebody, is not a constructive approach – you undermine your own reputation and you also mislead people.
> You ask the authors how they solved the problem of server needing to know to which client connection an incoming ciphertext needs to be forwarded, and they'll run to the hills
This is very precisely documented, and this design was recently audited by Trail of Bits (in July 2024), we are about to publish their report. So either you didn't understand, or your are lying.
> They're lying by omission about their security, and misleading about what constitutes as a permanent identifier.
You would have to substantiate this claim, as otherwise it is slander. We are not lying about anything, by omission or otherwise. You, on another hand, are lying here.
That you are spiteful for some reason is not a good enough reason.
Factually, at this point SimpleX Chat is one of the most private and secure messengers, see the comparisons of e2e encryption properties in SimpleX Chat and other messengers: https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...
> This is very precisely documented, and this design was recently audited by Trail of Bits (in July 2024), we are about to publish their report.
I’ve looked at SimpleX in the past and am also curious about this. Is there a high-level summary?
So how exactly are all those DMCA letters finding themselves to the correct household if IP address doesn't deanonymize you?
>Message routing protocol has anonymous pairwise identifiers for the connections between users
I'm so tired of you avoiding the obvious question. What does this identifier look like?
Given that you say its anonymous, its probably not a username. So. Is it a random string, an RSA/DH/ed25519/ed448/ECDSA key-pair? Is it permanent? If not, how often does it change? How is it changing, are the identifiers advancing in a hash-ratchet etc. Can it change while the IP address stays the same?
Give me an example of the identifier. If it is a collection of data, explain every single segment of it.
It's clear the server does not tell one user connection from another by its IP address. So, until you explain what information exactly the server uses to tell one user's connection apart from another, it makes no sense to discuss this further.
>You would have to substantiate this claim, as otherwise it is slander.
As per above, IPv4 addresses have been used to identify individual subscriptions, and you're not making it clear that if the users wants ambiguity about the identity of who's behind an IP-address, they should not live in a single person household. You're also not defaulting to Tor so by default every single-household user not behind a NAT can be determined by their IPv4 address. You pretending that IPv4 addresses don't matter doesn't change reality.
Also as for your vague threats of SLAPP lawsuits, let me give you a quick lesson on the Finnish law:
"Edellä 1 momentin 2 kohdassa tarkoitettuna kunnianloukkauksena ei pidetä arvostelua, joka kohdistuu toisen menettelyyn politiikassa, elinkeinoelämässä, julkisessa virassa tai tehtävässä, tieteessä, taiteessa taikka näihin rinnastettavassa julkisessa toiminnassa ja joka ei selvästi ylitä sitä, mitä voidaan pitää hyväksyttävänä."
or
"Defamation as referred to in subsection 1, point 2 above is not considered to be criticism directed at another person's conduct in politics, business, public office or task, science, art or similar public activities and which does not clearly exceed what can be considered acceptable."
https://www.finlex.fi/fi/laki/ajantasa/1889/18890039001
Tldr: Criticism of businesses is legal in Finland. Feel free to consult your lawyers on the matter.
https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
"""
SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server
* IP address / host name [alice-land.net or similar]
* port
* and hash of the long-lived offline certificate*
* a queue ID
* Alice's E2EE public key.
"""
The queue ID is of interest here. The text also says
"""
When setting up a queue, the server will create separate sender and recipient queue IDs (provided to Alice during set-up and Bob during initial connection)."
"""
---
So the queue is basically a pair of port numbers generated by the server. The server gives Alice queue number pair (a11cea11ce, b0bb0bb0b0b).
Alice's introduction message tells Bob that if Bob puts messages to server's port number a11cea11ce, they are sent to her. And upon first connection to Alice, Bob receives from server queue number b0bb0bb0b0b, and he knows, that when he puts messages to that port, they go to Alice. Since these are used to deliver packets, they can not be used by other SimpleX users. So Simplex has created the functional equivalent of emails user46453451@simplex.com and user2646453@simplex.com for the two users, and the users can use these emails to converse.
The server knows that port a11cea11ce is read by 414.414.414.414 (Alice) and if it's suddenly 414.414.414.224, or tor.tor.tor.tor exit node, it's still the same user, and it now knows that user is trying to become anonymous. If OTOH Alice registered via Tor, if she ever fails at connecting to port a11cea11ce without Tor, she must assume her queue number is permanently deanonymized.
But there is queue rotation. https://github.com/simplex-chat/simplexmq/blob/56986f82c89b0...?
The problem is, if Alice requests a new queue number, she is still connected via the same session and user that was already associated with the deanonymized IP-addrees. The service can just add the new queue-pair as the newest queues associated with Alice's account. Alice can not re-anonymize her account again, the server always knows it's the same user, unless Alice creates a completely new account from behind Tor and starts using new queues. This is why SimpleX should force connections through Tor, but it leaves configuration of proxies to the user. Yet it claims it's supposedly more private than the competition, like Cwtch.
"But the server doesn't know who the people behind the IP-addresses are"
Neither does Signal know who the people behind phone numbers or IP-addresses. But that's not the problem.
The server can accumulate data, and Alice's friendly fascist government can come around asking for these logs. Suppose Bob was apprehended and his device was confiscated and the local FSB wants to know who is behind queue ID a11cea11ce. A malicious server will have accumulated Alice's accidental connection to the service without Tor, so the queue ID a11cea11ce can be correlated with Alice's IP address, and the ISP can tell which subscriber was using the IP-address at the time. Again, defaulting to Tor in clients would have prevented the temptation to aggregate user data on server-side.
So reading your documentation, it's not exactly unclear why my reasoning was wrong. Please do tell me how a malicious server can't correlate IP-addresses with queues when your threat model states https://github.com/simplex-chat/simplexmq/blob/stable/protoc...
"""
The server can
* perform the correlation of the queue used to receive messages (matching multiple queues to a single user) via either a re-used transport connection, user's IP Address, or connection timing regularities.
* learn a recipient's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
"""
Your service doesn't seem to be adding anything ground breaking to the mix with queues. It's not using usernames, or registered accounts. Or phone numbers. It's generating queue numbers that are just random identifiers, that can be used to cross-correlate how may ciphertexts each user sent to one another, and it can bind all IP-addresses to those users. It can't be the case both the IP-address and the queue number changes at the same time, yet the service knows to which user it should deliver an incoming ciphertext.
The bottom line is this. The server that always knows where to relay ciphertexts, can always eventually deanonymize the user, unless the system defaults to Tor.
What is being said on the front page:
>Other apps have user IDs: Signal, Matrix, Session, Briar, Jami, Cwtch, etc. SimpleX does not, not even random numbers.
doesn't match the fine-print under threat model.
So explain to me, why isn't a list of tuples a malicious server secretly builds over time
[
(queue-number1, Tor-IP-address1),
(queue-number1, Tor-IP-address2),
(queue-number2, Tor-IP-address2),
(queue-number3, Tor-IP-address2),
(queue-number3, Deanonymized IPv4 address),
(queue-number3, Tor-IP-address3),
(queue-number4, Tor-IP-address3),
(queue-number4, Tor-IP-address3),
(queue-number4, Tor-IP-address4),
(queue-number4, Tor-IP-address5),
]
not a valid user ID that can be used to deanonymize Alice based on queue-number4 on Bob's confiscated device?
Why is this better than Cwtch where it's just a long term onion address that was never deanonymized? Cwtch didn't require 20 page manual to setup either.