Matrix: a new specification for federated realtime chat

The bits where crypto is fundamental to the robustness of the implementation are already in place. All server maintain keypairs. Message history integrity is all signed (like git). All replication transactions are all signed to protect against server identity spoofing. All federated traffic is TLSed.

As regards E2E, we actually (finally) started implementing it last week.

TextSecure is really nice - it uses Axolotl for a PFS key ratchet, and for group chat I believe each message is encrypted once with a ephemeral symmetric key, and the key are then sent 1:1 to all recipients using the 1:1 ratchet. The code seems good, and Moxie clearly knows his stuff.

However, if we deployed the TextSecure architecture to Matrix, we have a major problem: Matrix is all about storing history on a bunch of servers and synchronising it on demand to multiple clients. How can this ever work with PFS? New clients would never be able to replay past history by definition, as the keys to decode the old messages were ephemeral and have been lost. Moreover, existing clients could never expire history and re-lazy-load it in from the server, as the keys again will have been lost.

So our strategy in the E2E implementation for Matrix is to actually support a spectrum of PFS-ness, configurable per room. At one end of the spectrum, each room has a single symmetric key throughout its lifetime, which is shared securely 1:1 between the participants when they are invited into the room. This allows all past & future history to be decrypted. At the other end of the spectrum, you have pure PFS - each message has its own ephemeral key, and once the message has been pulled off the server, you might as well delete it from the server as you'll never be able to decode it again (unless the client keeps all the keys for all the messages it ever receives... at which point it might as well just be storing the decrypted messages).

In the middle of the spectrum it gets more interesting: you have the ability to specify encrypted subsets of data within the room, each with encrypted with its own symmetric key. In the simplest case, you could split the timeline of the room up into epochs. Only participants who have the key for that epoch can ever decrypt it. This lets you invite new participants in without leaking past history by rekeying the room when you invite someone - or lets you kick people out and rekey the room to avoid them decrypting it in future. The clients store non-ephemeral keys for as long as they care about decrypting the contents of the room on the server, and the usefulness of the matrix synchronised history is preserved.

In practice, we expect that this will be the common case. Rooms get created with a symmetric key; when users invite or kick people from the room they have the option to rekey the room to segregate history. Alternatively, the seriously tin-foil-hatted of us can enable PFS when creating the room, which will hopefully provide compatibility with TextSecure, and ensure that a single compromised key can never compromise any other history. However, this will obviously stop history synchronisation from being meaningful - your history will be stored on your clients, and only on your clients. (Don't to check for keyloggers!)

We expect to have the E2E implementation finished in the next 1-2 months. Getting the core state replication subsystem stable and performant is alas going to have to take priority in the interim.