@ -969,17 +969,17 @@ However, as the session keys are stored on the server encrypted, it
requires users to enter a decryption key to decrypt the session keys.
To create a backup, a client will call [POST
/\_matrix/client/r0/room\_keys/version]() and define how the keys are to
/\_matrix/client/r0/room\_keys/version](#post_matrixclientr0room_keysversion) and define how the keys are to
be encrypted through the backup's `auth_data`; other clients can
discover the backup by calling [GET
/\_matrix/client/r0/room\_keys/version](). Keys are encrypted according
/\_matrix/client/r0/room\_keys/version](#get_matrixclientr0room_keysversion). Keys are encrypted according
to the backup's `auth_data` and added to the backup by calling [PUT
/\_matrix/client/r0/room\_keys/keys]() or one of its variants, and can
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys]() or
be retrieved by calling [GET /\_matrix/client/r0/room\_keys/keys](#put_matrixclientr0room_keyskeys) or
one of its variants. Keys can only be written to the most recently
created version of the backup. Backups can also be deleted using [DELETE
/\_matrix/client/r0/room\_keys/version/{version}](), or individual keys
can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys]() or
/\_matrix/client/r0/room\_keys/version/{version}](#delete_matrixclientr0room_keysversionversion), or individual keys
can be deleted using [DELETE /\_matrix/client/r0/room\_keys/keys](#delete_matrixclientr0room_keyskeys) or
one of its variants.
Clients must only store keys in backups after they have ensured that the
@ -1071,7 +1071,7 @@ The `session_data` field in the backups is constructed as follows:
<trclass="even">
<td><p>forwarding_curve25519_key_chain</p></td>
<td><p>[string]</p></td>
<td><p><strong>Required.</strong> Chain of Curve25519 keys through which this session was forwarded, via <ahref="">m.forwarded_room_key</a> events.</p></td>
<td><p><strong>Required.</strong> Chain of Curve25519 keys through which this session was forwarded, via <ahref="#mforwarded_room_key">m.forwarded_room_key</a> events.</p></td>
</tr>
<trclass="odd">
<td><p>sender_key</p></td>
@ -1205,7 +1205,7 @@ objects described as follows:
<trclass="even">
<td><p>forwarding_curve25519_key_chain</p></td>
<td><p>[string]</p></td>
<td><p>Required. Chain of Curve25519 keys through which this session was forwarded, via <ahref="">m.forwarded_room_key</a> events.</p></td>
<td><p>Required. Chain of Curve25519 keys through which this session was forwarded, via <ahref="#mforwarded_room_key">m.forwarded_room_key</a> events.</p></td>
</tr>
<trclass="odd">
<td><p>room_id</p></td>
@ -1396,7 +1396,7 @@ a way to recover from the failure, making this session replacement
process required.
{{% /boxes/note %}}
To establish a new session, the client sends an [m.dummy](#m-dummy)
To establish a new session, the client sends an [m.dummy](#mdummy)
to-device event to the other party to notify them of the new session
When secrets are stored on the server, they are stored in the user's
[account-data](#module-account-data), using an event type equal to the
[account-data](#client-config), using an event type equal to the
secret's identifier. The keys that secrets are encrypted with are
described by data that is also stored in the user's account-data. Users
can have multiple keys, allowing them to control what sets of secrets
@ -103,7 +103,7 @@ of the data.
<trclass="odd">
<td><p>encrypted</p></td>
<td><p>{string: object}</p></td>
<td><p><strong>Required.</strong> Map from key ID the encrypted data. The exact format for the encrypted data is dependent on the key algorithm. See the definition of <code>AesHmacSha2EncryptedData</code> in the <ahref="#m.secret_storage.v1.aes-hmac-sha2">m.secret_storage.v1.aes-hmac-sha2</a> section.</p></td>
<td><p><strong>Required.</strong> Map from key ID the encrypted data. The exact format for the encrypted data is dependent on the key algorithm. See the definition of <code>AesHmacSha2EncryptedData</code> in the <ahref="#msecret_storagev1aes-hmac-sha2">m.secret_storage.v1.aes-hmac-sha2</a> section.</p></td>
Will
4 years ago