MSC4147: Including device keys with Olm-encrypted events

[uhoreg]

Rendered

disclosure: I am on the Spec Core Team and employed by Element. This MSC is written as part of my work in the Crypto team at Element

---

FCP tickyboxes

[turt2live]

Implementation requirements:

• Client sending this information
• Client using this information
• Demonstration of the core problem being solved (likely covered by the above tasks)

[uhoreg]

This has been implemented in the Rust matrix-sdk-crypto crate, both sending and using. Demonstration of the problem being solved: https://youtu.be/b1jJlT2ENT8?feature=shared&t=345

[richvdh]

A few links to the implementation.

On the sender side, the field is added here.

On the receiver side, it is deserialized after decryption into a DecryptedOlmV1Event. It is then used in SenderDataFinder whose job it is to construct a SenderData which records our knowledge about the sending device for a given session.

[richvdh]

I think this is ready for FCP, so:

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to merge this. The next step is review by the rest of the tagged people:

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

Concerns:

• implementation-needs-checking label

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

[richvdh]

I did wonder if we could improve the name here; in particular, to reflect the fact that these are the keys for the sender device.

Suggested change

	We propose to add a new property: `device_keys`, which is a copy of what the
	We propose to add a new property: `sender_device_keys`, which is a copy of what the

[uhoreg]

In the payload, we have also have recipient_keys and keys properties. Given that we've raised the possibility that keys could be removed in a future version, it seems like sender_device_keys would provide some symmetry with recipient_keys.

[turt2live]

@mscbot concern implementation-needs-checking label

(the needs-implementation label was not removed when the FCP was proposed or implementations listed, so I am assuming they have not been checked out of an abundance of caution)

[richvdh]

I've looked at the implementation, and checked that it matches the proposal to the best of my ability.

[turt2live]

@mscbot resolve implementation-needs-checking label