[SPEC-162] End-to-End Crypto Created: 23/Sep/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Open
Specification
None
None
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
New Feature
Matthew Hodgson
Unresolved
e2e
Not Specified
Issue Links:
Relates
relates to
relates to
relates to
relates to
relates to
relates to
Purpose:
Updated: 06/Jan/16
None
Priority:
Assignee:
Votes:
P2
Unassigned
0
Not Specified
Not Specified
SPEC-24
SPEC-138
SPEC-292
SPEC-293
SPEC-198
SPEC-271
How does E2E encryption work for atta...
Ability to send self-destructing events
Support for encryption in group chats
Define semantics for encryption contr...
API for key management for end to end...
Messages for E2E to notify about new ...
Open
Open
Open
Open
Resolved
Open
Feature
Description
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.
New device handling (SPEC-271)
We need better support for adding new devices to conversations.
Protocol support for self-destructing messages (SPEC-138), 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 (SPEC-292)
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. SPEC-292 considers how this can be improved.
Encryption controls on rooms (SPEC-293)
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 (SPEC-24)
This might become obvious after SPEC-292, but we should remember to make sure that
uploaded files can be encrypted as well as messages.
Comments
Comment by Alex Elsayed [ 06/Jan/16 ]
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 variablesized 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.
Generated at Tue Feb 09 15:43:54 GMT 2016 using JIRA 6.3.5a#6334sha1:09a5455216f716a7a0d602c94d19149d1a45bbcc.