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

storing megolm keys serverside #1538

Open
wants to merge 16 commits into
base: master
from

Conversation

Projects
None yet
5 participants
@uhoreg
Member

uhoreg commented Aug 18, 2018

@uhoreg uhoreg added the proposal-pr label Aug 18, 2018

Show resolved Hide resolved proposals/1219-storing-megolm-keys-serverside.md Outdated
On 403 error when trying to `PUT` keys:
1. get the current version
2. notify the user that there is a new backup version, and display relevant

This comment has been minimized.

@ara4n

ara4n Aug 18, 2018

Member

I wonder if we should be exposing multiple backup versions to the user: i.e. "Online backup started by device at ", to help protect the user against a malicious attacker starting a new backup to a) overwrite their actual keys or b) steal their keys. We could also let the user delete their online backups (after doing UI auth) to help them control their keys.

Show resolved Hide resolved proposals/1219-storing-megolm-keys-serverside.md
¹: cross-signing (when that is completed) can be used to verify the device
that signed the key.

This comment has been minimized.

@ara4n

ara4n Aug 18, 2018

Member

I think it would be very useful to spell out the sort of flows we expose via settings as per the original proposal: i.e. the ability to explicitly recover keys from a backup; change (rotate) the recovery key; delete the backup(s); and start a (new) backup. Particularly in terms of how much we should re-auth the user before each operation.

This comment has been minimized.

@uhoreg

uhoreg Oct 30, 2018

Member

This has been mentioned, but doesn't go into much detail. I don't think we need to go into too much detail, since I don't think we should be mandating too much UI-wise in the spec.

uhoreg added some commits Sep 6, 2018

@turt2live turt2live added the T-Core label Sep 10, 2018

@NotAFile

This comment has been minimized.

NotAFile commented Oct 20, 2018

Hm, I don't quite understand the point of this. If this requires exporting and saving a secret key anyway, what does this achieve?

@ara4n

This comment has been minimized.

Member

ara4n commented Oct 20, 2018

It means that the user can store their megolm keys (typically a few megabytes of key data) encrypted on the server, but be able to decrypt & restore that backup using their recovery key (32 bytes). To avoid users having to securely track the 32-byte recovery key somewhere, we also let them optionally encrypt that in turn with a passphrase and store that on the server. (We could also generate the recovery key from a passphrase in the first place, but that would be a problem for rotating the passphrase separately from the key, and would force people to set a passphrase even if they don't want one).

@NotAFile

This comment has been minimized.

NotAFile commented Oct 20, 2018

Ah, I see. Perhaps this rationale could be added to the "background" section.

@uhoreg

This comment has been minimized.

Member

uhoreg commented Oct 20, 2018

Words have been added to the background section.

@uhoreg uhoreg changed the title from [WIP] storing megolm keys serverside to storing megolm keys serverside Oct 30, 2018

@uhoreg uhoreg requested a review from matrix-org/spec-core-team Oct 30, 2018

Show resolved Hide resolved proposals/1219-storing-megolm-keys-serverside.md Outdated
Show resolved Hide resolved proposals/1219-storing-megolm-keys-serverside.md Outdated
This 58-character string is presented to the user to save. Implementations may
add whitespace to the recovery key; adding a space every 4th character is
recommended.

This comment has been minimized.

@dbkr

dbkr Nov 9, 2018

Member

FTR I put this in https://github.com/matrix-org/matrix-doc/pull/1703/files#diff-71799dad5d7a3097d9c19e3f940dd2cfR31 - we should make sure it only ends up in one place in the spec (I made 4 character grouping non-optional on the basis that it seemed better to mandate one format and stick to it).

sending device
- `forwarding_curve25519_key_chain` (array): zero or more curve25519 keys
for devices who forwarded the session key
- `session_key` (string): base64-encoded (unpadded) session key

This comment has been minimized.

@dbkr

dbkr Nov 9, 2018

Member

It's important to note that this is in 'export format' - with any luck this will be defined in the spec for m.forwarded_room_key which you can copy from (or define it in terms of).

@manuroe manuroe referenced this pull request Nov 13, 2018

Merged

E2e keys backup #591

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment