From 5bb2093a3a23ddb883bb009618b9d2c15a755df1 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Fri, 1 Nov 2024 17:41:05 +0000 Subject: [PATCH] another reason to encrypt device_keys --- ...including-device-keys-with-olm-encrypted-events.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/proposals/4147-including-device-keys-with-olm-encrypted-events.md b/proposals/4147-including-device-keys-with-olm-encrypted-events.md index ff7802c2c..55a31f37d 100644 --- a/proposals/4147-including-device-keys-with-olm-encrypted-events.md +++ b/proposals/4147-including-device-keys-with-olm-encrypted-events.md @@ -75,7 +75,7 @@ plaintext payload will now look something like: "ed25519": "" }, "device_keys": { - "algorithms": ["", ""], + "algorithms": ["", ""], "user_id": "", "device_id": "", "keys": { @@ -124,9 +124,12 @@ information to the user; that is left for the future. 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. +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. In addition, by +including it in the encrypted payload, it leaves open the possibility of +it replacing the `keys` property, which must be part of the encrypted payload +to prevent an [unknown key-share attack](https://github.com/element-hq/element-web/issues/2215). The `device_keys` property could be added to the cleartext by the sender's homeserver, rather than by the sending client. Possibly within an `unsigned`