mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-08-04 15:07:47 +02:00
Compare commits
5 commits
2a2db6eab4
...
da8b1f5be5
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
da8b1f5be5 | ||
|
|
f9dec5dc92 | ||
|
|
16b04f9d6c | ||
|
|
966109da49 | ||
|
|
e2b879d13d |
1
changelogs/appendices/newsfragments/2396.clarification
Normal file
1
changelogs/appendices/newsfragments/2396.clarification
Normal file
|
|
@ -0,0 +1 @@
|
|||
Clarify that clients must avoid producing ambiguous matrix.to URIs. Contributed by @HarHarLinks.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Add further normative language in mutual rooms server behaviour.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Rename OlmPayload to OlmPlaintext to avoid confusion with Olm message Payload Bytes.
|
||||
1
changelogs/olm_megolm/newsfragments/2421.clarification
Normal file
1
changelogs/olm_megolm/newsfragments/2421.clarification
Normal file
|
|
@ -0,0 +1 @@
|
|||
Fix typesetting of some symbols in the Olm/Megolm spec.
|
||||
|
|
@ -887,20 +887,22 @@ https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments>
|
|||
|
||||
The identifier may be a room ID, room alias, or user ID. The
|
||||
extra parameter is only used in the case of permalinks where an event ID
|
||||
is referenced. The matrix.to URI, when referenced, must always start
|
||||
is referenced. The matrix.to URI, when referenced, MUST always start
|
||||
with `https://matrix.to/#/` followed by the identifier.
|
||||
|
||||
The `<additional arguments>` and the preceding question mark are
|
||||
optional and only apply in certain circumstances, documented below.
|
||||
OPTIONAL and only apply in certain circumstances, documented below.
|
||||
|
||||
Clients should not rely on matrix.to URIs falling back to a web server
|
||||
if accessed and instead should perform some sort of action within the
|
||||
Clients SHOULD NOT rely on matrix.to URIs falling back to a web server
|
||||
if accessed and instead SHOULD perform some sort of action within the
|
||||
client. For example, if the user were to click on a matrix.to URI for a
|
||||
room alias, the client may open a view for the user to participate in
|
||||
room alias, the client MAY open a view for the user to participate in
|
||||
the room.
|
||||
|
||||
The components of the matrix.to URI (`<identifier>` and
|
||||
`<extra parameter>`) MUST be percent-encoded as per RFC 3986.
|
||||
Failure to do so will result in downstream software misinterpreting
|
||||
the links as invalid/not turning them into clickable links in UI.
|
||||
|
||||
Examples of matrix.to URIs are:
|
||||
|
||||
|
|
|
|||
|
|
@ -1762,12 +1762,9 @@ Messages with type 1 can only be decrypted with an existing session. If
|
|||
there is no matching session, the client must treat this as an invalid
|
||||
message.
|
||||
|
||||
The plaintext payload is of the form:
|
||||
The plaintext corresponding to the "Cipher-Text" in an an [Olm message](/olm-megolm/olm/#normal-messages) is of the form:
|
||||
|
||||
{{% definition path="api/client-server/definitions/olm_payload" %}}
|
||||
|
||||
The type and content of the plaintext message event are given in the
|
||||
payload.
|
||||
{{% definition path="api/client-server/definitions/olm_plaintext" %}}
|
||||
|
||||
If a client has multiple sessions established with another device, it
|
||||
should use the session from which it last received and successfully
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@
|
|||
|
||||
#### Server behaviour
|
||||
|
||||
The server may decide that the response to this endpoint is too large, and only return a
|
||||
subset of the results. In this case, the server should populate the optional field `next_batch`
|
||||
with an [opaque identifier](/appendices/#opaque-identifiers). The client may then supply
|
||||
The server MAY decide that the response to this endpoint is too large, and only return a
|
||||
subset of the results. In this case, the server populates the optional field `next_batch`
|
||||
with an [opaque identifier](/appendices/#opaque-identifiers). The client can then supply
|
||||
the identifier as the `from` query parameter in a subsequent request, along with the original
|
||||
`user_id`, to fetch the next batch of responses. This will continue until the server no longer
|
||||
inserts `next_batch`, meaning there are no further results.
|
||||
|
|
|
|||
|
|
@ -257,8 +257,8 @@ consists of the following key-value pairs:
|
|||
|
||||
**Name**|**Tag**|**Type**|**Meaning**
|
||||
:-----:|:-----:|:-----:|:-----:
|
||||
Message-Index|0x08|Integer|The index of the ratchet, i
|
||||
Cipher-Text|0x12|String|The cipher-text, Xi, of the message
|
||||
Message-Index|0x08|Integer|The index of the ratchet, \(i\).
|
||||
Cipher-Text|0x12|String|The cipher-text of the message, \(X_i\).
|
||||
|
||||
Within the payload, integers are encoded using a variable length encoding. Each
|
||||
integer is encoded as a sequence of bytes with the high bit set followed by a
|
||||
|
|
|
|||
|
|
@ -17,12 +17,12 @@ side of an \(=\) it means that the output is split.
|
|||
When this document uses \(\operatorname{ECDH}\left(K_A,K_B\right)\) it means
|
||||
that each party computes a Diffie-Hellman agreement using their private key
|
||||
and the remote party's public key.
|
||||
So party \(A\) computes \(\operatorname{ECDH}\left(K_B^{public},K_A^{private}\right)\)
|
||||
and party \(B\) computes \(\operatorname{ECDH}\left(K_A^{public},K_B^{private}\right)\).
|
||||
So party \(A\) computes \(\operatorname{ECDH}\left(K_B^{\mathit{public}},K_A^{\mathit{private}}\right)\)
|
||||
and party \(B\) computes \(\operatorname{ECDH}\left(K_A^{\mathit{public}},K_B^{\mathit{private}}\right)\).
|
||||
|
||||
Where this document uses \(\operatorname{HKDF}\left(salt,IKM,info,L\right)\) it
|
||||
Where this document uses \(\operatorname{HKDF}\left(\mathit{salt},\mathit{IKM},\mathit{info},L\right)\) it
|
||||
refers to the [HMAC-based key derivation function][] with a salt value of
|
||||
\(salt\), input key material of \(IKM\), context string \(info\),
|
||||
\(\mathit{salt}\), input key material of \(\mathit{IKM}\), context string \(\mathit{info}\),
|
||||
and output keying material length of \(L\) bytes.
|
||||
|
||||
## The Olm Algorithm
|
||||
|
|
@ -226,9 +226,9 @@ significant bits are stored in the first byte.
|
|||
|
||||
**Name**|**Tag**|**Type**|**Meaning**
|
||||
:-----:|:-----:|:-----:|:-----:
|
||||
Ratchet-Key|0x0A|String|The public part of the ratchet key, Ti, of the message
|
||||
Chain-Index|0x10|Integer|The chain index, j, of the message
|
||||
Cipher-Text|0x22|String|The cipher-text, Xi, j, of the message
|
||||
Ratchet-Key|0x0A|String|The public part of the ratchet key of the message, \(T_i\).
|
||||
Chain-Index|0x10|Integer|The chain index of the message, \(j\).
|
||||
Cipher-Text|0x22|String|The cipher-text of the message, \(X_{i,j}\).
|
||||
|
||||
The length of the MAC is determined by the authenticated encryption algorithm
|
||||
being used. (Olm version 1 uses [HMAC-SHA-256][], truncated to 8 bytes). The
|
||||
|
|
@ -251,9 +251,9 @@ The payload uses the same key-value format as for normal messages.
|
|||
|
||||
**Name**|**Tag**|**Type**|**Meaning**
|
||||
:-----:|:-----:|:-----:|:-----:
|
||||
One-Time-Key|0x0A|String|The public part of Bob's single-use key, Eb.
|
||||
Base-Key|0x12|String|The public part of Alice's single-use key, Ea.
|
||||
Identity-Key|0x1A|String|The public part of Alice's identity key, Ia.
|
||||
One-Time-Key|0x0A|String|The public part of Bob's single-use key, \(E_B\).
|
||||
Base-Key|0x12|String|The public part of Alice's single-use key, \(E_A\).
|
||||
Identity-Key|0x1A|String|The public part of Alice's identity key, \(I_A\).
|
||||
Message|0x22|String|An embedded Olm message with its own version and MAC.
|
||||
|
||||
## Olm Authenticated Encryption
|
||||
|
|
@ -268,13 +268,13 @@ message key using [HKDF-SHA-256][] using the default salt and an info of
|
|||
|
||||
\[
|
||||
\begin{aligned}
|
||||
AES\_KEY_{i,j}\;\parallel\;HMAC\_KEY_{i,j}\;\parallel\;AES\_IV_{i,j}
|
||||
\mathit{AES\_KEY}_{i,j}\;\parallel\;\mathit{HMAC\_KEY}_{i,j}\;\parallel\;\mathit{AES\_IV}_{i,j}
|
||||
&= \operatorname{HKDF}\left(0,M_{i,j},\text{``OLM\_KEYS"},80\right)
|
||||
\end{aligned}
|
||||
\]
|
||||
|
||||
The plain-text is encrypted with AES-256, using the key \(AES\_KEY_{i,j}\)
|
||||
and the IV \(AES\_IV_{i,j}\) to give the cipher-text, \(X_{i,j}\).
|
||||
The plain-text is encrypted with AES-256, using the key \(\mathit{AES\_KEY}_{i,j}\)
|
||||
and the IV \(\mathit{AES\_IV}_{i,j}\) to give the cipher-text, \(X_{i,j}\).
|
||||
|
||||
Then the entire message (including the Version Byte and all Payload Bytes) are
|
||||
passed through [HMAC-SHA-256][]. The first 8 bytes of the MAC are appended to the message.
|
||||
|
|
|
|||
|
|
@ -14,9 +14,9 @@
|
|||
|
||||
|
||||
type: object
|
||||
title: OlmPayload
|
||||
title: OlmPlaintext
|
||||
description: |-
|
||||
The plaintext payload of an event encrypted using Olm.
|
||||
The plaintext of an event encrypted using Olm.
|
||||
properties:
|
||||
type:
|
||||
type: string
|
||||
|
|
@ -13,7 +13,7 @@ description: |-
|
|||
[Olm](/client-server-api/#molmv1curve25519-aes-sha2).
|
||||
|
||||
The `sender_device_keys` property in the [Olm
|
||||
plaintext](/client-server-api/#definition-olmpayload) MUST be
|
||||
plaintext](/client-server-api/#definition-olmplaintext) MUST be
|
||||
populated. Recipients SHOULD ignore `m.room_key_bundle` messages which omit
|
||||
them.
|
||||
properties:
|
||||
|
|
|
|||
Loading…
Reference in a new issue