search

Bentheburrito / radio_beam

A WIP Matrix homeserver, powered by the BEAM
GNU Affero General Public License v3.0
1 stars 0 forks source link

10.12 End-to-End Encryption #10

Open Bentheburrito opened 1 month ago

Bentheburrito commented 1 month ago

https://spec.matrix.org/v1.12/client-server-api/#end-to-end-encryption

Some endpoints rely on #3 and #9

Pulling out parts from the spec that are particularly noteworthy for a HS impl:

One-time and fallback keys … Servers must ensure that each one-time key is only claimed once: a homeserver should discard the one time key once it has been given to another user.

When Alice uploads new cross-signing keys, her user ID will appear in the changed property of the device_lists field of the /sync of response of all users who share an encrypted room with her. When Bob sees Alice’s user ID in his /sync, he will call POST /_matrix/client/v3/keys/query to retrieve Alice’s device and cross-signing keys.

Cross-signing

…

Verification methods can be used to verify a user’s master key by using the master public key, encoded using unpadded base64, as the device ID, and treating it as a normal device…Servers therefore must ensure that device IDs will not collide with cross-signing public keys

To avoid leaking of social graphs, servers will only allow users to see:

  • signatures made by the user’s own master, self-signing or user-signing keys,
  • signatures made by the user’s own devices about their own master key,
  • signatures made by other users’ self-signing keys about their respective devices,
  • signatures made by other users’ master keys about their respective self-signing key, or
  • signatures made by other users’ devices about their respective master keys.

Server-side key backups

…Keys can only be written to the most recently created version of the backup. … …When a client uploads a key for a session that the server already has a key for, the server will choose to either keep the existing key or replace it with the new key based on the key metadata as follows:

  • if the keys have different values for is_verified, then it will keep the key that has is_verified set to true;
  • if they have the same values for is_verified, then it will keep the key with a lower first_message_index;
  • and finally, if is_verified and first_message_index are equal, then it will keep the key with a lower forwarded_count.

Key management API

/_matrix/client/v3/keys/changes … The server should include in the results any users who:

  • currently share a room with the calling user (ie, both users have membership state join); and
  • added new device identity keys or removed an existing device with identity keys, between from and to.

Extensions to /sync … The server need only populate this property for an incremental /sync (i.e., one where the since parameter was specified). … For optimal performance, Alice should be added to changed in Bob’s sync only when she updates her devices or cross-signing keys, or when Alice and Bob now share a room but didn’t share any room previously. However, for the sake of simpler logic, a server may add Alice to changed when Alice and Bob share a new room, even if they previously already shared a room.