mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-03-07 12:14:10 +01:00
add some information and an example
This commit is contained in:
parent
d47e13c6d9
commit
bd9efcdf53
|
|
@ -29,6 +29,11 @@ property, which is a human-readable name. The contents will be signed as
|
||||||
signed JSON using the user's master cross-signing key. Other properties depend
|
signed JSON using the user's master cross-signing key. Other properties depend
|
||||||
on the encryption algorithm, and are described below.
|
on the encryption algorithm, and are described below.
|
||||||
|
|
||||||
|
If a key has the `name` property set to `m.default`, then this key is marked as
|
||||||
|
the default key for the account. The default key is the one that all secrets
|
||||||
|
will be encrypted with, and the clients will try to use to decrypt data with,
|
||||||
|
unless the user specifies otherwise. Only one key can be marked as the default.
|
||||||
|
|
||||||
Encrypted data can be stored using the `account_data` API. The `type` for the
|
Encrypted data can be stored using the `account_data` API. The `type` for the
|
||||||
`account_data` is defined by the feature that uses the data. For example,
|
`account_data` is defined by the feature that uses the data. For example,
|
||||||
decryption keys for key backups could be stored under the type
|
decryption keys for key backups could be stored under the type
|
||||||
|
|
@ -80,7 +85,29 @@ The data is encrypted and MACed as follows:
|
||||||
(The key HKDF, AES, and HMAC steps are the same as what are used for encryption
|
(The key HKDF, AES, and HMAC steps are the same as what are used for encryption
|
||||||
in olm and megolm.)
|
in olm and megolm.)
|
||||||
|
|
||||||
FIXME: add an example of `m.secret_storage.key.*`, and of encrypted data.
|
For example, a key using this algorithm could look like:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"name": "m.default",
|
||||||
|
"algorithm": "m.secret_storage.v1.curve25519-aes-sha2",
|
||||||
|
"pubkey": "base64+public+key"
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
and data encrypted using this algorithm could look like this:
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"encrypted": {
|
||||||
|
"key_id": {
|
||||||
|
"ciphertext": "base64+encoded+encrypted+data",
|
||||||
|
"ephemeral": "base64+ephemeral+key",
|
||||||
|
"mac": "base64+encoded+mac"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
###### Keys
|
###### Keys
|
||||||
|
|
||||||
|
|
@ -181,7 +208,12 @@ data to indicate whether it should come down the `/sync` or not.
|
||||||
|
|
||||||
## Security considerations
|
## Security considerations
|
||||||
|
|
||||||
Yes.
|
By storing information encrypted on the server, this allows the server operator
|
||||||
|
to read the information if they manage to get hold of the decryption keys.
|
||||||
|
In particular, if the key is based on a passphrase and the passphrase can be
|
||||||
|
guessed, then the secrets could be compromised. In order to help protect the
|
||||||
|
secrets, clients should provide feedback to the user when their chosen
|
||||||
|
passphrase is considered weak.
|
||||||
|
|
||||||
## Conclusion
|
## Conclusion
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue