3 ms·

Rocket.Chat uses their own E2EE scheme [1] which is different and arguably less secure than the one in Matrix [2]. As I understand it, this is simply a bridge a

Rocket.Chat uses their own E2EE scheme [1] which is different and arguably less secure than the one in Matrix [2]. As I understand it, this is simply a bridge and will defeat the purpose of the advanced E2EE algorithm in Matrix. I recall looking at Rocket.Chat when setting up chat servers for my corporation and dropping it over their poor and slow to adopt E2EE implementations. [1] https://docs.rocket.chat/guides/security/end-to-end-encryption-algorithms https://docs.rocket.chat/guides/security/end-to-end-encrypti... [2] https://gitlab.matrix.org/matrix-org/olm https://gitlab.matrix.org/matrix-org/olm

zaik 4y ago
That's also the reason you cannot securely message Matrix users if you already have a XMPP address.
Arathorn 4y ago
Even if Rocket.Chat used the same E2EE scheme as Matrix, you would still have to re-encrypt, given the application-layer protocols are not the same. RC's messages are a blob of JSON which looks nothing like Matrix's JSON events. To preserve E2EE throughout you'd have to speak precisely the same protocol - e.g. Matrix+Megolm or XMPP+OMEMO or whatever, or effectively run a multihead stack (one which can speak both Matrix & Rocket.Chat), which isn't exactly elegant. This is the disadvantage of bridges, alas: if you want E2EE, you need to be on the same protocol throughout.
- CameronNemo 4y ago
  You can run bridges on the client, but that is not well supported right now.
  - Arathorn 4y ago
    True, although this is one step away from being a multihead messenger, effectively. It's just that the protocol-specific modules are daemons using a standard API rather than in-process. For instance, I can't think of a way that one would run an Element Web<->Rocket.Chat bridge clientside, as web browsers can't use local web services, short of a service worker... but by the time you're running a dedicated service-worker for a webapp which lets it talk to another webapp, it's basically become a multihead msgr.
- jeroenhd 4y ago
  I believe the eventual intention is to run a bridge in the client, allowing for perfect secrecy. Matrix itself is showing signs of running a homeserver on every client (though that's still experimental). Both projects are still a long way away, though. To be fair, though E2EE is perfect for a general purpose messenger, I don't think it's necessary per se. Group chats that would normally appear on IRC don't have a need for E2EE (and verifying everyone in a public room is also extremely impractical!) which seems like a perfect use case for this integration.

zaik 4y ago

That's also the reason you cannot securely message Matrix users if you already have a XMPP address.

Arathorn 4y ago

Even if Rocket.Chat used the same E2EE scheme as Matrix, you would still have to re-encrypt, given the application-layer protocols are not the same. RC's messages are a blob of JSON which looks nothing like Matrix's JSON events. To preserve E2EE throughout you'd have to speak precisely the same protocol - e.g. Matrix+Megolm or XMPP+OMEMO or whatever, or effectively run a multihead stack (one which can speak both Matrix & Rocket.Chat), which isn't exactly elegant. This is the disadvantage of bridges, alas: if you want E2EE, you need to be on the same protocol throughout.

CameronNemo 4y ago
You can run bridges on the client, but that is not well supported right now.
- Arathorn 4y ago
  True, although this is one step away from being a multihead messenger, effectively. It's just that the protocol-specific modules are daemons using a standard API rather than in-process. For instance, I can't think of a way that one would run an Element Web<->Rocket.Chat bridge clientside, as web browsers can't use local web services, short of a service worker... but by the time you're running a dedicated service-worker for a webapp which lets it talk to another webapp, it's basically become a multihead msgr.
jeroenhd 4y ago
I believe the eventual intention is to run a bridge in the client, allowing for perfect secrecy. Matrix itself is showing signs of running a homeserver on every client (though that's still experimental). Both projects are still a long way away, though. To be fair, though E2EE is perfect for a general purpose messenger, I don't think it's necessary per se. Group chats that would normally appear on IRC don't have a need for E2EE (and verifying everyone in a public room is also extremely impractical!) which seems like a perfect use case for this integration.