MSC4147: Including device keys with Olm-encrypted events #4147
Conversation
uhoreg
changed the title
turt2live
added
proposal
|
|
||
| When a Megolm session is sent from one device to another via Olm, the recipient | ||
| can | ||
| [query](https://spec.matrix.org/unstable/client-server-api/#post_matrixclientv3keysquery) |
There was a problem hiding this comment.
versioned links throughout please :)
(unstable and latest do not guarantee that links will work over time)
There was a problem hiding this comment.
Implementation requirements:
- Client sending this information
- Client using this information
- Demonstration of the core problem being solved (likely covered by the above tasks)
proposals/4147-including-device-keys-with-olm-encrypted-events.md
Outdated
Show resolved
Hide resolved
| "ed25519:<device_id>": "<our_ed25519_key>", | ||
| "curve25519:<device_id>": "<our_curve25519_key>" |
There was a problem hiding this comment.
note that our_ed25519_key is used to refer to the recipient's ed25519 key further up. I think you mean:
| "ed25519:<device_id>": "<our_ed25519_key>", | |
| "curve25519:<device_id>": "<our_curve25519_key>" | |
| "ed25519:<device_id>": "<sender_ed25519_key>", | |
| "curve25519:<device_id>": "<sender_curve25519_key>" |
| property. If they differ, the recipient should discard the event. | ||
|
|
||
| As the `keys` property is now redundant, it may be removed in a future version | ||
| of Olm. |
There was a problem hiding this comment.
| of Olm. | |
| of the Matrix specification. |
This is nothing to do with Olm, afaict?
|
|
||
| ## Proposal | ||
|
|
||
| The plaintext payload of the [`m.olm.v1.curve25519-aes-sha2` encryption |
There was a problem hiding this comment.
| The plaintext payload of the [`m.olm.v1.curve25519-aes-sha2` encryption | |
| The plaintext payload of `m.room.encrypted` events encrypted with the [`m.olm.v1.curve25519-aes-sha2` encryption |
| The `device_keys` property could be added to the cleartext. That is, it could | ||
| be added as a property to the `m.room.encrypted` event. This information is | ||
| already public, as it is accessible from `/keys/query` (while the device is | ||
| logged in), and does not need to be authenticated as it is protected by .the | ||
| self-signing signature, so it does not seem to need to be encrypted. However, | ||
| there seems to be little reason not to encrypt the information. |
There was a problem hiding this comment.
I feel there was some cryptographic reason why "keys": { "ed25519": "<sender_ed25519_key>" } had to go inside the encrypted part of the events, and, particularly if we hope to get rid of keys at some point, that presumably also applies here. It might be good to fire up the time machine and see if we can remember what that was all about. (Let me know if you draw blanks/think it was before your time)
This patch implements MSC4147[1]. Signed-off-by: Hubert Chathi <[email protected]> [1]: matrix-org/matrix-spec-proposals#4147
| @@ -0,0 +1,135 @@ | |||
| # MSC4147: Including device keys with Olm-encrypted events | |||
There was a problem hiding this comment.
Are we sure we want to do this? It feels like a very blunt solution to the problem, and duplicating per-device metadata on every event ever sent feels very inefficient.
What about letting the origin server keep publishing deleted devices in /keys/query instead? After all, if the server or account has entirely gone away (or reset its cross-signing keys), then we won't be able to check the signatures meaningfully anyway. So we might as well rely on the origin server to keep publishing the keys for us, rather than cluttering every single event with them?
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