mirror of
https://github.com/simplex-chat/simplexmq.git
synced 2026-07-17 16:31:52 +00:00
Rename edge-messaging to simplex messaging (#15)
* rename edge-messaging protocol related files * rename edge-messaging protocol to simplex messaging protocol * adjust wordings for simplex connections
This commit is contained in:
Efim Poberezkin
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
@@ -1,315 +0,0 @@
|
||||
# Edge-messagng protocol implementation
|
||||
|
||||
This document defines specific elements to be used by client and server implementations of edge-messaging protocol. This protocol relies on the connection creation and messaging flows defined in generic [edge-messaging protocol][1].
|
||||
|
||||
This document defines:
|
||||
- [cryptographic algorithms](#cryptographic-algorithms) to sign/verify requests and to encrypt/decrypt messages.
|
||||
- required approaches to generate:
|
||||
- [connection IDs](#connection-id) for clients.
|
||||
- [connection URIs](#connection-uris) for servers.
|
||||
- [privacy requirements](#privacy-requirements) to the servers.
|
||||
- [REST API](#rest-api):
|
||||
- to create connections and to update connection attributes.
|
||||
- to send and to retrieve messages.
|
||||
- [WebSockets API](#websockets-api) to subscribe to connections:
|
||||
- to receive the new messages.
|
||||
- to update connection attributes.
|
||||
- any other requirements for edge-messaging servers
|
||||
|
||||
|
||||
## Cryptographic algorithms
|
||||
|
||||
Edge-messaging clients need to cryptographically sign requests:
|
||||
- with the recipient's key `RK` (server to verify):
|
||||
- to create connections.
|
||||
- to subscribe to connection.
|
||||
- to change connection attributes.
|
||||
- to delete the connection.
|
||||
- to retrieve messages from the connection
|
||||
- with the sender's key `SK`:
|
||||
- to send the initial request including public key `SK` (connection recipient to verify).
|
||||
- to send messages (server to verify).
|
||||
|
||||
To sign and verify requests, clients and servers MUST use RSA-PSS algorythm defined in [RFC3447][2].
|
||||
|
||||
To optinally sign and verify messages, clients SHOULD use RSA-PSS algorythm.
|
||||
|
||||
To encrypt and decrypt messages, clients SHOULD use RSA-OAEP algorythm defined in [RFC3447][2].
|
||||
|
||||
The reasons to support these algorithms:
|
||||
- they are supported by WebCrypto API.
|
||||
- they are newer versions than RSA-PKCS1-v1_5 encryption and signature schemes.
|
||||
- they are more widely supported than ECC algorithms
|
||||
|
||||
Future versions of the protocol may allow different algorithms.
|
||||
|
||||
|
||||
## Connection ID
|
||||
|
||||
Edge-messaging clients MUST generate random unique ID for each new unidirectional connection.
|
||||
|
||||
It is not required that this ID is globally unique across all clients and servers, and this ID is known only to the server on which connection is created and to the connection recipient.
|
||||
|
||||
Clients MUST use cryptographically strong pseudo-random number generator to generate 64(?)-bit connection IDs.
|
||||
|
||||
All requests (other than Create connection) require that `connectionID` property is passed to the server in the request body. This connection ID MUST match the client-generated `connectionID` earlier passed in the request to create the connection.
|
||||
|
||||
If connection IDs do not match, the server MUST reject the request with HTTP status code 404 (Not Found).
|
||||
|
||||
|
||||
## Connection URIs
|
||||
|
||||
Edge-messaging servers MUST generate 2 different URIs for each new connection - for recipient (that created the connection) and for sender. It is REQUIRED that:
|
||||
- these URIs are different.
|
||||
- they do not contain client-generated connection ID, any keys, or key hashes.
|
||||
- based on 64(?)-bit number generated with cryptographically strong pseudo-random number generator.
|
||||
|
||||
Coonection URIs can be:
|
||||
- server domain, path used to create connection and random string (e.g. `https://example.com/connection/aZ...9f), e.g. base-64 encoded random number.
|
||||
- any unique URI that server recognises.
|
||||
|
||||
|
||||
## Privacy requirements
|
||||
|
||||
Edge-messaging server implementations MUST NOT:
|
||||
- create any logs of the client requests in the production environment.
|
||||
- create any history of deleted connections or retrieved (and removed) messages.
|
||||
- create any history of connection updates and store old keys or URIs.
|
||||
- create any snapshots of the database they use to store connections and messages (instead edge-messaging clients must manage redundancy by using more than one edge-messaging server, e.g., as described in [graph-chat protocol][3]).
|
||||
- create/store any other information that may undermine privacy or [forward secrecy][4] of communication between clients using edge-messaging server.
|
||||
|
||||
|
||||
## REST API
|
||||
|
||||
### General API considerations
|
||||
|
||||
Edge-messaging server MUST provide REST API via HTTPS protocol. It MAY operate on the same domain as any other web application. It is RECOMMENDED that the endpoint to create connections and all connection URIs start from the same path, to avoid namespace conflicts with other applications.
|
||||
|
||||
In case of any requests sent to unknown URIs, server MUST reject the request with HTTP status code 404 (Not Found).
|
||||
|
||||
In case of any requests sent with missing required properties, incorrect property type/value or any additional unknown property (or sub-property), server MUST reject the request with HTTP status code 400 (Bad Request).
|
||||
|
||||
Below examples of API endpoints use:
|
||||
- server `https://example.com`
|
||||
- path `/connection`
|
||||
|
||||
|
||||
### Request headers
|
||||
|
||||
All server requests MUST use JSON object as request body and MUST use HTTP header `Content-Type: application/json`.
|
||||
|
||||
... client protocol version
|
||||
|
||||
TODO
|
||||
|
||||
|
||||
### Request authorisation
|
||||
|
||||
All server requests MUST be signed with the relevant key and the digital signature MUST be passed in HTTP header `Authorization`.
|
||||
|
||||
In case of signature verification failure, server MUST reject the request with HTTP status code 401 (Unauthorised).
|
||||
|
||||
TODO Authorisation header format
|
||||
|
||||
|
||||
### Response headers
|
||||
|
||||
... server protocol version
|
||||
|
||||
... server timestamp
|
||||
|
||||
TODO
|
||||
|
||||
|
||||
### REST API endpoints
|
||||
|
||||
Edge-messaging server MUST provide the API endpoints for the recipient and for the sender. The list of endpoints below has URI examples, the actual API URI schemes can differ between implementations, and even from deployment to deployment, based on server configuration.
|
||||
|
||||
URI scheme provides an additional layer of security to access the connection for both the sender and the recipient, and allows, if required, to implement and deploy private and commercial edge-messaging servers.
|
||||
|
||||
`messages` path segment in all endpoints to retrieve, delete and send messages is REQUIRED and MUST NOT be changed by any implementation or deployment.
|
||||
|
||||
Endpoints for the recipient:
|
||||
- [Create connection](#create-connection): POST `create URI` (e.g. `https://example.com/connection`)
|
||||
- [Update connection](#update-connection): PUT `<RU>` (e.g. `https://example.com/connection/aZ9f`)
|
||||
- [Delete connection](#delete-connection): DELETE `<RU>` (e.g. `https://example.com/connection/aZ9f`)
|
||||
- [Retrieve messages](#retrieve-messages): POST `<RU>/messages` (e.g. `https://example.com/connection/aZ9f/messages`)
|
||||
- [Delete messages](#delete-messages): DELETE `<RU>/messages` (e.g. `https://example.com/connection/aZ9f/messages`)
|
||||
|
||||
Endpoints for the sender:
|
||||
- [Update connection](#update-connection): PUT `<SU>` (e.g. `https://example.com/connection/bY1h`)
|
||||
- [Send messages](#send-messages): POST `<SU>/messages` (e.g. `https://example.com/connection/bY1h/messages`)
|
||||
|
||||
__Please note__: the server MUST NOT allow the sender to delete of modify the messages after they are sent.
|
||||
|
||||
|
||||
### REST API endpoints for the connection recipients
|
||||
|
||||
#### Create connection
|
||||
|
||||
URI: as defined by server configuration, can be different per server user.
|
||||
|
||||
Example: POST `https://example.com/connection`
|
||||
|
||||
Server MUST define a single endpoint to create connections. This endpoint can be:
|
||||
- server domain without any path, if the domain is not shared with other web application.
|
||||
- server domain and path used for all connection URIs.
|
||||
- server domain, path and secure token(s) (possibly user-specific), if the server owner wants to restrict access to creating connections (for private or commercial servers).
|
||||
- any other, potentially undiscoverable, URI that server recognises.
|
||||
|
||||
To create a connection, edge-messaging client MUST send POST request to this endpoint, signed with the key `RK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `connectionID` (string): new client-generated connection ID.
|
||||
- `recipient` (string): public key `RK` to verify digital signature of the recipient.
|
||||
- `sender` (string, optional): public key `SK` to verify digital signature of the sender (it can be used in the alternative flow of establishing the connection when recipient and sender exchanged two secure out-of-band messages with each other, to reduce the number of connection steps - see [edge-messaging protocol][1]).
|
||||
- `disabled` (boolean, optional): if `true`, the connection will be created but it will not be possible for the sender to use it to send messages. It will still be possible to retrieve the available messages and to modify the connection.
|
||||
|
||||
Servers MUST require that connection ID is unique, and in the unlikely case of ID collision reject the connection creation request with HTTP status code 409 (Conflict).
|
||||
|
||||
If the connection creation succeeded, the server MUST respond with HTTP status code 201 (Created) and the response body MUST be a JSON object with the following properties:
|
||||
- `recipientURI` (string): recipient URI `RU` of the connection that MUST be used as the endpoint for requests to retrieve the messages, to update connection attributes and to delete the connection. Clients MUST NOT share this URI with the sender.
|
||||
- `senderURI` (string): sender URI `SU` of the connection that MUST be used as the endpoint for requests to send the messages.
|
||||
|
||||
|
||||
#### Update connection
|
||||
|
||||
URI: recipient connection URI `<RU>`
|
||||
|
||||
Example: PUT `https://example.com/connection/aZ9f`
|
||||
|
||||
To update the connection, edge-messaging client MUST send PUT request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
|
||||
- `recipient` (string, optional): public key `RK` to verify digital signature of the recipient, if the recipient wants to change the key (TBC - the request should be signed with both current and new key).
|
||||
- `sender` (string, optional/required): public key `SK` to verify digital signature of the sender. Unless this key was set when connection was created, this key is required on the first connection update request.
|
||||
- `disabled` (boolean, optional): if `true`, the connection will be "disabled" and it will not be possible for the sender to use it to send messages. It will still be possible to retrieve the available messages and for both sides to modify the connection. This parameter can be used to allow the back-pressure to the message sender (e.g. if the recipient is overloaded with message processing and cannot accept any new messages).
|
||||
|
||||
|
||||
Server MUST permanently update required connection keys and URIs without preserving any copy.
|
||||
|
||||
If the connection update succeeded, the server MUST respond with HTTP status code 200 (OK) without body.
|
||||
|
||||
If any of the connection keys have changed, all the following requests signed with the old keys MUST be rejected with HTTP status code 401 (Unauthorised).
|
||||
|
||||
|
||||
#### Delete connection
|
||||
|
||||
URI: recipient connection URI `<RU>`
|
||||
|
||||
Example: DELETE `https://example.com/connection/aZ9f`
|
||||
|
||||
To delete the connection, edge-messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection), signed with the key `RK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
|
||||
|
||||
If the connection deletion succeeded, the server MUST respond with HTTP status code 200 (OK) without body.
|
||||
|
||||
Server MUST permanently delete the connection and all unretrieved messages without preserving any copy of the connection or messages.
|
||||
|
||||
All further requests to the recipient and sender connection URIs MUST be rejected with HTTP status code 404 (Not Found).
|
||||
|
||||
|
||||
#### Retrieve messages
|
||||
|
||||
URI: `<RU>/messages`
|
||||
|
||||
Example: POST `https://example.com/connection/aZ9f/messages`
|
||||
|
||||
To retrieve messages from the connection, edge-messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
|
||||
- `pageSize` (number, optional): if set, the server will return the number of messages, from the earliest available, up to the maximum of this parameter and `PAGE_SIZE` configured in the server. If not set the server will return up to `PAGE_SIZE` available messages.
|
||||
- `fromMessageID` (string, optional): if set, the server will retrieve the messages received starting from the message with server message ID (unique per server) passed in this parameter. This ID of the next available message is passed in the response to this request (if more messages are available).
|
||||
- `keepMessages` (boolean, optional): if `true`, the server will keep the retrieved messages available in the connection to be retrieved again (or deleted via a separate request). By default the retrieved messages will be removed from the server. Clients may need to process messages in some way, and until the processing succeded clients may choose to keep messages on the server to ensure they are not lost if processing fails for any reason.
|
||||
|
||||
Edge-messaging server MUST permanently remove the retrieved messages, unless specifically instructed by the clients to keep them.
|
||||
|
||||
__Please note__: server implementations MUST NOT track in any form how many times or whether the messages were retrieved.
|
||||
|
||||
If the unknown message ID is passed in `afterMessageID` parameter, the request should be rejected with HTTP status code 400 (Bad Request).
|
||||
|
||||
If the request is successful, the server MUST respond with HTTP status code (200) returning as response body the required number (but not more than `PAGE_SIZE` configured in the server) of the earliest sent messages with the following properties:
|
||||
- `messages` (array): retrieved messages. Each retrieved message is an object with the following properties:
|
||||
- `id`: server-generated unique ID allowing to identify messages until (they are deleted from the server) and to paginate responses.
|
||||
- `ts`: server timestamp of the time when the message was received from the sender.
|
||||
- `msg`: encrypted message body, that the recipient should be able to decrypt with the key `EK`.
|
||||
- `nextMessageID` (string, optional): if server has more messages available it MUST return this parameter that can be used by the next request in `fromMessageID` property.
|
||||
|
||||
|
||||
#### Delete messages
|
||||
|
||||
URI: `<RU>/messages`
|
||||
|
||||
Example: DELETE `https://example.com/connection/aZ9f/messages`
|
||||
|
||||
To delete messages from the connection, edge-messaging client MUST send DELETE request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `RK`.
|
||||
|
||||
This request SHOULD be used by edge-messaging clients to delete the previously retrived messages when `"keepMessages": true` parameter was used or in case they no longer require to retrive the messages.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `connectionID` (string): existing connection ID (see [Connection ID](#connection-id)).
|
||||
- `pageSize` (number, optional): if set, the server will delete up to the requested number of messages, otherwise all messages, in both cases from the message ID in `fromMessageID` parameter (or from the earliest available).
|
||||
- `fromMessageID` (string, optional): the server will delete the messages received, starting from the message with the server message ID passed in this parameter. If not specified, it defaults to the server message ID of the earliest received message.
|
||||
|
||||
Edge-messaging server MUST permanently remove the messages as requested.
|
||||
|
||||
If the request is successful, the server MUST respond with HTTP status code (200) with the body that has the count of deleted messages in `deleted` property.
|
||||
|
||||
If the unknown message ID is passed in `fromMessageID` parameter, the request should be rejected with HTTP status code 400 (Bad Request).
|
||||
|
||||
|
||||
### REST API endpoints for the connection sender
|
||||
|
||||
#### Update connection
|
||||
|
||||
URI: sender connection URI `<SU>`
|
||||
|
||||
Example: PUT `https://example.com/connection/bY1h`
|
||||
|
||||
To update the connection, edge-messaging client of the sender MUST send PUT request to the sender connection URI `SU` (returned by the server to the connection recipient when creating the connection), signed with the key `SK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `sender` (string, optional): the new public key `SK` to verify digital signature of the sender. This parameter is only allowed if the sender key `SK` is already available on the connection, otherwise the server MUST reject the request with HTTP status code 401 (Unauthorised).
|
||||
- `recipient`, `disabled`: these parameters are prohibited, and if any of them is present the server MUST reject the request with HTTP status code 401 (Unauthorised).
|
||||
|
||||
Server MUST permanently update required connection keys and URIs without preserving any copy.
|
||||
|
||||
If the connection update succeeded, the server MUST respond with HTTP status code 200 (OK) with emty body.
|
||||
|
||||
If the connection key `SK` has changed, all the following requests signed with the old key MUST be rejected with HTTP status code 401 (Unauthorised).
|
||||
|
||||
|
||||
#### Send messages
|
||||
|
||||
URI: `<SU>/messages`
|
||||
|
||||
Example: POST `https://example.com/connection/bY1h/messages`
|
||||
|
||||
To send messages to the connection, edge-messaging client MUST send POST request to the recipient connection URI `RU` (returned by the server when creating the connection) with the REQUIRED appended string `/messages` (it MUST NOT be changed by any implementation or deployment), signed with the key `SK`.
|
||||
|
||||
Request body should be sent as JSON object with the following properties:
|
||||
- `messages` (array): retrieved messages. Each sent message is an object with the following properties:
|
||||
- `msg`: encrypted message body, that the recipient should be able to decrypt with the key `EK`. Any message meta-data (client timestamp, ID, etc.) MUST be inside the encrypted message and MUST NOT passed via additional properties.
|
||||
|
||||
If the request is successful, the server MUST respond with HTTP status code 200 (OK) without body.
|
||||
|
||||
|
||||
## WebSockets API
|
||||
|
||||
TODO
|
||||
|
||||
**Simplex connection operation:**
|
||||
|
||||
|
||||
|
||||
Sequence diagram does not show E2EE - connection itself knows nothing about encryption between sender and receiver.
|
||||
|
||||
|
||||
[1]: edge-messaging.md
|
||||
[2]: https://tools.ietf.org/html/rfc3447
|
||||
[3]: graph-chat.md
|
||||
[4]: https://en.wikipedia.org/wiki/Forward_secrecy
|
||||
@@ -1,4 +1,4 @@
|
||||
# Edge-messaging protocol
|
||||
# Simplex messaging protocol
|
||||
|
||||
A generic client-server protocol for asynchronous distributed unidirectional messaging
|
||||
|
||||
@@ -15,20 +15,20 @@ A generic client-server protocol for asynchronous distributed unidirectional mes
|
||||
- [MITM attack][1]. Any mechanism of the key exchange via the same network is prone to this type of attack when the public keys of the participants are substituted with the public keys of the attacker intercepting communication. While some solutions have been proposed that complicate MITM attack (social millionaire, OTR), if the attacker understands the protocol and has intercepted and can substitute all information exchanged between the participants, it is still possible to substitute encryption keys. It means that the existing [E2EE][2] implementations in messaging protocols and platforms can be compromised by the attacked who either compromised the server or communication channel.
|
||||
|
||||
|
||||
## Edge-messaging protocol abstract
|
||||
## Simplex messaging protocol abstract
|
||||
|
||||
The proposed "edge-messaging protocol" removes the need for participants' identities and provides [E2EE][2] without the possibility of [MITM attack][1] attack under one assumption: participants have an existing alternative communication channel that they trust and can use to pass one small binary message to initiate the connection (out-of-band message).
|
||||
The proposed "simplex messaging protocol" removes the need for participants' identities and provides [E2EE][2] without the possibility of [MITM attack][1] attack under one assumption: participants have an existing alternative communication channel that they trust and can use to pass one small binary message to initiate the connection (out-of-band message).
|
||||
|
||||
The out-of band message is sent via some trusted alternative channel by the connection recipient to the connection sender. This message is used to share the encryption (a.k.a. "public") key and connection URI requried to establish a unidirectional connection:
|
||||
The out-of band message is sent via some trusted alternative channel by the connection recipient to the connection sender. This message is used to share the encryption (a.k.a. "public") key and connection URI requried to establish a unidirectional (simplex) connection:
|
||||
- the sender of the connection (who received out-of-band message) will use it to send messages to the server using connection URI, signing the message by sender key.
|
||||
- the recepient of the connection (who created the connection and who sent out-of-band message) will use it to retrieve messages from the server, signing the requests by the recepient key.
|
||||
- participant identities are not shared with the server, as completely new keys and connection URI are used for each connection.
|
||||
|
||||
This unidirectional connection ("graph edge") is the main building block of the network that is used to build application level primitives (in graph-chat protocol) that are only known to system participants in their client applications (graph vertices) - user profiles, contacts, conversations, groups and broadcasts. At the same time, system servers are only aware of the low-level unidirectional connections (graph edges). In this way a high level of privacy and security of the conversations is provided. Application level chat primitives defined in graph-chat protocol are not in scope of this edge-messaging protocol.
|
||||
This simplex connection is the main building block of the network that is used to build application level primitives (in graph-chat protocol) that are only known to system participants in their client applications (graph vertices) - user profiles, contacts, conversations, groups and broadcasts. At the same time, system servers are only aware of the low-level simplex connections. In this way a high level of privacy and security of the conversations is provided. Application level chat primitives defined in graph-chat protocol are not in scope of this simplex messaging protocol.
|
||||
|
||||
This approach is based on the concepts of [unidirectional networks][4] that are used for applications with high level of information security.
|
||||
|
||||
Defining the approach to out-of-band message passing is out of scope of this edge-messaging protocol. For practical purposes, and from the graph-chat client application point of view, various solutions can be used, e.g. one of the versions or the analogues of [QR code][3] (or their sequence) that is read via the camera, either directly from the chat participant's device or via the video call. Although a video call still allows for a highly sophisticated MITM attack, it requires that in addition to compromising edge-messaging connection to intercept messages, the attacker also identifies and compromises the video connection in another channel and substitutes the video in real time - it seems extremely unlikely.
|
||||
Defining the approach to out-of-band message passing is out of scope of this simplex messaging protocol. For practical purposes, and from the graph-chat client application point of view, various solutions can be used, e.g. one of the versions or the analogues of [QR code][3] (or their sequence) that is read via the camera, either directly from the chat participant's device or via the video call. Although a video call still allows for a highly sophisticated MITM attack, it requires that in addition to compromising simplex connection to intercept messages, the attacker also identifies and compromises the video connection in another channel and substitutes the video in real time - it seems extremely unlikely.
|
||||
|
||||
|
||||
## Simplex connection - the main unit of protocol design
|
||||
@@ -37,35 +37,35 @@ The network consists of multiple "simplex connections" (i.e. unidirectional, non
|
||||
|
||||
The messages sent into the connection are encrypted and decrypted using another key pair - the recepient has the private key and the sender has the associated public key.
|
||||
|
||||
**Unidirectional connection diagram:**
|
||||
**Simplex connection diagram:**
|
||||
|
||||
|
||||
|
||||
|
||||
Connection is defined by ID (`ID`) unique to the server, sender URI `SU` and receiver URI `RU`. Sender key (`SK`) is used by the server to verify sender's requests (made via `SU`) to send messages. Recipient key (`RK`) is used by the server to verify recipient's requests (made via `RU`) to retrieve messages.
|
||||
|
||||
The protocol uses different URIs for sender and recipient in order to provide an additional connection privacy by complicating correlation of senders and recipients.
|
||||
|
||||
|
||||
## How Alice and Bob use edge-messaging protocol
|
||||
## How Alice and Bob use simplex messaging protocol
|
||||
|
||||
Alice (recipient) wants to receive the messages from Bob (sender).
|
||||
|
||||
To do it Alice and Bob follow these steps:
|
||||
|
||||
1. Alice creates the unidirectional connection on the server:
|
||||
1. she decides which edge-messaging server to use (can be the same or different server that Alice uses for other connections).
|
||||
1. Alice creates a simplex connection on the server:
|
||||
1. she decides which simplex messaging server to use (can be the same or different server that Alice uses for other connections).
|
||||
2. she generates a new random public/private key pair (encryption key - `EK`) that she did not use before for Bob to encrypt the messages.
|
||||
3. she generates another new random public/private key pair (recepient key - `RK`) that she did not use before for her to sign requests to retrieve the messages from the server.
|
||||
4. she generates a unique connection `ID` - generic edge-messaging protocol only requires that:
|
||||
4. she generates a unique connection `ID` - generic simplex messaging protocol only requires that:
|
||||
- it is generated by the client.
|
||||
- it is unique on the server.
|
||||
5. she requests from the server to create a unidirectional connection. The request to create the connection is un-authenticated and anonymous. This connection definition contains previouisly generated connection `ID` and a uniqie "public" key `RK` that will be used to:
|
||||
5. she requests from the server to create a simplex connection. The request to create the connection is un-authenticated and anonymous. This connection definition contains previouisly generated connection `ID` and a uniqie "public" key `RK` that will be used to:
|
||||
- verify the requests to retrieve the messages as signed by the same person who created the connection.
|
||||
- update the connection, e.g. by setting the key required to send the messages (initially Alice creates the connection that accepts unsigned requests to send messages, so anybody could send the message via this connection if they knew the connection URI).
|
||||
6. The server responds with connection URIs:
|
||||
- recipient URI `RU` for Alice to retrieve messages from the connection.
|
||||
- sender URI `SU` for Bob to send messages to the connection.
|
||||
2. Alice sends an out-of-band message to Bob via the alternative channel that both Alice and Bob trust (see [Edge-messaging protocol abstract](#edge-messaging-protocol-abstract) above). The message includes:
|
||||
2. Alice sends an out-of-band message to Bob via the alternative channel that both Alice and Bob trust (see [Simplex messaging protocol abstract](#simplex-messaging-protocol-abstract) above). The message includes:
|
||||
- the unique "public" key (`EK`) that Bob should use to encrypt messages.
|
||||
- the sender connection URI `SU` for Bob to use.
|
||||
3. Bob, having received the out-of-band message from Alice, accepts the connection:
|
||||
@@ -82,17 +82,17 @@ To do it Alice and Bob follow these steps:
|
||||
5. Alice secures the connection `ID` so only Bob can send messages to it:
|
||||
1. she sends the request to `RU` signed with "private" key `RK` to update the connection to only accept requests signed by "private" key `SK` provided by Bob.
|
||||
2. From this moment the server will accept only signed requests, and only Bob will be able to send messages to the `SU` corresponding to connection `ID`.
|
||||
6. The unidirectional connection `ID` is now established on the server.
|
||||
6. The simplex connection `ID` is now established on the server.
|
||||
|
||||
**Creating unidirectional connection from Bob to Alice:**
|
||||
**Creating simplex connection from Bob to Alice:**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Bob now can securely send messages to Alice.
|
||||
|
||||
1. Bob sends the message:
|
||||
1. he encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Alice and Bob, used only for one unidirectional connection).
|
||||
1. he encrypts the message to Alice with "public" key `EK` (provided by Alice, only known to Alice and Bob, used only for one simplex connection).
|
||||
2. he signs the request to the server (via `SU`) using the "private" key `SK` (that only he knows, used only for this connection).
|
||||
3. he sends the request to the server, that the server will verify using the "public" key SK (that Alice provided to the server).
|
||||
2. Alice retrieves the message(s):
|
||||
@@ -100,49 +100,49 @@ Bob now can securely send messages to Alice.
|
||||
2. the server, having verified Alice's request with the "public" key `RK` that she provided, responds with Bob's message(s).
|
||||
3. she decrypts Bob's message(s) with the "private" key `EK` (that only she has).
|
||||
|
||||
**Sending messages from Bob to Alice via unidirectional connection:**
|
||||
**Sending messages from Bob to Alice via simplex connection:**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
A higher level protocol (e.g., [graph-chat][7]) defines the semantics that allow to use two unidirectional connections (or two sets of connections for redundancy) for the bi-directional messaging chat and for any other communication scenarios.
|
||||
A higher level protocol (e.g., [graph-chat][7]) defines the semantics that allow to use two simplex connections (or two sets of connections for redundancy) for the bi-directional messaging chat and for any other communication scenarios.
|
||||
|
||||
The edge-messaging protocol is intentionally unidirectional - it provides no answer to how Bob will know that the process succeeded, and whether Alice received any messages. There may be a situation when Alice wants to securely receive the messages from Bob, but she does not want Bob to have any proof that she received any messages - this low-level edge-messaging protocol can be used in this scenario, as all Bob knows as a fact is that he was able to send one unsigned message to the server that Alice provided, and now can only send messages signed with the key `SK` that he sent to the server - it does not prove that any message was received by Alice.
|
||||
The simplex messaging protocol is intentionally sipmlex - it provides no answer to how Bob will know that the process succeeded, and whether Alice received any messages. There may be a situation when Alice wants to securely receive the messages from Bob, but she does not want Bob to have any proof that she received any messages - this low-level simplex messaging protocol can be used in this scenario, as all Bob knows as a fact is that he was able to send one unsigned message to the server that Alice provided, and now can only send messages signed with the key `SK` that he sent to the server - it does not prove that any message was received by Alice.
|
||||
|
||||
For practical purposes of bi-directional conversation, now that Bob can securely send encrypted messages to Alice, Bob can establish the second unidirectional connection that will allow Alice to send messages to Bob in the same way. If both Alice and Bob have their respective uniqie "public" keys (Alice's and Bob's `EK`s of two separate connections), the conversation can be both encrypted and signed.
|
||||
For practical purposes of bi-directional conversation, now that Bob can securely send encrypted messages to Alice, Bob can establish the second simplex connection that will allow Alice to send messages to Bob in the same way. If both Alice and Bob have their respective uniqie "public" keys (Alice's and Bob's `EK`s of two separate connections), the conversation can be both encrypted and signed.
|
||||
|
||||
The established connection can also be used to change the encryption keys providing [forward secrecy][5].
|
||||
|
||||
This protocol also can be used for off-the-record messaging, as Alice and Bob can have multiple connections established between them and only information they pass to each other allows proving their identity, so if they want to share anything off-the-record they can initiate a new connection without linking it to any other information they exchanged. As a result, this protocol provides better anonymity and better protection from [MITM][1] than [OTR][6] protocol.
|
||||
|
||||
How unidirectional connections (graph edges) are used by the participants (graph vertices) is defined by graph-chat protocol and is not in scope of this low level edge-messaging protocol.
|
||||
How simplex connections are used by the participants (graph vertices) is defined by graph-chat protocol and is not in scope of this low level simplex messaging protocol.
|
||||
|
||||
|
||||
## Alternative flow to establish unidirectional connection
|
||||
## Alternative flow to establish a simplex connection
|
||||
|
||||
When Alice and Bob already have a secure duplex (bi-directional) communication channel that allows to conveniently send two out-of-band messages, a flow with smaller number of steps to establish the connection can be used.
|
||||
|
||||
TODO
|
||||
|
||||
**Alternative flow of creating unidirectional connection from Bob to Alice:**
|
||||
**Alternative flow of creating a simplex connection from Bob to Alice:**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Elements of the generic edge-messaging protocol
|
||||
## Elements of the generic simplex messaging protocol
|
||||
|
||||
- defines only message-passing protocol:
|
||||
- transport agnostic - the protocol does not define how clients connect to the servers and does not require persistent connections. While a generic term "request" is used, it can be implemented in various ways - HTTP requests, messages over (web)sockets, etc. This is defined by edge-messaging server protocol.
|
||||
- not semantic - the protocol does not assign any meaning to connections and messages. While on the application level the connections and messages can have different meaning (e.g., for messages: text or image chat message, message acknowledgement, participant profile information, status updates, changing "public" key to encrypt messages, changing servers, etc.), on the edge-messaging protocol level all the messages are binary and their meaning can only be interpreted by client applications and not by the servers - this interpretation is in scope of graph-chat protocol and out of scope of this edge-messaging protocol.
|
||||
- transport agnostic - the protocol does not define how clients connect to the servers and does not require persistent connections. While a generic term "request" is used, it can be implemented in various ways - HTTP requests, messages over (web)sockets, etc. This is defined by simplex messaging server protocol.
|
||||
- not semantic - the protocol does not assign any meaning to connections and messages. While on the application level the connections and messages can have different meaning (e.g., for messages: text or image chat message, message acknowledgement, participant profile information, status updates, changing "public" key to encrypt messages, changing servers, etc.), on the simplex messaging protocol level all the messages are binary and their meaning can only be interpreted by client applications and not by the servers - this interpretation is in scope of graph-chat protocol and out of scope of this simplex messaging protocol.
|
||||
- client-server architecture:
|
||||
- multiple servers, that can be deployed by the system users, can be used to send and retrieve messages.
|
||||
- servers do not communicate with each other and do not even "know" about other servers.
|
||||
- clients only communicate with servers (excluding the initial out-of-band message), so the message passing is asynchronous.
|
||||
- for each connection, the message recipient defines the server through which the sender should send messages.
|
||||
- while multiple servers and multiple connections can be used to pass each chat message, it is in scope of graph-chat protocol, and out of scope of this edge-messaging protocol.
|
||||
- while multiple servers and multiple connections can be used to pass each chat message, it is in scope of graph-chat protocol, and out of scope of this simplex messaging protocol.
|
||||
- servers store messages only until they are retrieved by the recipients
|
||||
- servers are not supposed to store any message history or delivery log, but even if the server is compromised, it does not allow to decrypt the messages or to determine the list of connections established by any participant - this information is only stored on client devices.
|
||||
- the only element provided by edge-messaging servers is unidirectional connections (graph edges):
|
||||
- the only element provided by simplex messaging servers is simplex connections:
|
||||
- each connection is created and managed by the connection recipient.
|
||||
- assymetric encryption is used to sign and verify the requests to send and receive the messages.
|
||||
- one unique "public" key is used for the servers to authenticate requests to send the messages into the connection, and another unique "public" key - to retrieve the messages from the connection. "Unique" here means that each "public" key is used only for one connection and is not used for any other context - effectively this key is not public and does not represent any participant identity.
|
||||
Reference in New Issue
Block a user