3 ms·

I'm not sure I understand. If in fact the same underlying encryption protocol is used, why can I not retrieve the public key of a Matrix user, encrypt the messa

by zaik 5y ago

I'm not sure I understand. If in fact the same underlying encryption protocol is used, why can I not retrieve the public key of a Matrix user, encrypt the message and send it? Nothing here requires the server to break E2EE.

ThatGeoGuy 5y ago
Because the message format is different. In XMPP, the message is an XML document according to the message schema. In Matrix, it's JSON. You can exchange the private keys, but using what format? Once that's done, you can encrypt XML on one side, but Matrix has to convert it into JSON on the other (in its own, separate format with its own fields). This can be done on the server side after decryption (no more E2EE), or on the client side (after decryption). In the latter case, you're not running a bridge anymore, you're just running an ad-hoc client for XMPP inside your matrix client.
- larma 5y ago
  In XMPP, encrypted messages can either contain encrypted XML > <message type="chat"><body>Hi there!</body></message> or raw text > Hi there! In Matrix, it's always encrypted JSON > {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}} It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM). But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above). Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).
upofadown 5y ago
Even if you could make Olm/OMEMO interoperate otherwise, the Signal protocol supporting client requires access to a server to pick up pre-keys. So you need to have access to the pre-key server of your correspondent or your correspondent needs access to the pre-key server you are on. The Signal Protocol is not generally suitable for this sort of thing mostly due to its complexity. If you did something stateless like OpenPGP then you could do E2EE over bridges with no problem. The cost would be that each and every message would be complete in itself. So sending a single emoji would take several hundred bytes. That might be less important these days...

by zaik 5y ago

ThatGeoGuy 5y ago

Because the message format is different. In XMPP, the message is an XML document according to the message schema. In Matrix, it's JSON. You can exchange the private keys, but using what format? Once that's done, you can encrypt XML on one side, but Matrix has to convert it into JSON on the other (in its own, separate format with its own fields). This can be done on the server side after decryption (no more E2EE), or on the client side (after decryption). In the latter case, you're not running a bridge anymore, you're just running an ad-hoc client for XMPP inside your matrix client.

larma 5y ago
In XMPP, encrypted messages can either contain encrypted XML > <message type="chat"><body>Hi there!</body></message> or raw text > Hi there! In Matrix, it's always encrypted JSON > {"type": "m.room.message", "content": {"msgtype": "m.text", "body": "Hi there!"}} It would be possible for Matrix to indicate that a room is a "raw room" and that clients should send and expect raw messages in that room - losing a few features on the go. Such raw room could be bridged over to XMPP fully end-to-end-encrypted (with small changes on either side to adjust for the differences between OMEMO and OLM). But I doubt anyone at Element will invest time into doing it and for the XMPP side it's much more work to do it "on their own" (by implementing parsing support for the encrypted JSON of Matrix as shown above). Having raw text in the encrypted content is by the way still the normal way how things work in XMPP world and is supported by every client doing E2EE - because it is basically free to implement (barely any additional code needed).

upofadown 5y ago

Even if you could make Olm/OMEMO interoperate otherwise, the Signal protocol supporting client requires access to a server to pick up pre-keys. So you need to have access to the pre-key server of your correspondent or your correspondent needs access to the pre-key server you are on. The Signal Protocol is not generally suitable for this sort of thing mostly due to its complexity. If you did something stateless like OpenPGP then you could do E2EE over bridges with no problem. The cost would be that each and every message would be complete in itself. So sending a single emoji would take several hundred bytes. That might be less important these days...