-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
redacted #4551
Comments
Those same encryption keys are shared between users by uploading them to the server in the first place. A malicious server could keep them forever when they are shared the first time anyways. This doesn't seem to add any new attack vectors, provided that the encryption scheme works as intended. |
The proposal talks about inbound group session keys, they are used to decrypt room messages. Those same keys can be exported into a file, and need to be shared with room participants so they can decrypt messages originating from you. If you want more information check out the proposal and the client-server API for E2E encryption. |
The user's keys are protected by a passphrase when the keys are backed up to the homeserver, are they not? So, how can this be a huge security and privacy issue? |
@gerg5c42g542g2c54g52c, have a Snickers. I feel you are trying to look for a problem that doesn't exist. |
FWIW, cross-signing is a separate feature from key backups. Having key backups alone has no effect on key verification. |
i agree that we should have a config option to disable the keybackup APIs if not wanted on a given HS. this would need to be reflected in the caps API (or alternatively we could check whether the API 404s to determine availability) |
Hi there, has there been any movement on this one? we have issues where on a self-hosted server we just cannot rely on users to manage their own key backups, nor is it possible to get them to reliably follow through the steps. An option to just turn off the the whole key backup steps would make things more usable. |
While this still pending can somebody may be post an example how to set and get a recovery key for the user through the API? I'd just pre-generate them for my users and store in a safe place. That's the only way to help enterprise users not to forget those keys... |
redacted
The text was updated successfully, but these errors were encountered: