Rename "recovery key" to "backup decryption key" (#1819)

Also, some other editorial improvements, including factoring out our two definitions of the same key encoding algorithm.

Co-authored-by: Travis Ralston <travisr@matrix.org>
This commit is contained in:
Richard van der Hoff 2024-05-14 09:35:42 +01:00 committed by GitHub
parent b0df8e7fb5
commit dac867dd6a
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
5 changed files with 50 additions and 44 deletions

View file

@ -262,22 +262,8 @@ For example, data encrypted using this algorithm could look like this:
##### Key representation
When a user is given a raw key for `m.secret_storage.v1.aes-hmac-sha2`,
it will be presented as a string constructed as follows:
1. The key is prepended by the two bytes `0x8b` and `0x01`
2. All the bytes in the string above, including the two header bytes,
are XORed together to form a parity byte. This parity byte is
appended to the byte string.
3. The byte string is encoded using base58, using the same [mapping as
is used for Bitcoin
addresses](https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart),
that is, using the alphabet
`123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`.
4. The string is formatted into groups of four characters separated by
spaces.
When decoding a raw key, the process should be reversed, with the
exception that whitespace is insignificant in the user's input.
the key should be presented as a string using the common [cryptographic key
representation](/appendices/#cryptographic-key-representation).
##### Deriving keys from passphrases