Matrix: a new specification for federated realtime chat [LWN.net]

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:07 UTC (Thu) by drag (guest, #31333)
In reply to: Matrix: a new specification for federated realtime chat by Arathorn
Parent article: Matrix: a new specification for federated realtime chat

> We do have good support for decentralised ACLs however - we absolutely stop unwanted users from joining private discussions, by supporting invite semantics, and decentralised ACLs where users must quote the historical events that prove that they have permission to join a room (or do some privileged action in the room). This is all relatively mature now, but is a very seperate problem from encrypted messaging.

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

So say you have something like PGP/GPG on the client side were every message is signed by the user and encrypted using a public key generated for that particular chatroom/session. Then the encrypted messages are naturally stored and replicated just like plain text ones. To 'join' a chatroom then all that is necessary is to accept a invitation from the person/service that created the chatroom which will provide the necessary keys to decrypt previous and new messages.

That way you end up with end-to-end secrecy, the server can continue to manage chat rooms like it normally does. All the messages themselves can be in ascii-armor format or something like that so it wouldn't really change anything. It's just that they would be gibberish to anybody joining the room without a invitation.

to post comments

Matrix: a new specification for federated realtime chat

Posted Feb 12, 2015 22:37 UTC (Thu) by Arathorn (guest, #101018) [Link]

Can you do encrypting messages in the client and just make it very standardized behavior by recommending the clients behave in a particular way?

Yup, this is precisely the idea. The catch is that you need to define how users' keys are distributed (PKI using centralised or federated keyservers? or PERSPECTIVEs? or some kind of per-session ephemeral keys? are they ratcheted?); you may need to define the mechanism for securely sharing a symmetric key for the room's content between the participants, or define the strategy for encrypting messages using all the participants keys. Do multiple devices for the same user share the same keys (if so, how?), or is each its own actor? Critically, you need to decide on whether to do PFS or deliberately make past history available to newcomers in the room.

All of this can be done at an application layer layered on top of Matrix (like PGP or OTR implementations on the clients) - but we think it's vital to mandate specific protocols for doing this, to avoid fragmentation and have some hope of ever federating with other e2e crypto systems (e.g. Axolotl-based services such as TextSecure or WhatsApp; or OTR-enabled clients; etc). And we can also provide well-defined helpers in the protocol for handling key discovery/exchange and the other administravia in-band.

We're starting work on this properly next week, so if anyone wants to help define how it works please swing by #matrix:matrix.org and give us a shout!