archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-Authored-By: David Baker <dbkr@users.noreply.github.com>
Co-Authored-By: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-Authored-By: Erik Johnston <erikj@jki.re>
pull/1946/head
Hubert Chathi 5 years ago committed by GitHub
parent 9aade7291a
commit 9dfca61ae7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File

10
proposals/1946-secure_server-side_storage.md
Unescape Escape View File

@ -41,7 +41,7 @@ A key with ID `abcdefg` is stored in `m.secret_storage.key.abcdefg`
```json ```json
{ {
"name": "Some key", "name": "Some key",
"algorihm": "m.secret_storage.v1.curve25519-aes-sha2", "algorithm": "m.secret_storage.v1.curve25519-aes-sha2",
// ... other properties according to algorithm // ... other properties according to algorithm
} }
``` ```
@ -52,7 +52,7 @@ will be encrypted with, and that clients will try to use to decrypt data with,
unless the user specifies otherwise. Only one key can be marked as the default unless the user specifies otherwise. Only one key can be marked as the default
at a time. at a time.
Encrypted data is stored in the `account_data` using the `type` defined by the Encrypted data is stored in `account_data` using the `type` defined by the
feature that uses the data. For example, decryption keys for key backups could feature that uses the data. For example, decryption keys for key backups could
be stored under the type `m.megolm_backup.v1.recovery_key`, or the self-signing be stored under the type `m.megolm_backup.v1.recovery_key`, or the self-signing
key for cross-signing could be stored under the type key for cross-signing could be stored under the type
@ -180,7 +180,7 @@ and the number of iterations given in the `iterations` parameter.
Rather than (or in addition to) storing secrets on the server encrypted by a Rather than (or in addition to) storing secrets on the server encrypted by a
shared key, devices can send secrets to each other, encrypted using olm. shared key, devices can send secrets to each other, encrypted using olm.
To request a secret, a client sends a `m.secret.request` event with `action` To request a secret, a client sends a `m.secret.request` device event with `action`
set to `request` to other devices, and `name` set to the name of the secret set to `request` to other devices, and `name` set to the name of the secret
that it wishes to retrieve. A device that wishes to share the secret will that it wishes to retrieve. A device that wishes to share the secret will
reply with a `m.secret.send` event, encrypted using olm. When the original reply with a `m.secret.send` event, encrypted using olm. When the original
@ -229,8 +229,8 @@ also define a secret key mechanism.
## Potential issues ## Potential issues
Keeping all the data and keys in account data means that it may clutter up the Keeping all the data and keys in account data means that it may clutter up
`/sync`. However, clients can filter out the data that they are not interested `/sync` requests. However, clients can filter out the data that they are not interested
in. One possibility for addressing this would be to add a flag to the account in. One possibility for addressing this would be to add a flag to the account
data to indicate whether it should come down the `/sync` or not. data to indicate whether it should come down the `/sync` or not.

Write Preview
Loading…
Cancel
Save