From 71988263f3de6dede3fad200d83784c18af46f8a Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Fri, 17 Dec 2021 08:45:19 -0500 Subject: [PATCH] clarify which signature to check (#3573) --- .../client_server/newsfragments/3573.clarification | 1 + .../client-server-api/modules/end_to_end_encryption.md | 10 +++++----- 2 files changed, 6 insertions(+), 5 deletions(-) create mode 100644 changelogs/client_server/newsfragments/3573.clarification diff --git a/changelogs/client_server/newsfragments/3573.clarification b/changelogs/client_server/newsfragments/3573.clarification new file mode 100644 index 00000000..c7c7da0e --- /dev/null +++ b/changelogs/client_server/newsfragments/3573.clarification @@ -0,0 +1 @@ +Clarify which signature to check when decrypting `m.olm.v1.curve25519-aes-sha2` messages. diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index 1faa108c..7056a1b9 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -1461,11 +1461,11 @@ user, and `recipient_keys` to the local ed25519 key. Clients must confirm that the `sender_key` and the `ed25519` field value under the `keys` property match the keys returned by [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) for -the given user, and must also verify the signature of the payload. -Without this check, a client cannot be sure that the sender device owns -the private part of the ed25519 key it claims to have in the Olm -payload. This is crucial when the ed25519 key corresponds to a verified -device. +the given user, and must also verify the signature of the keys from the +`/keys/query` response. Without this check, a client cannot be sure that +the sender device owns the private part of the ed25519 key it claims to +have in the Olm payload. This is crucial when the ed25519 key corresponds +to a verified device. If a client has multiple sessions established with another device, it should use the session from which it last received and successfully