wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

we're using the binary format

Browse source
This commit is contained in:
Hubert Chathi 2020-10-16 22:43:04 -04:00
parent a7279d99f0
commit 7b3c98cd98
1 changed files with 0 additions and 78 deletions
Download patch file Download diff file Expand all files Collapse all files

78
proposals/1543-qr_code_key_verification.md
View file

@ -170,11 +170,6 @@ This proposal defines three verification methods that can be used in
### QR code format
Note: only one of the following will be supported. They are all being
documented here while we determine how well different formats are supported.
#### Binary format
The QR codes to be displayed and scanned using this format will encode binary
strings in the general form:
@ -221,79 +216,6 @@ Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in
base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
base64).
#### Base32 format
The QR codes to be displayed and scanned using this format will encode alphanumeric
strings generated as follows:
1. generate a binary string by concatenating:
- the event ID or `transaction_id` of the associated verification
request event, encoded as:
- two bytes in network byte order (big-endian) indicating the length in
bytes of the ID as a UTF-8 string
- the ID as a UTF-8 string
- the first key, as 32 bytes. The key to use depends on the mode field as
described in step 3:
- if "0" or "1", then the user's own master cross-signing public key
- if "2", then the current device's device key
- the second key, as 32 bytes. The key to use depends on the mode field:
- if "0", then what the device thinks the other user's master
cross-signing key is
- if "1", then what the device thinks the other device's device key is
- if "2", then what the device thinks the user's master cross-signing key
is
- a random shared secret, as a byte string. It is suggested to use a secret
that is about 8 bytes long. Note: as we do not share the length of the
secret, and it is not a fixed size, clients will just use the remainder of
binary string as the shared secret.
2. encode the above string using unpadded base32 as defined in RFC4648
3. prepend the resulting string with
- the string "MATRIX"
- one character indicating the version (must by "2")
- one character indicating the QR code verification mode. May be one of the
following values:
- "0" verifying another user with cross-signing
- "1" self-verifying in which the current device does trust the master key
- "2" self-verifying in which the current device does not yet trust the
master key
The QR code is then generated using alphanumeric encoding mode.
#### Base64 format
The QR codes to be displayed and scanned using this format will be a string of
the following form:
- the string "MATRIX"
- one character indicating the version (must by "2")
- one character indicating the QR code verification mode. May be one of the
following values:
- "0" verifying another user with cross-signing
- "1" self-verifying in which the current device does trust the master key
- "2" self-verifying in which the current device does not yet trust the
master key
- the event ID or `transaction_id` of the associated verification
request event, encoded as:
- two bytes in network byte order (big-endian), encoded in unpadded base64 (3
characters), indicating the length in bytes of the ID as a UTF-8 string
- the ID as a UTF-8 string
- the first key as unpadded base64 (43 characters). The key to use depends on
the mode field:
- if "0" or "1", then the user's own master cross-signing public key
- if "2", then the current device's device key
- the second key as unpadded base64 (43 characters). The key to use depends on
the mode field:
- if "0", then what the device thinks the other user's master
cross-signing key is
- if "1", then what the device thinks the other device's device key is
- if "2", then what the device thinks the user's master cross-signing key
is
- a random shared secret, as an ASCII string. It is suggested to use a secret
that is about 11 bytes long. (This is approximately the length of 8 bytes as
a base64 string.) Note: as we do not share the length of the secret, and it
is not a fixed size, clients will just use the remainder of binary string as
the shared secret.
### Message types
#### `m.key.verification.start`