Support for encryption in group chats (SPEC-292)

[matrixbot]

m.room.encrypted events work as a proof-of-concept to demonstrate that we can transfer data securely between clients, but this:

• does not scale to more than a few devices per room
• is incompatible with any sort of history visibility (even the original recipients of a message can only read a message once)

The draft e2e spec contains some initial ideas about a design, but this needs fleshing out.

As an alternative approach, it would also be interesting to consider a very simple encryption protocol, whereby there is a single shared secret for each room, which is used as a key for a cipher. This secret could be shared between participants using 1:1 Olm channels. The main disadvantage of such an approach is that it does not offer Forward Security, or privacy from departed members, without regular rekeying. This opens further questions: when would you rekey, and who is responsible for initiating such a process?

(Imported from https://matrix.org/jira/browse/SPEC-292)

(Reported by @richvdh)

[matrixbot]

Jira watchers: @richvdh

[matrixbot]

Links exported from Jira:

is blocked by #443
relates to #501

[matrixbot]

Currently, the draft spec is missing details on the transport to be used by the proposed messages: what event types would be required, and what fields would they have?

Another thing that is missing is the ability for room admins to configure security. This is the subject of #590.

-- @richvdh

[matrixbot]

For anyone interested in following progress here, I've started some notes on the design of this at https://docs.google.com/document/d/1igtE-wd7f7dXlGgo52ivt-omFmtDVNMTtlQ7-sD1Ofg.

-- @richvdh

[uhoreg]

Fixed by #1284