Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Synapse does not tell the clients when it runs out of OTKs #10484

Open
bmarty opened this issue Jul 27, 2021 · 4 comments · Fixed by #10485
Open

Synapse does not tell the clients when it runs out of OTKs #10484

bmarty opened this issue Jul 27, 2021 · 4 comments · Fixed by #10485
Labels
A-E2EE End-to-end encryption for Matrix clients S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.

Comments

@bmarty
Copy link

bmarty commented Jul 27, 2021

Following discussion in #10479 (and especially #10479 (comment)), I've checked the sync response when Synapse does not have OTK (one time key) anymore. So when the number of OTK is changing from N to 0.

Instead of receiving

"device_one_time_keys_count":{"signed_curve25519":0}

The client receives

"device_one_time_keys_count":{}

and so the client cannot distinguish "no change" and "no OTK left", and do not upload new OTK, which at the end breaks decryption of some messages.

Server version: 1.38.0 commit 12c92ee

@richvdh
Copy link
Member

richvdh commented Jul 27, 2021

It seems like this needs clarification in the spec too. Is a server obliged to know about all potential one-time-key algorithms so that it can fully populate this field? What happens if/when we introduce a new algorithm?

Maybe "device_one_time_keys_count":{} should mean "I don't have any one-time keys", and the complete absence of the field should mean "no change".

@anoadragon453
Copy link
Member

@richvdh I too ran into this line of thinking, though the possible algorithm names are specced.

Maybe "device_one_time_keys_count":{} should mean "I don't have any one-time keys", and the complete absence of the field should mean "no change".

What if there is no change in algorithm A, but there is a change in algorithm B? You can't have the absence of "device_one_time_keys_count" in that scenario.

@richvdh
Copy link
Member

richvdh commented Jul 27, 2021

@richvdh I too ran into this line of thinking, though the possible algorithm names are specced.

well they are now, but again: what if we introduce a new algorithm? Clients using the new algorithm will be back where we are now: unable to tell if the server is out of keys or if there is no change.

What if there is no change in algorithm A, but there is a change in algorithm B? You can't have the absence of "device_one_time_keys_count" in that scenario.

I was thinking you'd populate the whole field anyway, including the (redundant) count of algorithm A. But you're right, it's not obvious. We should probably take this over to matrix-doc.

@reivilibre reivilibre added S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. labels Jul 27, 2021
@uhoreg
Copy link
Member

uhoreg commented Jan 11, 2022

The spec has been updated to clarify that a missing algorithm means zero one-time keys are available.

@richvdh richvdh changed the title Synapse does not tell the clients when it gets out of OTK Synapse does not tell the clients when it runs out of OTKs Jul 27, 2022
@MadLittleMods MadLittleMods added the A-E2EE End-to-end encryption for Matrix clients label Jun 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-E2EE End-to-end encryption for Matrix clients S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants