5 ms·

Is there a nice solution for multiparty (n >= 3) end-to-end encryption?

by yarg 2y ago

dtx1 2y ago
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.
- kitkat_new 2y ago
  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
  - foresto 2y ago
    > 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-encryption https://spec.matrix.org/v1.11/client-server-api/#end-to-end-...
    - kitkat_new 2y ago
      > When creating a Megolm session in a room, clients must share the corresponding session key using Olm with the intended recipients, so that they can decrypt future messages encrypted using this session. An m.room_key event is used to do this. Clients must also handle m.room_key events sent by other devices in order to decrypt their messages. https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1aes-sha2 https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1ae... OLM is the public key encryption scheme, similar to the Signal Protocol. It is used to exchange room_key messages, but not the room messages itself. MEGOLM as linked in the specification: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
- maqp 2y ago
  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.
lxgr 2y ago
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 https://eprint.iacr.org/2017/713.pdf
deleted 2y ago
[deleted]
kitkat_new 2y ago
MLS scales best for large n, but WhatsApp/Signal or Matrix do pretty well for < 1k people
- yarg 2y ago
  https://en.wikipedia.org/wiki/Messaging_Layer_Security https://en.wikipedia.org/wiki/Messaging_Layer_Security https://github.com/facebookresearch/asynchronousratchetingtree https://github.com/facebookresearch/asynchronousratchetingtr...
_niki_s_ 2y ago
simplex.chat
- maqp 2y ago
  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.
  - epoberezkin 2y ago
    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-message-routing-chat-themes.html 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-resistance-signal-double-ratchet-algorithm.html https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...
squarefoot 2y ago
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)..

Is there a nice solution for multiparty (n >= 3) end-to-end encryption?

by yarg 2y ago

Is there a nice solution for multiparty (n >= 3) end-to-end encryption?

dtx1 2y ago

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.

kitkat_new 2y ago
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
- foresto 2y ago
  > 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-encryption https://spec.matrix.org/v1.11/client-server-api/#end-to-end-...
  - kitkat_new 2y ago
    > When creating a Megolm session in a room, clients must share the corresponding session key using Olm with the intended recipients, so that they can decrypt future messages encrypted using this session. An m.room_key event is used to do this. Clients must also handle m.room_key events sent by other devices in order to decrypt their messages. https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1aes-sha2 https://spec.matrix.org/v1.11/client-server-api/#mmegolmv1ae... OLM is the public key encryption scheme, similar to the Signal Protocol. It is used to exchange room_key messages, but not the room messages itself. MEGOLM as linked in the specification: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/me...
maqp 2y ago
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.

lxgr 2y ago

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 https://eprint.iacr.org/2017/713.pdf

deleted 2y ago

[deleted]

kitkat_new 2y ago

MLS scales best for large n, but WhatsApp/Signal or Matrix do pretty well for < 1k people

yarg 2y ago
https://en.wikipedia.org/wiki/Messaging_Layer_Security https://en.wikipedia.org/wiki/Messaging_Layer_Security https://github.com/facebookresearch/asynchronousratchetingtree https://github.com/facebookresearch/asynchronousratchetingtr...

_niki_s_ 2y ago

simplex.chat

maqp 2y ago
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.
- epoberezkin 2y ago
  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-message-routing-chat-themes.html 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-resistance-signal-double-ratchet-algorithm.html https://simplex.chat/blog/20240314-simplex-chat-v5-6-quantum...

squarefoot 2y ago

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