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

redacted #4551

Closed
ghost opened this issue Feb 2, 2019 · 8 comments
Closed

redacted #4551

ghost opened this issue Feb 2, 2019 · 8 comments
Labels
z-feature (Deprecated Label) z-p3 (Deprecated Label)

Comments

@ghost
Copy link

ghost commented Feb 2, 2019

redacted

@poljar
Copy link

poljar commented Feb 2, 2019

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.

@poljar
Copy link

poljar commented Feb 3, 2019

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.

@echto
Copy link

echto commented Feb 4, 2019

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?

@echto
Copy link

echto commented Feb 4, 2019

@gerg5c42g542g2c54g52c, have a Snickers. I feel you are trying to look for a problem that doesn't exist.

@uhoreg
Copy link
Member

uhoreg commented Feb 7, 2019

Anyone possessing this data will also be able to impresonate users without them nor any of their contacts knowing (because this feature not only backs keys up server-side, but also signals to other users that a device is trustworthy - messages coming from it will be represented on your contacts Riot clients in identical way as if the fingerprints were compared manually with QR codes or manually)!

FWIW, cross-signing is a separate feature from key backups. Having key backups alone has no effect on key verification.

@ara4n
Copy link
Member

ara4n commented Feb 7, 2019

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)

@richvdh richvdh changed the title Disable Secure Message Recovery server-wide. Add a config option to disable the keybackup APIs Feb 14, 2019
@richvdh richvdh added z-feature (Deprecated Label) z-p3 (Deprecated Label) labels Feb 6, 2020
@phewitt-uw
Copy link

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.

@Programmierus
Copy link

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...

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
z-feature (Deprecated Label) z-p3 (Deprecated Label)
Projects
None yet
Development

No branches or pull requests

7 participants