assets/scss/_styles_project.scss

@@ -502,13 +502,6 @@ Make padding symmetrical (this selector is used in the default styles to apply p
   }
 }
 
-/* Adjust the width of math to match normal paragraphs */
-@include media-breakpoint-up(lg) {
-  .katex-display {
-    max-width: 80%;
-  }
-}
-
 /* Adjust default styles for info banner */
 .pageinfo-primary {
   @include media-breakpoint-up(lg) {

changelogs/internal/newsfragments/2226.clarification

@@ -1 +0,0 @@
-Inline Olm & Megolm specifications.

changelogs/internal/newsfragments/2241.clarification

@@ -1 +0,0 @@
-Inline Olm & Megolm specifications.

config/_default/hugo.toml

@@ -43,15 +43,6 @@ description = "Home of the Matrix specification for decentralised communication"
     [markup.goldmark.renderer]
       # Enables us to render raw HTML
       unsafe = true
-    [markup.goldmark.extensions]
-      # Tell Goldmark to pass delimited blocks through the `render-passthrough` render hook.
-      # This is used to render the maths in the Olm spec.
-      # See: https://gohugo.io/functions/transform/tomath/#step-1.
-      [markup.goldmark.extensions.passthrough]
-        enable = true
-        [markup.goldmark.extensions.passthrough.delimiters]
-          block = [['\[', '\]']]
-          inline = [['\(', '\)']]
   [markup.highlight]
       # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
       # If the style is changed, remember to regenerate the CSS with:
@@ -130,9 +121,7 @@ sidebar_menu_compact = true
 [[server.headers]]
   for = '/**'
   [server.headers.values]
-    # `style-src 'unsafe-inline'` is needed to correctly render the maths in the Olm spec:
-    # https://github.com/KaTeX/KaTeX/issues/4096
-    Content-Security-Policy = "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; media-src 'self'; child-src 'self'; form-action 'self'; object-src 'self'"
+    Content-Security-Policy = "default-src 'self'; style-src 'self'; script-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; media-src 'self'; child-src 'self'; form-action 'self'; object-src 'self'"
     X-XSS-Protection = "1; mode=block"
     X-Content-Type-Options = "nosniff"
     # Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"

content/_index.md

@@ -25,7 +25,6 @@ The specification consists of the following parts:
 * [Identity Service API](/identity-service-api)
 * [Push Gateway API](/push-gateway-api)
 * [Room Versions](/rooms)
-* [Olm & Megolm](/olm-megolm)
 * [Appendices](/appendices)
 
 Additionally, this introduction page contains the key baseline
@@ -152,7 +151,7 @@ request.
 
 How data flows between clients:
 
-```nohighlight
+```
     { Matrix client A }                             { Matrix client B }
         ^          |                                    ^          |
         |  events  |  Client-Server API                 |  events  |

content/appendices.md

@@ -749,13 +749,13 @@ history (a permalink).
 
 The Matrix URI scheme is defined as follows (`[]` enclose optional parts, `{}`
 enclose variables):
-```nohighlight
+```
 matrix:[//{authority}/]{type}/{id without sigil}[/{type}/{id without sigil}...][?{query}][#{fragment}]
 ```
 
 As a schema, this can be represented as:
 
-```nohighlight
+```
 MatrixURI = "matrix:" hier-part [ "?" query ] [ "#" fragment ]
 hier-part = [ "//" authority "/" ] path
 path = entity-descriptor ["/" entity-descriptor]
@@ -865,7 +865,7 @@ below for more details.
 A matrix.to URI has the following format, based upon the specification
 defined in [RFC 3986](https://tools.ietf.org/html/rfc3986):
 
-```nohighlight
+```
 https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments>
 ```
 

content/application-service-api.md

@@ -178,13 +178,13 @@ The application service API provides a transaction API for sending a
 list of events. Each list of events includes a transaction ID, which
 works as follows:
 
-```nohighlight
+```
     Typical
     HS ---> AS : Homeserver sends events with transaction ID T.
        <---    : Application Service sends back 200 OK.
 ```
 
-```nohighlight
+```
     AS ACK Lost
     HS ---> AS : Homeserver sends events with transaction ID T.
        <-/-    : AS 200 OK is lost.
@@ -258,7 +258,7 @@ have been omitted for brevity):
 
 **Typical**
 
-```nohighlight
+```
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
     HS <--- AS : 200 OK {}
@@ -267,7 +267,7 @@ AS <--- HS : 200 OK {"duration_ms": 123}
 
 **Incorrect `hs_token`**
 
-```nohighlight
+```
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
     HS <--- AS : 403 Forbidden {"errcode": "M_FORBIDDEN"}
@@ -276,7 +276,7 @@ AS <--- HS : 502 Bad Gateway {"errcode": "M_BAD_STATUS", "status": 403, "body":
 
 **Can't connect to appservice**
 
-```nohighlight
+```
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS -/-> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
 AS <--- HS : 502 Bad Gateway {"errcode": "M_CONNECTION_FAILED"}

content/client-server-api/_index.md

@@ -687,7 +687,7 @@ request parameter.
 A client should first make a request with no `auth` parameter.
 The homeserver returns an HTTP 401 response, with a JSON body, as follows:
 
-```nohighlight
+```
 HTTP/1.1 401 Unauthorized
 Content-Type: application/json
 ```
@@ -733,7 +733,7 @@ given. It also contains other keys dependent on the auth type being
 attempted. For example, if the client is attempting to complete auth
 type `example.type.foo`, it might submit something like this:
 
-```nohighlight
+```
 POST /_matrix/client/v3/endpoint HTTP/1.1
 Content-Type: application/json
 ```
@@ -756,7 +756,7 @@ along with the same object as when no authentication was attempted, with
 the addition of the `completed` key which is an array of auth types the
 client has completed successfully:
 
-```nohighlight
+```
 HTTP/1.1 401 Unauthorized
 Content-Type: application/json
 ```
@@ -790,7 +790,7 @@ but the client may make a second attempt, it returns the same HTTP
 status 401 response as above, with the addition of the standard
 `errcode` and `error` fields describing the error. For example:
 
-```nohighlight
+```
 HTTP/1.1 401 Unauthorized
 Content-Type: application/json
 ```
@@ -820,7 +820,7 @@ Content-Type: application/json
 If the request fails for a reason other than authentication, the server
 returns an error message in the standard format. For example:
 
-```nohighlight
+```
 HTTP/1.1 400 Bad request
 Content-Type: application/json
 ```
@@ -859,7 +859,7 @@ must still give a 401 response to requests with no auth data.
 At a high level, the requests made for an API call completing an auth
 flow with three stages will resemble the following diagram:
 
-```nohighlight
+```
     _______________________
     |       Stage 0         |
     | No auth               |
@@ -918,7 +918,7 @@ This specification defines the following auth types:
 To use this authentication type, clients should submit an auth dict as
 follows:
 
-```nohighlight
+```
 {
   "type": "m.login.password",
   "identifier": {
@@ -1168,7 +1168,7 @@ user during registration, if applicable.
 
 1. A client might submit a registration request as follows:
 
-   ```nohighlight
+   ```
    POST /_matrix/client/v3/register
    ```
    ```json
@@ -1181,7 +1181,7 @@ user during registration, if applicable.
 2. The server requires the user to accept some terms of service before
    registration, so returns the following response:
 
-   ```nohighlight
+   ```
    HTTP/1.1 401 Unauthorized
    Content-Type: application/json
    ```
@@ -1216,7 +1216,7 @@ user during registration, if applicable.
 
 4. The client repeats the registration request, confirming that the user has
    accepted the documents:
-   ```nohighlight
+   ```
    POST /_matrix/client/v3/register
    ```
    ```json
@@ -1231,7 +1231,7 @@ user during registration, if applicable.
    ```
 
 5. All authentication steps have now completed, so the request is successful:
-   ```nohighlight
+   ```
    HTTP/1.1 200 OK
    Content-Type: application/json
    ```
@@ -1652,7 +1652,7 @@ This authorization request URL must be opened in the user's browser:
 
 Sample authorization request, with extra whitespaces for readability:
 
-```nohighlight
+```
 https://account.example.com/oauth2/auth?
     client_id     = s6BhdRkqt3 &
     response_type = code &
@@ -1685,7 +1685,7 @@ used in the authorization request.
 
 A successful authorization will have a `code` value, for example:
 
-```nohighlight
+```
 https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&code=iuB7Eiz9heengah1joh2ioy9ahChuP6R
 ```
 
@@ -1697,7 +1697,7 @@ A failed authorization will have the following values:
 
 For example:
 
-```nohighlight
+```
 https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request.&error_uri=https%3A%2F%2Ferrors.example.com%2F
 ```
 
@@ -1722,7 +1722,7 @@ type, the expiration time, and the refresh token.
 
 Sample token request:
 
-```nohighlight
+```
 POST /oauth2/token HTTP/1.1
 Host: account.example.com
 Content-Type: application/x-www-form-urlencoded
@@ -2045,7 +2045,7 @@ When generating a new `device_id`, the client SHOULD generate a random string
 with enough entropy. It SHOULD only use characters from the unreserved character
 list defined by [RFC 3986 section 2.3](https://datatracker.ietf.org/doc/html/rfc3986#section-2.3):
 
-```nohighlight
+```
 unreserved = a-z / A-Z / 0-9 / "-" / "." / "_" / "~"
 ```
 
@@ -2058,7 +2058,7 @@ In any case it MUST only use characters allowed by the OAuth 2.0 scope
 definition in [RFC 6749 section 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3),
 which is defined as the following ASCII ranges:
 
-```nohighlight
+```
 %x21 / %x23-5B / %x5D-7E
 ```
 
@@ -2200,7 +2200,7 @@ The body of the request includes the following parameters, encoded as
 
 For example, revoking using the access token:
 
-```nohighlight
+```
 POST /oauth2/revoke HTTP/1.1
 Host: auth.example.com
 Content-Type: application/x-www-form-urlencoded
@@ -2245,7 +2245,7 @@ set to `true` on all but the following Client-Server APIs:
 Servers MAY additionally include details of why the lock was applied in
 the `error` field.
 
-```nohighlight
+```
 HTTP/1.1 401 Unauthorized
 Content-Type: application/json
 ```
@@ -2325,7 +2325,7 @@ When a client attempts to perform an action while suspended, the server MUST
 respond with a `403 Forbidden` error response with `M_USER_SUSPENDED` as the
 error code, as shown below:
 
-```nohighlight
+```
 HTTP/1.1 403 Forbidden
 Content-Type: application/json
 ```
@@ -2933,7 +2933,7 @@ For example, a `/sync` request might return a range of four events
 `E2`, `E3`, `E4` and `E5` within a given room, omitting two prior events
 `E0` and `E1`. This can be visualised as follows:
 
-```nohighlight
+```
     [E0]->[E1]->[E2]->[E3]->[E4]->[E5]
                ^                      ^
                |                      |
@@ -2951,7 +2951,7 @@ deprecated `/events` API) support long-polling in this way.
 Continuing the example above, an incremental sync might report
 a single new event `E6`. The response can be visualised as:
 
-```nohighlight
+```
     [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]
                                       ^     ^
                                       |     |
@@ -2975,7 +2975,7 @@ the `since` parameter. The server knows about four new events, `E7`, `E8`,
 the server sends a `limited` response containing `E8`, `E9` and `E10`but
 omitting `E7`. This forms a gap, which we can see in the visualisation:
 
-```nohighlight
+```
                                             | gap |
                                             | <-> |
     [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10]
@@ -3070,29 +3070,29 @@ to another.
 
 Valid requests look like:
 
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.example.event
 { "key" : "without a state key" }
 ```
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.another.example.event/foo
 { "key" : "with 'foo' as the state key" }
 ```
 
 In contrast, these requests are invalid:
 
-```nohighlight
+```
 POST /rooms/!roomid:domain/state/m.example.event/
 { "key" : "cannot use POST here" }
 ```
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11
 { "key" : "txnIds are not supported" }
 ```
 
 Care should be taken to avoid setting the wrong `state key`:
 
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.another.example.event/11
 { "key" : "with '11' as the state key, but was probably intended to be a txnId" }
 ```
@@ -3100,7 +3100,7 @@ PUT /rooms/!roomid:domain/state/m.another.example.event/11
 The `state_key` is often used to store state about individual users, by
 using the user ID as the `state_key` value. For example:
 
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
 { "animal" : "cat", "reason": "fluffy" }
 ```
@@ -3108,7 +3108,7 @@ PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
 In some cases, there may be no need for a `state_key`, so it can be
 omitted:
 
-```nohighlight
+```
 PUT /rooms/!roomid:domain/state/m.room.bgd.color
 { "color": "red", "hex": "#ff0000" }
 ```

content/client-server-api/modules/content_repo.md

@@ -33,7 +33,7 @@ specification.
 Content locations are represented as Matrix Content (`mxc://`) URIs. They
 look like:
 
-```nohighlight
+```
 mxc://<server-name>/<media-id>
 
 <server-name> : The name of the homeserver where this content originated, e.g. matrix.org

content/client-server-api/modules/end_to_end_encryption.md

@@ -18,7 +18,7 @@ exchange fingerprints between users to build a web of trust.
 device. This may include long-term identity keys, and/or one-time
 keys.
 
-```nohighlight
+```
       +----------+  +--------------+
       | Bob's HS |  | Bob's Device |
       +----------+  +--------------+
@@ -29,7 +29,7 @@ keys.
 
 2) Alice requests Bob's public identity keys and supported algorithms.
 
-```nohighlight
+```
       +----------------+  +------------+  +----------+
       | Alice's Device |  | Alice's HS |  | Bob's HS |
       +----------------+  +------------+  +----------+
@@ -40,7 +40,7 @@ keys.
 
 3) Alice selects an algorithm and claims any one-time keys needed.
 
-```nohighlight
+```
       +----------------+  +------------+  +----------+
       | Alice's Device |  | Alice's HS |  | Bob's HS |
       +----------------+  +------------+  +----------+
@@ -491,7 +491,7 @@ this example, Bob's device sends the `m.key.verification.start`, Alice's device
 could also send that message. As well, the order of the
 `m.key.verification.done` messages could be reversed.
 
-```nohighlight
+```
     +---------------+ +---------------+                    +-------------+ +-------------+
     | AliceDevice1  | | AliceDevice2  |                    | BobDevice1  | | BobDevice2  |
     +---------------+ +---------------+                    +-------------+ +-------------+
@@ -695,7 +695,7 @@ The process between Alice and Bob verifying each other would be:
 The wire protocol looks like the following between Alice and Bob's
 devices:
 
-```nohighlight
+```
     +-------------+                    +-----------+
     | AliceDevice |                    | BobDevice |
     +-------------+                    +-----------+
@@ -969,7 +969,7 @@ she can trust Bob's device if:
 
 The following diagram illustrates how keys are signed:
 
-```nohighlight
+```
     +------------------+                ..................   +----------------+
     | +--------------+ |   ..................            :   | +------------+ |
     | |              v v   v            :   :            v   v v            | |
@@ -1000,7 +1000,7 @@ the user who created them.
 The following diagram illustrates Alice's view, hiding the keys and
 signatures that she cannot see:
 
-```nohighlight
+```
     +------------------+                +----------------+   +----------------+
     | +--------------+ |                |                |   | +------------+ |
     | |              v v                |                v   v v            | |
@@ -1218,7 +1218,7 @@ The binary segment MUST be of the following form:
 
 For example, if Alice displays a QR code encoding the following binary data:
 
-```nohighlight
+```
       "MATRIX"    |ver|mode| len   | event ID
  4D 41 54 52 49 58  02  00   00 2D   21 41 42 43 44 ...
 | user's cross-signing key    | other user's cross-signing key | shared secret

content/client-server-api/modules/push.md

@@ -1,7 +1,7 @@
 
 ### Push Notifications
 
-```nohighlight
+```
                                    +--------------------+  +-------------------+
                   Matrix HTTP      |                    |  |                   |
              Notification Protocol |   App Developer    |  |   Device Vendor   |

content/client-server-api/modules/receipts.md

@@ -214,7 +214,7 @@ before delivering them to clients.
 Some receipts are sent across federation as EDUs with type `m.receipt`. The
 format of the EDUs are:
 
-```nohighlight
+```
 {
     <room_id>: {
         <receipt_type>: {

content/client-server-api/modules/secrets.md

@@ -157,7 +157,7 @@ Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
 
 `org.example.some.secret`:
 
-```nohighlight
+```
 {
   "encrypted": {
     "key_id_1": {
@@ -177,7 +177,7 @@ and the key descriptions for the keys would be:
 
 `m.secret_storage.key.key_id_1`:
 
-```nohighlight
+```
 {
   "name": "Some key",
   "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
@@ -187,7 +187,7 @@ and the key descriptions for the keys would be:
 
 `m.secret_storage.key.key_id_2`:
 
-```nohighlight
+```
 {
   "name": "Some other key",
   "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
@@ -199,7 +199,7 @@ If `key_id_1` is the default key, then we also have:
 
 `m.secret_storage.default_key`:
 
-```nohighlight
+```
 {
   "key": "key_id_1"
 }
@@ -294,7 +294,7 @@ in the `iterations` parameter.
 
 Example:
 
-```nohighlight
+```
 {
     "passphrase": {
         "algorithm": "m.pbkdf2",

content/client-server-api/modules/spaces.md

@@ -58,7 +58,7 @@ parent to the room. The `state_key` for the event is the child room's ID.
 
 For example, to achieve the following:
 
-```nohighlight
+```
 #space:example.org
     #general:example.org (!abcdefg:example.org)
     !private:example.org

content/client-server-api/modules/sso_login.md

@@ -67,7 +67,7 @@ opening an embedded web view.
 
 These steps are illustrated as follows:
 
-```nohighlight
+```
     Matrix Client                        Matrix Homeserver      Auth Server
         |                                       |                   |
         |-------------(0) GET /login----------->|                   |

content/client-server-api/modules/third_party_invites.md

@@ -44,7 +44,7 @@ If the lookup yields a result for a Matrix User ID then the normal [invite
 process](/server-server-api/#inviting-to-a-room) can be initiated. This process
 ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                    +-----------------+
     | Client  |                         | Homeserver  |                                    | IdentityServer  |
     +---------+                         +-------------+                                    +-----------------+
@@ -74,7 +74,7 @@ the invite on the identity server with a call to
 and emit a valid [`m.room.third_party_invite`](#mroomthird_party_invite) event
 to the room. This process ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                               +-----------------+
     | Client  |                         | Homeserver  |                                               | IdentityServer  |
     +---------+                         +-------------+                                               +-----------------+
@@ -133,7 +133,7 @@ and an identity server IS, the full sequence for a third-party invite
 would look like the following. This diagram assumes H1 and H2 are
 residents of the room while H3 is attempting to join.
 
-```nohighlight
+```
     +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+
     | UserA | | ThirdPartyUser  |         | H1  |                                          | H2  |           | H3  |                      | IS  |
     +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+

content/client-server-api/modules/voip_events.md

@@ -129,7 +129,7 @@ or not there have been any changes to the Matrix spec.
 
 A call is set up with message events exchanged as follows:
 
-```nohighlight
+```
     Caller                    Callee
     [Place Call]
     m.call.invite ----------->
@@ -144,7 +144,7 @@ A call is set up with message events exchanged as follows:
 
 Or a rejected call:
 
-```nohighlight
+```
     Caller                      Callee
     m.call.invite ------------>
     m.call.candidate --------->

content/olm-megolm/_index.md

@@ -1,10 +0,0 @@
----
-title: "Olm & Megolm"
-weight: 61
-type: docs
----
-
-Matrix uses the Olm and Megolm cryptographic ratchets for [end-to-end encryption](../client-server-api/#end-to-end-encryption).
-
--   [Olm: A Cryptographic Ratchet](/olm-megolm/olm/)
--   [Megolm group ratchet](/olm-megolm/megolm/)

content/olm-megolm/megolm.md

@@ -1,378 +0,0 @@
----
-title: "Megolm group ratchet"
-weight: 20
-type: docs
----
-
-An AES-based cryptographic ratchet intended for group communications.
-
-## Background
-
-The Megolm ratchet is intended for encrypted messaging applications where there
-may be a large number of recipients of each message, thus precluding the use of
-peer-to-peer encryption systems such as [Olm][].
-
-It also allows a recipient to decrypt received messages multiple times. For
-instance, in client/server applications, a copy of the ciphertext can be stored
-on the (untrusted) server, while the client need only store the session keys.
-
-## Overview
-
-Each participant in a conversation uses their own outbound session for
-encrypting messages. A session consists of a ratchet and an [Ed25519][] keypair.
-
-Secrecy is provided by the ratchet, which can be wound forwards but not
-backwards, and is used to derive a distinct message key for each message.
-
-Authenticity is provided via Ed25519 signatures.
-
-The value of the ratchet, and the public part of the Ed25519 key, are shared
-with other participants in the conversation via secure peer-to-peer
-channels. Provided that peer-to-peer channel provides authenticity of the
-messages to the participants and deniability of the messages to third parties,
-the Megolm session will inherit those properties.
-
-## The Megolm ratchet algorithm
-
-The Megolm ratchet \(R_i\) consists of four parts, \(R_{i,j}\) for
-\(j \in {0,1,2,3}\). The length of each part depends on the hash function
-in use (256 bits for this version of Megolm).
-
-The ratchet is initialised with cryptographically-secure random data, and
-advanced as follows:
-
-\[
-\begin{aligned}
-R_{i,0} &=
-  \begin{cases}
-  H_0\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  R_{i-1,0} &\text{otherwise}
-  \end{cases}\\
-R_{i,1} &=
-  \begin{cases}
-  H_1\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_1\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  R_{i-1,1} &\text{otherwise}
-  \end{cases}\\
-R_{i,2} &=
-  \begin{cases}
-  H_2\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_2\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  H_2\left(R_{2^8(p-1),2}\right) &\text{if }\exists p | i = 2^8p\\
-  R_{i-1,2} &\text{otherwise}
-  \end{cases}\\
-R_{i,3} &=
-  \begin{cases}
-  H_3\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_3\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  H_3\left(R_{2^8(p-1),2}\right) &\text{if }\exists p | i = 2^8p\\
-  H_3\left(R_{i-1,3}\right) &\text{otherwise}
-  \end{cases}
-\end{aligned}
-\]
-
-where \(H_0\), \(H_1\), \(H_2\), and \(H_3\) are different hash
-functions. In summary: every \(2^8\) iterations, \(R_{i,3}\) is
-reseeded from \(R_{i,2}\). Every \(2^{16}\) iterations, \(R_{i,2}\)
-and \(R_{i,3}\) are reseeded from \(R_{i,1}\). Every \(2^{24}\)
-iterations, \(R_{i,1}\), \(R_{i,2}\) and \(R_{i,3}\) are reseeded
-from \(R_{i,0}\).
-
-The complete ratchet value, \(R_{i}\), is hashed to generate the keys used
-to encrypt each message. This scheme allows the ratchet to be advanced an
-arbitrary amount forwards while needing at most 1020 hash computations.  A
-client can decrypt chat history onwards from the earliest value of the ratchet
-it is aware of, but cannot decrypt history from before that point without
-reversing the hash function.
-
-This allows a participant to share its ability to decrypt chat history with
-another from a point in the conversation onwards by giving a copy of the
-ratchet at that point in the conversation.
-
-
-## The Megolm protocol
-
-### Session setup
-
-Each participant in a conversation generates their own Megolm session. A
-session consists of three parts:
-
-* a 32 bit counter, \(i\).
-* an [Ed25519][] keypair, \(K\).
-* a ratchet, \(R_i\), which consists of four 256-bit values,
-  \(R_{i,j}\) for \(j \in {0,1,2,3}\).
-
-The counter \(i\) is initialised to \(0\). A new Ed25519 keypair is
-generated for \(K\). The ratchet is simply initialised with 1024 bits of
-cryptographically-secure random data.
-
-A single participant may use multiple sessions over the lifetime of a
-conversation. The public part of \(K\) is used as an identifier to
-discriminate between sessions.
-
-### Sharing session data
-
-To allow other participants in the conversation to decrypt messages, the
-session data is formatted as described in [Session-sharing format](#session-sharing-format). It is then
-shared with other participants in the conversation via a secure peer-to-peer
-channel (such as that provided by [Olm][]).
-
-When the session data is received from other participants, the recipient first
-checks that the signature matches the public key. They then store their own
-copy of the counter, ratchet, and public key.
-
-### Message encryption
-
-This version of Megolm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding and
-[HMAC-SHA-256][] (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key,
-and 128 bit AES IV are derived from the megolm ratchet \(R_i\):
-
-\[
-\begin{aligned}
- \mathit{AES\_KEY}_{i}\;\parallel\;\mathit{HMAC\_KEY}_{i}\;\parallel\;\mathit{AES\_IV}_{i}
-    &= \operatorname{HKDF}\left(0,\,R_{i},\text{"MEGOLM\_KEYS"},\,80\right) \\
-\end{aligned}
-\]
-
-where \(\parallel\) represents string splitting, and
-\(\operatorname{HKDF}\left(\mathit{salt},\,\mathit{IKM},\,\mathit{info},\,L\right)\)
-refers to the [HMAC-based key
-derivation function][] using using [SHA-256][] as the hash function
-([HKDF-SHA-256][]) with a salt value of \(\mathit{salt}\), input key material of
-\(\mathit{IKM}\), context string \(\mathit{info}\), and output keying material length of
-\(L\) bytes.
-
-The plain-text is encrypted with AES-256, using the key \(\mathit{AES\_KEY}_{i}\)
-and the IV \(\mathit{AES\_IV}_{i}\) to give the cipher-text, \(X_{i}\).
-
-The ratchet index \(i\), and the cipher-text \(X_{i}\), are then packed
-into a message as described in [Message format](#message-format). Then the entire message
-(including the version bytes and all payload bytes) are passed through
-HMAC-SHA-256. The first 8 bytes of the MAC are appended to the message.
-
-Finally, the authenticated message is signed using the Ed25519 keypair; the 64
-byte signature is appended to the message.
-
-The complete signed message, together with the public part of \(K\) (acting
-as a session identifier), can then be sent over an insecure channel. The
-message can then be authenticated and decrypted only by recipients who have
-received the session data.
-
-### Advancing the ratchet
-
-After each message is encrypted, the ratchet is advanced. This is done as
-described in [The Megolm ratchet algorithm](#the-megolm-ratchet-algorithm), using the following definitions:
-
-\[
-\begin{aligned}
-    H_0(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x00"}) \\
-    H_1(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x01"}) \\
-    H_2(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x02"}) \\
-    H_3(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x03"}) \\
-\end{aligned}
-\]
-
-where \(\operatorname{HMAC}(A, T)\) is the HMAC-SHA-256 of ``T``, using ``A`` as the
-key.
-
-For outbound sessions, the updated ratchet and counter are stored in the
-session.
-
-In order to maintain the ability to decrypt conversation history, inbound
-sessions should store a copy of their earliest known ratchet value (unless they
-explicitly want to drop the ability to decrypt that history - see [Partial
-Forward Secrecy](#partial-forward-secrecy)). They may also choose to cache calculated ratchet values,
-but the decision of which ratchet states to cache is left to the application.
-
-## Data exchange formats
-
-### Session sharing format
-
-This format is used for the initial sharing of a Megolm session with other
-group participants who need to be able to read messages encrypted by this
-session.
-
-The session sharing format is as follows:
-
-```nohighlight
-+---+----+--------+--------+--------+--------+------+-----------+
-| V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature |
-+---+----+--------+--------+--------+--------+------+-----------+
-0   1    5        37       69      101      133    165         229   bytes
-```
-
-The version byte, ``V``, is ``"\x02"``.
-
-This is followed by the ratchet index, \(i\), which is encoded as a
-big-endian 32-bit integer; the ratchet values \(R_{i,j}\); and the public
-part of the Ed25519 keypair \(K\).
-
-The data is then signed using the Ed25519 keypair, and the 64-byte signature is
-appended.
-
-### Session export format
-
-Once the session is initially shared with the group participants, each
-participant needs to retain a copy of the session if they want to maintain
-their ability to decrypt messages encrypted with that session.
-
-For forward-secrecy purposes, a participant may choose to store a ratcheted
-version of the session. But since the ratchet index is covered by the
-signature, this would invalidate the signature. So we define a similar format,
-called the *session export format*, which is identical to the [session sharing
-format](#session-sharing-format) except for dropping the signature.
-
-The Megolm session export format is thus as follows:
-
-```nohighlight
-+---+----+--------+--------+--------+--------+------+
-| V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub |
-+---+----+--------+--------+--------+--------+------+
-0   1    5        37       69      101      133    165   bytes
-```
-
-The version byte, ``V``, is ``"\x01"``.
-
-This is followed by the ratchet index, \(i\), which is encoded as a
-big-endian 32-bit integer; the ratchet values \(R_{i,j}\); and the public
-part of the Ed25519 keypair \(K\).
-
-### Message format
-
-Megolm messages consist of a one byte version, followed by a variable length
-payload, a fixed length message authentication code, and a fixed length
-signature.
-
-```nohighlight
-+---+------------------------------------+-----------+------------------+
-| V | Payload Bytes                      | MAC Bytes | Signature Bytes  |
-+---+------------------------------------+-----------+------------------+
-0   1                                    N          N+8                N+72   bytes
-```
-
-The version byte, ``V``, is ``"\x03"``.
-
-The payload uses a format based on the [Protocol Buffers encoding][]. It
-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
-
-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
-byte with the high bit clear. The seven low bits of each byte store the bits of
-the integer. The least significant bits are stored in the first byte.
-
-Strings are encoded as a variable-length integer followed by the string itself.
-
-Each key-value pair is encoded as a variable-length integer giving the tag,
-followed by a string or variable-length integer giving the value.
-
-The payload is followed by the MAC. The length of the MAC is determined by the
-authenticated encryption algorithm being used (8 bytes in this version of the
-protocol). The MAC protects all of the bytes preceding the MAC.
-
-The length of the signature is determined by the signing algorithm being used
-(64 bytes in this version of the protocol). The signature covers all of the
-bytes preceding the signature.
-
-## Limitations
-
-### Message Replays
-
-A message can be decrypted successfully multiple times. This means that an
-attacker can re-send a copy of an old message, and the recipient will treat it
-as a new message.
-
-To mitigate this it is recommended that applications track the ratchet indices
-they have received and that they reject messages with a ratchet index that
-they have already decrypted.
-
-### Lack of Transcript Consistency
-
-In a group conversation, there is no guarantee that all recipients have
-received the same messages. For example, if Alice is in a conversation with Bob
-and Charlie, she could send different messages to Bob and Charlie, or could
-send some messages to Bob but not Charlie, or vice versa.
-
-Solving this is, in general, a hard problem, particularly in a protocol which
-does not guarantee in-order message delivery. For now it remains the subject of
-future research.
-
-### Lack of Backward Secrecy
-
-[Backward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)
-(also called 'future secrecy' or 'post-compromise security') is the property
-that if current private keys are compromised, an attacker cannot decrypt
-future messages in a given session.  In other words, when looking
-**backwards** in time at a compromise which has already happened, **current**
-messages are still secret.
-
-By itself, Megolm does not possess this property: once the key to a Megolm
-session is compromised, the attacker can decrypt any message that was
-encrypted using a key derived from the compromised or subsequent ratchet
-values.
-
-In order to mitigate this, the application should ensure that Megolm sessions
-are not used indefinitely. Instead it should periodically start a new session,
-with new keys shared over a secure channel.
-
-<!-- TODO: Can we recommend sensible lifetimes for Megolm sessions? Probably
-   depends how paranoid we're feeling, but some guidelines might be useful. -->
-
-### Partial Forward Secrecy
-
-[Forward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)
-(also called 'perfect forward secrecy') is the property that if the current
-private keys are compromised, an attacker cannot decrypt *past* messages in
-a given session. In other words, when looking **forwards** in time towards a
-potential future compromise, **current** messages will be secret.
-
-In Megolm, each recipient maintains a record of the ratchet value which allows
-them to decrypt any messages sent in the session after the corresponding point
-in the conversation. If this value is compromised, an attacker can similarly
-decrypt past messages which were encrypted by a key derived from the
-compromised or subsequent ratchet values. This gives 'partial' forward
-secrecy.
-
-To mitigate this issue, the application should offer the user the option to
-discard historical conversations, by winding forward any stored ratchet values,
-or discarding sessions altogether.
-
-### Dependency on secure channel for key exchange
-
-The design of the Megolm ratchet relies on the availability of a secure
-peer-to-peer channel for the exchange of session keys. Any vulnerabilities in
-the underlying channel are likely to be amplified when applied to Megolm
-session setup.
-
-For example, if the peer-to-peer channel is vulnerable to an unknown key-share
-attack, the entire Megolm session become similarly vulnerable. For example:
-Alice starts a group chat with Eve, and shares the session keys with Eve. Eve
-uses the unknown key-share attack to forward the session keys to Bob, who
-believes Alice is starting the session with him. Eve then forwards messages
-from the Megolm session to Bob, who again believes they are coming from
-Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob
-will realise that the key-sharing message was forwarded by Eve, and can treat
-the Megolm session as a forgery.
-
-A second example: if the peer-to-peer channel is vulnerable to a replay
-attack, this can be extended to entire Megolm sessions.
-
-## License
-
-The Megolm specification (this document) is licensed under the Apache License,
-Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.
-
-[Ed25519]: http://ed25519.cr.yp.to/
-[HMAC-based key derivation function]: https://tools.ietf.org/html/rfc5869
-[HKDF-SHA-256]: https://tools.ietf.org/html/rfc5869
-[HMAC-SHA-256]: https://tools.ietf.org/html/rfc2104
-[SHA-256]: https://tools.ietf.org/html/rfc6234
-[AES-256]: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
-[CBC]: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
-[PKCS#7]: https://tools.ietf.org/html/rfc2315
-[Olm]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md
-[Protocol Buffers encoding]: https://developers.google.com/protocol-buffers/docs/encoding

content/olm-megolm/olm.md

@@ -1,334 +0,0 @@
----
-title: "Olm: A Cryptographic Ratchet"
-weight: 10
-type: docs
----
-
-An implementation of the double cryptographic ratchet described by
-https://whispersystems.org/docs/specifications/doubleratchet/.
-
-## Notation
-
-This document uses \(\parallel\) to represent string concatenation. When
-\(\parallel\) appears on the right hand side of an \(=\) it means that
-the inputs are concatenated. When \(\parallel\) appears on the left hand
-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)\).
-
-Where this document uses \(\operatorname{HKDF}\left(salt,IKM,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\),
-and output keying material length of \(L\) bytes.
-
-## The Olm Algorithm
-
-### Initial setup
-
-The setup takes four [Curve25519][] inputs: Identity keys for Alice and Bob,
-\(I_A\) and \(I_B\), and one-time keys for Alice and Bob,
-\(E_A\) and \(E_B\). A shared secret, \(S\), is generated using
-[Triple Diffie-Hellman][]. The initial 256 bit root key, \(R_0\), and 256
-bit chain key, \(C_{0,0}\), are derived from the shared secret using an
-HMAC-based Key Derivation Function using [SHA-256][] as the hash function
-([HKDF-SHA-256][]) with default salt and ``"OLM_ROOT"`` as the info.
-
-\[
-\begin{aligned}
-    S&=\operatorname{ECDH}\left(I_A,E_B\right)\;\parallel\;
-       \operatorname{ECDH}\left(E_A,I_B\right)\;\parallel\;
-       \operatorname{ECDH}\left(E_A,E_B\right)\\
-    R_0\;\parallel\;C_{0,0}&=
-        \operatorname{HKDF}\left(0,S,\text{``OLM\_ROOT"},64\right)
-\end{aligned}
-\]
-
-### Advancing the root key
-
-Advancing a root key takes the previous root key, \(R_{i-1}\), and two
-Curve25519 inputs: the previous ratchet key, \(T_{i-1}\), and the current
-ratchet key \(T_i\). The even ratchet keys are generated by Alice.
-The odd ratchet keys are generated by Bob. A shared secret is generated
-using Diffie-Hellman on the ratchet keys. The next root key, \(R_i\), and
-chain key, \(C_{i,0}\), are derived from the shared secret using
-[HKDF-SHA-256][] using \(R_{i-1}\) as the salt and ``"OLM_RATCHET"`` as the
-info.
-
-\[
-\begin{aligned}
-    R_i\;\parallel\;C_{i,0}&=
-        \operatorname{HKDF}\left(
-            R_{i-1},
-            \operatorname{ECDH}\left(T_{i-1},T_i\right),
-            \text{``OLM\_RATCHET"},
-            64
-        \right)
-\end{aligned}
-\]
-
-### Advancing the chain key
-
-Advancing a chain key takes the previous chain key, \(C_{i,j-1}\). The next
-chain key, \(C_{i,j}\), is the [HMAC-SHA-256][] of ``"\x02"`` using the
-previous chain key as the key.
-
-\[
-\begin{aligned}
-    C_{i,j}&=\operatorname{HMAC}\left(C_{i,j-1},\text{``\char`\\x02"}\right)
-\end{aligned}
-\]
-
-### Creating a message key
-
-Creating a message key takes the current chain key, \(C_{i,j}\). The
-message key, \(M_{i,j}\), is the [HMAC-SHA-256][] of ``"\x01"`` using the
-current chain key as the key. The message keys where \(i\) is even are used
-by Alice to encrypt messages. The message keys where \(i\) is odd are used
-by Bob to encrypt messages.
-
-\[
-\begin{aligned}
-    M_{i,j}&=\operatorname{HMAC}\left(C_{i,j},\text{``\char`\\x01"}\right)
-\end{aligned}
-\]
-
-## The Olm Protocol
-
-### Creating an outbound session
-
-Bob publishes the public parts of his identity key, \(I_B\), and some
-single-use one-time keys \(E_B\).
-
-Alice downloads Bob's identity key, \(I_B\), and a one-time key,
-\(E_B\). She generates a new single-use key, \(E_A\), and computes a
-root key, \(R_0\), and a chain key \(C_{0,0}\). She also generates a
-new ratchet key \(T_0\).
-
-### Sending the first pre-key messages
-
-Alice computes a message key, \(M_{0,j}\), and a new chain key,
-\(C_{0,j+1}\), using the current chain key. She replaces the current chain
-key with the new one.
-
-Alice encrypts her plain-text with the message key, \(M_{0,j}\), using an
-authenticated encryption scheme (see below) to get a cipher-text,
-\(X_{0,j}\).
-
-She then sends the following to Bob:
- * The public part of her identity key, \(I_A\)
- * The public part of her single-use key, \(E_A\)
- * The public part of Bob's single-use key, \(E_B\)
- * The current chain index, \(j\)
- * The public part of her ratchet key, \(T_0\)
- * The cipher-text, \(X_{0,j}\)
-
-Alice will continue to send pre-key messages until she receives a message from
-Bob.
-
-### Creating an inbound session from a pre-key message
-
-Bob receives a pre-key message as above.
-
-Bob looks up the private part of his single-use key, \(E_B\). He can now
-compute the root key, \(R_0\), and the chain key, \(C_{0,0}\), from
-\(I_A\), \(E_A\), \(I_B\), and \(E_B\).
-
-Bob then advances the chain key \(j\) times, to compute the chain key used
-by the message, \(C_{0,j}\). He now creates the
-message key, \(M_{0,j}\), and attempts to decrypt the cipher-text,
-\(X_{0,j}\). If the cipher-text's authentication is correct then Bob can
-discard the private part of his single-use one-time key, \(E_B\).
-
-Bob stores Alice's initial ratchet key, \(T_0\), until he wants to
-send a message.
-
-### Sending normal messages
-
-Once a message has been received from the other side, a session is considered
-established, and a more compact form is used.
-
-To send a message, the user checks if they have a sender chain key,
-\(C_{i,j}\). Alice uses chain keys where \(i\) is even. Bob uses chain
-keys where \(i\) is odd. If the chain key doesn't exist then a new ratchet
-key \(T_i\) is generated and a new root key \(R_i\) and chain key
-\(C_{i,0}\) are computed using \(R_{i-1}\), \(T_{i-1}\) and
-\(T_i\).
-
-A message key,
-\(M_{i,j}\) is computed from the current chain key, \(C_{i,j}\), and
-the chain key is replaced with the next chain key, \(C_{i,j+1}\). The
-plain-text is encrypted with \(M_{i,j}\), using an authenticated encryption
-scheme (see below) to get a cipher-text, \(X_{i,j}\).
-
-The user then sends the following to the recipient:
- * The current chain index, \(j\)
- * The public part of the current ratchet key, \(T_i\)
- * The cipher-text, \(X_{i,j}\)
-
-### Receiving messages
-
-The user receives a message as above with the sender's current chain index, \(j\),
-the sender's ratchet key, \(T_i\), and the cipher-text, \(X_{i,j}\).
-
-The user checks if they have a receiver chain with the correct
-\(i\) by comparing the ratchet key, \(T_i\). If the chain doesn't exist
-then they compute a new root key, \(R_i\), and a new receiver chain, with
-chain key \(C_{i,0}\), using \(R_{i-1}\), \(T_{i-1}\) and
-\(T_i\).
-
-If the \(j\) of the message is less than
-the current chain index on the receiver then the message may only be decrypted
-if the receiver has stored a copy of the message key \(M_{i,j}\). Otherwise
-the receiver computes the chain key, \(C_{i,j}\). The receiver computes the
-message key, \(M_{i,j}\), from the chain key and attempts to decrypt the
-cipher-text, \(X_{i,j}\).
-
-If the decryption succeeds the receiver updates the chain key for \(T_i\)
-with \(C_{i,j+1}\) and stores the message keys that were skipped in the
-process so that they can decode out of order messages. If the receiver created
-a new receiver chain then they discard their current sender chain so that
-they will create a new chain when they next send a message.
-
-## The Olm Message Format
-
-Olm uses two types of messages. The underlying transport protocol must provide
-a means for recipients to distinguish between them.
-
-### Normal Messages
-
-Olm messages start with a one byte version followed by a variable length
-payload followed by a fixed length message authentication code.
-
-```nohighlight
- +--------------+------------------------------------+-----------+
- | Version Byte | Payload Bytes                      | MAC Bytes |
- +--------------+------------------------------------+-----------+
-```
-
-The version byte is ``"\x03"``.
-
-The payload consists of key-value pairs where the keys are integers and the
-values are integers and strings. The keys are encoded as a variable length
-integer tag where the 3 lowest bits indicates the type of the value:
-0 for integers, 2 for strings. If the value is an integer then the tag is
-followed by the value encoded as a variable length integer. If the value is
-a string then the tag is followed by the length of the string encoded as
-a variable length integer followed by the string itself.
-
-Olm uses a variable length encoding for integers. Each integer is encoded as a
-sequence of bytes with the high bit set followed by a byte with the high bit
-clear. The seven low bits of each byte store the bits of the integer. The least
-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
-
-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
-MAC protects all of the bytes preceding the MAC.
-
-### Pre-Key Messages
-
-Olm pre-key messages start with a one byte version followed by a variable
-length payload.
-
-```nohighlight
- +--------------+------------------------------------+
- | Version Byte | Payload Bytes                      |
- +--------------+------------------------------------+
-```
-
-The version byte is ``"\x03"``.
-
-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.
-Message|0x22|String|An embedded Olm message with its own version and MAC.
-
-## Olm Authenticated Encryption
-
-### Version 1
-
-Version 1 of Olm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding for
-encryption and [HMAC-SHA-256][] (truncated to 64 bits) for authentication.  The
-256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the
-message key using [HKDF-SHA-256][] using the default salt and an info of
-``"OLM_KEYS"``.
-
-\[
-\begin{aligned}
-    AES\_KEY_{i,j}\;\parallel\;HMAC\_KEY_{i,j}\;\parallel\;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}\).
-
-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.
-
-## Message authentication concerns
-
-To avoid unknown key-share attacks, the application must include identifying
-data for the sending and receiving user in the plain-text of (at least) the
-pre-key messages. Such data could be a user ID, a telephone number;
-alternatively it could be the public part of a keypair which the relevant user
-has proven ownership of.
-
-### Example attacks
-
-1. Alice publishes her public [Curve25519][] identity key, \(I_A\). Eve
-   publishes the same identity key, claiming it as her own. Bob downloads
-   Eve's keys, and associates \(I_A\) with Eve. Alice sends a message to
-   Bob; Eve intercepts it before forwarding it to Bob. Bob believes the
-   message came from Eve rather than Alice.
-
-   This is prevented if Alice includes her user ID in the plain-text of the
-   pre-key message, so that Bob can see that the message was sent by Alice
-   originally.
-
-2. Bob publishes his public [Curve25519][] identity key, \(I_B\). Eve
-   publishes the same identity key, claiming it as her own. Alice downloads
-   Eve's keys, and associates \(I_B\) with Eve. Alice sends a message to
-   Eve; Eve cannot decrypt it, but forwards it to Bob. Bob believes the
-   Alice sent the message to him, whereas Alice intended it to go to Eve.
-
-   This is prevented by Alice including the user ID of the intended recpient
-   (Eve) in the plain-text of the pre-key message. Bob can now tell that the
-   message was meant for Eve rather than him.
-
-## IPR
-
-The Olm specification (this document) is hereby placed in the public domain.
-
-## Feedback
-
-Can be sent to olm at matrix.org.
-
-## Acknowledgements
-
-The ratchet that Olm implements was designed by Trevor Perrin and Moxie
-Marlinspike - details at https://whispersystems.org/docs/specifications/doubleratchet/. Olm is
-an entirely new implementation written by the Matrix.org team.
-
-[Curve25519]: http://cr.yp.to/ecdh.html
-[Triple Diffie-Hellman]: https://whispersystems.org/blog/simplifying-otr-deniability/
-[HMAC-based key derivation function]: https://tools.ietf.org/html/rfc5869
-[HKDF-SHA-256]: https://tools.ietf.org/html/rfc5869
-[HMAC-SHA-256]: https://tools.ietf.org/html/rfc2104
-[SHA-256]: https://tools.ietf.org/html/rfc6234
-[AES-256]: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
-[CBC]: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
-[PKCS#7]: https://tools.ietf.org/html/rfc2315

content/proposals.md

@@ -1,6 +1,6 @@
 ---
 title: "Spec Change Proposals"
-weight: 62
+weight: 60
 type: docs
 ---
 
@@ -281,7 +281,7 @@ corresponding labels for each stage on the
 [matrix-spec-proposals](https://github.com/matrix-org/matrix-spec-proposals)
 pull request trackers.
 
-```nohighlight
+```
                            +                          +
          Proposals         |          Spec PRs        |  Additional States
          +-------+         |          +------+        |  +---------------+

content/push-gateway-api.md

@@ -14,7 +14,7 @@ A client's homeserver forwards information about received events to the
 push gateway. The gateway then submits a push notification to the push
 notification provider (e.g. APNS, GCM).
 
-```nohighlight
+```
                                    +--------------------+  +-------------------+
                   Matrix HTTP      |                    |  |                   |
              Notification Protocol |   App Developer    |  |   Device Vendor   |

content/rooms/v10.md

@@ -18,7 +18,7 @@ refined in [room version 9](/rooms/v9)).
 
 Clients should render the new join rule accordingly for such rooms. For example:
 
-```nohighlight
+```
 This room is:
 [ ] Public
 [x] Private

content/server-server-api.md

@@ -289,7 +289,7 @@ and any query parameters if present, but should not include the leading
 
 Step 1 sign JSON:
 
-```nohighlight
+```
 {
     "method": "POST",
     "uri": "/target",
@@ -822,7 +822,7 @@ ResidentServer->JoiningServer: send_join response
 JoiningServer->Client: join response
 -->
 
-```nohighlight
+```
 +---------+          +---------------+            +-----------------+ +-----------------+
 | Client  |          | JoiningServer |            | DirectoryServer | | ResidentServer  |
 +---------+          +---------------+            +-----------------+ +-----------------+

layouts/_markup/render-passthrough.html

@@ -1,19 +0,0 @@
-{{- /*
-
-    This is a passthrough render hook (https://gohugo.io/render-hooks/passthrough/).
-
-    We use it to send the delimited passthrough element through KaTeX to render maths
-    in the Olm / Megolm spec.
-
-    See: https://gohugo.io/functions/transform/tomath/#step-2
-
-*/ -}}
-{{- $opts := dict "output" "htmlAndMathml" "displayMode" (eq .Type "block") }}
-{{- with try (transform.ToMath .Inner $opts) }}
-  {{- with .Err }}
-    {{- errorf "Unable to render mathematical markup to HTML using the transform.ToMath function. The KaTeX display engine threw the following error: %s: see %s." . $.Position }}
-  {{- else }}
-    {{- .Value }}
-    {{- $.Page.Store.Set "hasMath" true }}
-  {{- end }}
-{{- end -}}

layouts/docs/baseof.html

@@ -12,10 +12,6 @@
     class="no-js">
   <head>
     {{ partial "head.html" . }}
-    {{ if .Page.Store.Get "hasMath" }}
-      <link href="{{ relURL "css/katex.min.css" }}" rel="preload" as="style">
-      <link href="{{ relURL "css/katex.min.css" }}" rel="stylesheet">
-    {{ end }}
   </head>
   <body class="td-{{ .Kind }}{{ with .Page.Params.body_class }} {{ . }}{{ end }}">
     <header>

scripts/download-katex-assets.sh

@@ -1,41 +0,0 @@
-#!/bin/bash
-#
-# Download the KaTeX fonts and CSS, and copy them into `static`.
-set -e
-
-root=$(dirname "$0")/..
-
-# Check that the caller supplied a version.
-version=$1
-if [[ -z $1 || $1 = "-h" || $1 = "--help" ]]; then
-    >&2 echo "Usage: download-katex-assets.sh VERSION (e.g. v0.16.23)"
-    >&2 echo
-    >&2 echo "Downloads KaTeX fonts and CSS from the specified release"
-    >&2 echo "on GitHub and puts the files into static/."
-    exit 1
-fi
-
-# Create a temporary directory and register a handler to clean it up on exit.
-tmp_dir=$(mktemp -d)
-clean_up () {
-    rm -rf "$tmp_dir"
-} 
-trap clean_up EXIT
-
-# Fetch the release archive.
-archive=$tmp_dir/katex.tar.gz
-url=https://github.com/KaTeX/KaTeX/releases/download/$version/katex.tar.gz
-echo "GET $url"
-curl -L --output "$archive" "$url"
-
-# Unpack the archive.
-tar -xzvf "$archive" -C "$tmp_dir"
-
-# Move the CSS file into place.
-install -vm644 "$tmp_dir/katex/katex.min.css" "$root/static/css/katex.min.css"
-
-# Remove any existing fonts and move the new ones into place.
-rm -rvf "$root"/static/css/fonts/KaTeX*
-while IFS= read -r -d '' file; do
-    install -vm644 "$file" "$root/static/css/fonts"
-done < <(find "$tmp_dir/katex/fonts" -maxdepth 1 -name "KaTeX*.woff2" -print0)