we're using the binary format
This commit is contained in:
parent
a7279d99f0
commit
7b3c98cd98
1 changed files with 0 additions and 78 deletions
|
@ -170,11 +170,6 @@ This proposal defines three verification methods that can be used in
|
||||||
|
|
||||||
### QR code format
|
### 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
|
The QR codes to be displayed and scanned using this format will encode binary
|
||||||
strings in the general form:
|
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), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
|
||||||
base64).
|
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
|
### Message types
|
||||||
|
|
||||||
#### `m.key.verification.start`
|
#### `m.key.verification.start`
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue