End-to-End Crypto (SPEC-162)

[matrixbot]

update April 2017: we now have more-or-less operational E2E encryption in matrix. The work remaining on this issue is to specify it.

---

End-to-end encryption in Matrix is currently a work-in-progress. A draft of the specification is being prepared on the drafts/e2e branch of matrix-doc. The purpose of this issue is to provide an overview of the work that is outstanding.

An audit of the Olm library, and Olm's use in matrix

Matrix's cryptographic support has been designed according to our understanding of the latest security research and algorithms. However, none of the matrix.org team are trained security experts.

We would welcome an independent audit of our designs and implementations, to highlight any potential vulnerabilities.

(update: NCC group carried out a review on the olm and megolm protocols, and the libolm implementations in November 2016: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review/)

New device handling (SPEC-271)

We need better support for adding new devices to conversations.

Protocol support for out-of-room messages (#443), and implementations in homeservers and clients

Once all recipients have received encrypted data, it is useless (even to the original recipients), because nobody can decrypt it. There is no point keeping such history in a DAG forever. Good security practice dictates that we destroy the ciphertext even if we are confident in the security of the encryption.

Group chat support (#589)

m.room.encrypted events are a valid proof-of-concept to show that we can transmit encrypted data between clients; however this does not scale beyond a few users, and does not give a good user experience. #589 considers how this can be improved.

Encryption controls on rooms (#590)

Not every room will need or want the same level of security. We need to define some controls for room administrators to use.

Support for encryption of attachments (#461)

This might become obvious after #589, but we should remember to make sure that uploaded files can be encrypted as well as messages.

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

(Reported by @ara4n)

[matrixbot]

Jira watchers: @ara4n @richvdh

[matrixbot]

Links exported from Jira:

relates to #461
relates to #443
relates to #589
relates to #590
relates to SPEC-198
relates to SPEC-271

[matrixbot]

Once all recipients have received encrypted data, it is useless (even to the original recipients), because nobody can decrypt it. There is no point keeping such history in a DAG forever.

Counterpoint from https://lwn.net/Articles/634144/

I'd argue that even with PFS, history sync is meaningful for a few reasons:

1. Storage - if the client is only storing fixed-size keys, rather than variable-sized records, small clients (like phones) will be able to keep more history
2. Reliability - fixed-size keys can trivially be saved as a packed array, either of keys or of {timestamp, key} tuples (for searching efficiency), while variable-length messages require more complex (and failure-prone) storage
3. Verification - if the messages are encrypted using AEAD (and they should be!), keeping the key allows you to revalidate that yes, this is the same message that was originally sent.
4. Simplicity - keeping the behavior of history sync the same even with PFS reduces the number of corner cases to handle in the code (and possibly the protocol).
5. Sharing - you want to show someone a past message, and you want them to trust that it actually happened when you say it did (and possibly the context, which are just more messages). If the server still has it, this is trivial: Send them the message identifier and the key, and let them fetch it themselves. This allows treating keys as read-capabilities for historic messages, which is a useful tool indeed.

-- Alex Elsayed

[matrixbot]

Not sure if this is the right place for this, but, related to encryption, I'd like to see the ability to specify a message as "self destructing" after a certain period, where, after that period passes, the system auto-redacts the message.

If not easily possible with single messages, then perhaps on a per-room basis.

The use case I'm thinking of is, sharing passwords with a team, or, (if possible per message) on a 1:1 basis with a specific matrix user.

I'd like to be able to share a password and have that message expire after x hours or days. The operational expectation would be, that people would copy the password to their secure storage systems, such as Zetetic Codebook or 1Password and the like.

(Now I see the challenge here: Protocol support for self-destructing messages (#443)...)

-- Rick Cogley

[matrixbot]

Rick, the "self-destructing" message concept is worrisome because it implies a security property that is not true and may mislead users. There has been some discussion about how to better support the use case you describe without making false promises. I believe the resolution of that discussion is represented in https://matrix.org/jira/browse/SPEC-138. You may want to watch that issue.

-- Jimmy Cuadra

[richvdh]

The fundamentals of e2e are now defined; however they need proper specification.

[pik]

Just a few items for the TODO.

• state_key use for m.room.encryption is undocumented

• one_time_keys upload format is undocumented

• Megolm session key share via. olm is undocumented

[richvdh]

@pik: Some of those are visible at http://matrix.org/speculator/spec/drafts%2Fe2e/client_server/unstable.html#end-to-end-encryption, fyi

[ara4n]

i believe this is now closable, with #1648 merging.