Skip to content

MSC3673: Encrypted ephemeral data units #3673

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

MSC3673: Encrypted ephemeral data units #3673

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
066acda
MSC3673: Encrypted ephemeral data units
stefanceriu Jan 25, 2022
7ba8e27
Update proposals/3673-encrypted-ephemeral-data-units.md
stefanceriu Jan 25, 2022
7fdf81a
Reference MSCs through PR link instead of rendered.
stefanceriu Jan 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions proposals/3673-encrypted-ephemeral-data-units.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
# MSC3673 - Encrypting ephemeral data units

## Problem

With the introduction of [MSC2477](https://github.com/matrix-org/matrix-doc/pull/2477)
we now have the ability to send and receive custom, user-defined ephemeral data
units. This is a great mechanism for transferring short-lived data, applicable in
a variety of situations where persistence is not desired.

Unfortunately E2E encryption for EDUs isn't currently defined and some
situations, like live user location sharing, come with privacy concerns, moment
in which that becomes a problem.

## Proposal

This MSC proposes a generic mechanism for end to end encrypted ephemeral data
units, building on top of [MSC2477](https://github.com/matrix-org/matrix-doc/pull/2477)

We would like to wrap them inside the standard encryption envelope:

```json5
{
"algorithm": "m.megolm.v1.aes-sha2",
"sender_key": "<sender_curve25519_key>",
"device_id": "<sender_device_id>",
"session_id": "<outbound_group_session_id>",
"ciphertext": "<encrypted_payload_base_64>"
}
```

in which the `ciphertext` will contain the custom EDUs payload and which will be
sent to `rooms/{roomId}/ephemeral/m.room.encrypted/{txnId}`, similar to
encrypted timeline events .

The Megolm keys required to decrypt this EDU should be shared over Olm just like
regular encrypted timeline events.
Copy link
Member

@uhoreg uhoreg Jan 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be worth clarifying whether you can use the same megolm session for normal room events and for ephemeral events. (FWIW, I think you should use a separate megolm session, and that it should have the shared_history property (MSC3061) flag unset)

Copy link
Member Author

@stefanceriu stefanceriu Jan 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't know much about how that works. Would adding a new session significantly complicate things client side? Also, what are the advantages/disadvantages?

Copy link
Member

@dkasak dkasak Apr 8, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The advantage of using separate keys is increased confidentiality protection against malicious homeserver attacks.

The HS could store encrypted EDUs indefinitely since all EDUs have to pass through it. If we used regular Megolm sessions ("room keys") for encrypting EDUs, then in the event that the server somehow managed to get a hold of the regular session, it would also have complete historical visibility of the EDUs sent during the time that this session was active. Using an unshareable separate Megolm session for this purpose alleviates this risk.

The disadvantage is that it increases to-device traffic and the number of Megolm sessions and session operations, which can be slow. If it turns out to be a problem, we could allow EDU Megolm sessions to be rotated slower than normal sessions.

Copy link

@robryk robryk May 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In what scenarios would you expect the homeserver to be able to get ahold of a regular session, but not of the separate session for EDUs? I would naively expect the same set of entities to have keys for both, so also any compromise to affect both or neither.

Copy link
Member

@dkasak dkasak May 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not any legitimate scenarios, but there can always be implementation bugs. From my POV, this is just an extra degree of separation for some extra hardening, so that stealing one does not compromise the other.

I would naively expect the same set of entities to have keys for both, so also any compromise to affect both or neither.

Room keys are probably in a bit of a worse position since they get forwarded/re-shared to other devices in several situations (for instance, upon m.room_key_request), whereas EDU keys don't need to support forwarding since the EDUs themselves are ephemeral. So in the event of an undecryptable EDU, we can just drop it and rotate the key.


Clients will receive the encrypted payloads in the `/sync`s `ephemeral`
dictionary where `type` will be equal to `m.room.encrypted` and which can be
decrypted using the pre-shared Megolm keys.

## Alternatives

We are not aware of any other straightforward solution for sharing sensisitive
ephemeral data between users.