You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fallback keys: allows clients to keep receiving e2ee messages even if they are offline for a long time by avoiding a problem known as "one-time key exhaustion". To share encryption keys in a room, devices set up secure channels with each other over olm. To establish an olm channel, a client will claim a one-time key (OTK) on the homeserver that was previously uploaded by the destination device of the channel. These keys are only used once as their name implies and hence if the destination device isn't online to upload more (it usually tries to keep around 50 on the server), they can get exhausted. When that happens, nobody would be able to establish a secure channel anymore and hence won't be able to share keys if they don't have a channel to that device already. The result would be that the destination device wouldn't be able to decrypt your message. This applies both to normal and dehydrated devices. The solution is to have a fallback key that can be used more than once in case a device runs out of one-time keys.
Tasks
upload fallback key whenever device_unused_fallback_key_types is present but doesn't contain our key type in sync response (without deleting them from local storage so we can still use them to decrypt?)
Highlevel description
Fallback keys: allows clients to keep receiving e2ee messages even if they are offline for a long time by avoiding a problem known as "one-time key exhaustion". To share encryption keys in a room, devices set up secure channels with each other over olm. To establish an olm channel, a client will claim a one-time key (OTK) on the homeserver that was previously uploaded by the destination device of the channel. These keys are only used once as their name implies and hence if the destination device isn't online to upload more (it usually tries to keep around 50 on the server), they can get exhausted. When that happens, nobody would be able to establish a secure channel anymore and hence won't be able to share keys if they don't have a channel to that device already. The result would be that the destination device wouldn't be able to decrypt your message. This applies both to normal and dehydrated devices. The solution is to have a fallback key that can be used more than once in case a device runs out of one-time keys.
Tasks
device_unused_fallback_key_types
is present but doesn't contain our key type in sync response (without deleting them from local storage so we can still use them to decrypt?)See https://github.com/uhoreg/matrix-doc/blob/fallback_keys/proposals/2732-olm-fallback-keys.md
The text was updated successfully, but these errors were encountered: