Arguably WhatsApp's protocol scales reasonably well (nice description in this survey paper: [1]), at least well enough for maximum WhatsApp group sizes (times up to four devices per participant).
A possible implementation using existing infrastructure where at least the client is open: modify the messaging client so that when it receives multiple pvt connections it routes every incoming message to all connected members. Now if you have say 10 users that want group encrypted chats, have one of them run the modded client too so that any user connecting to a pvt chat with that client will essentially enter a room with other users. Of course this requires trust between members, and adding another encryption layer on all clients might turn out necessary so that you don't need to worry about the carrier telling the truth (all p2p connections encrypted, etc)..
IIRC Signal just has each group member send each group message to each recipient with the standard pair-wise encryption keys. It's the message's headers that lets the recipient know it's intended for the group and not the 1:1 group.
> this is pretty much what Matrix does, if I understand correctly.
I think it has senders encrypt messages with each room member's public key, rather than a single shared key. (At least, that's what the behavior I've seen suggests to me.)
Here's the spec, in case you want to comb through it:
The entire platform is a joke. It pretends to have no identifiers and heavily markets queues (a programming technique) as a solution to privacy problem.
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.
That you don't like the design is well known. But this is not the reason to lie.
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.
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.
Arguably WhatsApp's protocol scales reasonably well (nice description in this survey paper: [1]), at least well enough for maximum WhatsApp group sizes (times up to four devices per participant).
[1] https://eprint.iacr.org/2017/713.pdf
MLS scales best for large n, but WhatsApp/Signal or Matrix do pretty well for < 1k people
https://en.wikipedia.org/wiki/Messaging_Layer_Security
https://github.com/facebookresearch/asynchronousratchetingtr...
A possible implementation using existing infrastructure where at least the client is open: modify the messaging client so that when it receives multiple pvt connections it routes every incoming message to all connected members. Now if you have say 10 users that want group encrypted chats, have one of them run the modded client too so that any user connecting to a pvt chat with that client will essentially enter a room with other users. Of course this requires trust between members, and adding another encryption layer on all clients might turn out necessary so that you don't need to worry about the carrier telling the truth (all p2p connections encrypted, etc)..
Have the room owner create an AES 256 key, send it to all Party members via 1:1 e2ee, encrypt room messages with that AES key.
This kills the forward secrecy.
IIRC Signal just has each group member send each group message to each recipient with the standard pair-wise encryption keys. It's the message's headers that lets the recipient know it's intended for the group and not the 1:1 group.
this is pretty much what Matrix does, if I understand correctly.
Additionally the key is regularly updated to provide some degree of perfect forward secrecy and avoid encrypting for people who left the group chat
> this is pretty much what Matrix does, if I understand correctly.
I think it has senders encrypt messages with each room member's public key, rather than a single shared key. (At least, that's what the behavior I've seen suggests to me.)
Here's the spec, in case you want to comb through it:
https://spec.matrix.org/v1.11/client-server-api/#end-to-end-...
1 reply →
simplex.chat
The entire platform is a joke. It pretends to have no identifiers and heavily markets queues (a programming technique) as a solution to privacy problem.
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.
That you don't like the design is well known. But this is not the reason to lie.
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...
3 replies →