Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Element-R: Verifying against a device that does not have the private SSK claims to succeed, but does not #27655

Open
BillCarsonFr opened this issue May 14, 2024 · 2 comments
Labels
A-E2EE A-E2EE-SAS-Verification A-Element-R Issues affecting the port of Element's crypto layer to Rust O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@BillCarsonFr
Copy link
Member

BillCarsonFr commented May 14, 2024

STR:

  • Sign in on a new device
  • Verify against a device which, for some reason, does not have a copy of the private cross-signing keys. (It's not entirely clear how to get into this situation; one way to do it might be to verify against another device which doesn't correctly implement secret sharing).

Observe success message:

image

However, the new device is not actually cross-signed, and doesn't receive the secrets.

  • At the very least, the session that has no private SSK should not accept the verification request
  • We should probably also not offer verifying against a device as a potential verification method if the other devices lack private SSKs; however this may be tricky.
  • We should probably not report verification success until the cross-signature and cross-signing keys are received.

See #21919

@BillCarsonFr
Copy link
Member Author

Other occurence #27502

@kegsay
Copy link
Contributor

kegsay commented Jun 28, 2024

#27623 is similar, but this time it's the backup key that is missing, the other 3 are there.

@richvdh richvdh transferred this issue from another repository Jun 28, 2024
@richvdh richvdh transferred this issue from another repository Jun 28, 2024
@richvdh richvdh added A-Element-R Issues affecting the port of Element's crypto layer to Rust T-Defect labels Jun 28, 2024
@dosubot dosubot bot added A-E2EE O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround labels Jun 28, 2024
@richvdh richvdh changed the title WebR | Force Verification: Edge Case, A session that cannot cross-sign (no private ssk cached) should not be able to accept a verification request. If it can the verification dance will work but the session will not be cross-signed WebR: a session that cannot cross-sign (no private ssk cached) should not be able to accept a verification request Jun 28, 2024
@richvdh richvdh changed the title WebR: a session that cannot cross-sign (no private ssk cached) should not be able to accept a verification request WebR: a session that has no private ssk cached should not be able to accept a verification request Jun 28, 2024
@richvdh richvdh changed the title WebR: a session that has no private ssk cached should not be able to accept a verification request Element-R: Verifying against a device that does not have the private SSK claims to succeed, but does not Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE A-E2EE-SAS-Verification A-Element-R Issues affecting the port of Element's crypto layer to Rust O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

No branches or pull requests

3 participants