From d6d23bcac9b059e875766798171d3364e480530b Mon Sep 17 00:00:00 2001
From: Evgeny Poberezkin <2769109+epoberezkin@users.noreply.github.com>
Date: Thu, 22 Oct 2020 11:29:48 +0100
Subject: [PATCH] update protocol to use term "queue" to mean "SMP connection",
CONN -> NEW
---
.../simplex-messaging/simplex-creating.mmd | 18 +-
.../simplex-messaging/simplex-creating.svg | 2 +-
diagrams/simplex-messaging/simplex-using.mmd | 4 +-
diagrams/simplex-messaging/simplex-using.svg | 2 +-
diagrams/simplex-messaging/simplex.mmd | 2 +-
diagrams/simplex-messaging/simplex.svg | 2 +-
simplex-messaging.md | 586 ++++++++----------
7 files changed, 290 insertions(+), 326 deletions(-)
diff --git a/diagrams/simplex-messaging/simplex-creating.mmd b/diagrams/simplex-messaging/simplex-creating.mmd
index b04d3d6b6b..5116c3bedc 100644
--- a/diagrams/simplex-messaging/simplex-creating.mmd
+++ b/diagrams/simplex-messaging/simplex-creating.mmd
@@ -1,20 +1,20 @@
sequenceDiagram
participant B as Bob (sender)
- participant S as server (conn. RID)
+ participant S as server (queue RID)
participant A as Alice (recipient)
- note over A: creating connection ("public" key RK for msg retrieval)
- A ->> S: 1. create connection
- S ->> A: respond with connection's RID and SID
+ note over A: creating queue ("public" key RK for msg retrieval)
+ A ->> S: 1. create queue ("NEW")
+ S ->> A: respond with queue RID and SID ("IDS")
- note over A: out-of-band msg (sender's conn. SID and "public" key EK to encrypt msgs)
+ note over A: out-of-band msg (sender's queue SID and "public" key EK to encrypt msgs)
A -->> B: 2. send out-of-band message
- note over B: confirm connection ("public" key SK for sending messages and any optional info encrypted with "public" key EK)
- B ->> S: 3. confirm connection (command not signed)
+ note over B: confirm queue ("public" key SK for sending messages and any optional info encrypted with "public" key EK)
+ B ->> S: 3. confirm queue ("SEND" command not signed)
S ->> A: 4. deliver Bob's message
note over A: decrypt message ("private" key EK)
- A ->> S: 5. secure connection (RK-signed)
+ A ->> S: 5. secure queue ("KEY", RK-signed)
- note over S: 6. simplex connection RID is established!
+ note over S: 6. simplex queue RID is ready to use!
diff --git a/diagrams/simplex-messaging/simplex-creating.svg b/diagrams/simplex-messaging/simplex-creating.svg
index 6bd2e68635..325fbb6cf8 100644
--- a/diagrams/simplex-messaging/simplex-creating.svg
+++ b/diagrams/simplex-messaging/simplex-creating.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/diagrams/simplex-messaging/simplex-using.mmd b/diagrams/simplex-messaging/simplex-using.mmd
index 6125f87115..3bf0e409b6 100644
--- a/diagrams/simplex-messaging/simplex-using.mmd
+++ b/diagrams/simplex-messaging/simplex-using.mmd
@@ -1,10 +1,10 @@
sequenceDiagram
participant B as Bob (sender)
- participant S as server (conn. RID)
+ participant S as server (queue RID)
participant A as Alice (recipient)
note over B: encrypt message ("public" key EK)
B ->> S: 1. send message to SID (SK-signed command)
- S ->> A: 2. retrieve messages from RID (RK-signed subscription)
+ S ->> A: 2. receive messages from RID (RK-signed subscription)
note over A: decrypt message ("private" key EK)
diff --git a/diagrams/simplex-messaging/simplex-using.svg b/diagrams/simplex-messaging/simplex-using.svg
index 49023e16f7..3cb04ddb70 100644
--- a/diagrams/simplex-messaging/simplex-using.svg
+++ b/diagrams/simplex-messaging/simplex-using.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/diagrams/simplex-messaging/simplex.mmd b/diagrams/simplex-messaging/simplex.mmd
index c8cbad02b7..7f6660868d 100644
--- a/diagrams/simplex-messaging/simplex.mmd
+++ b/diagrams/simplex-messaging/simplex.mmd
@@ -3,7 +3,7 @@ graph LR
VR{{"verify recipient (RK)"}}
S(sender) -->|msg| VS
- subgraph "server (connection RID)"
+ subgraph "server (queue RID)"
VS --> DB[("storage")]
DB --> VR
end
diff --git a/diagrams/simplex-messaging/simplex.svg b/diagrams/simplex-messaging/simplex.svg
index e560e6e09b..aba3110514 100644
--- a/diagrams/simplex-messaging/simplex.svg
+++ b/diagrams/simplex-messaging/simplex.svg
@@ -1 +1 @@
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/simplex-messaging.md b/simplex-messaging.md
index b0c109b19d..98e81b4ef9 100644
--- a/simplex-messaging.md
+++ b/simplex-messaging.md
@@ -6,28 +6,28 @@
- [Introduction](#introduction)
- [SMP Model](#smp-model)
- [Out-of-band messages](#out-of-band-messages)
-- [Simplex connection](#simplex-connection)
+- [Simplex queue](#simplex-queue)
- [SMP procedure](#smp-procedure)
- [SMP elements](#smp-elements)
- [SMP qualities and features](#smp-qualities-and-features)
- [Cryptographic algorithms](#cryptographic-algorithms)
-- [Simplex connection IDs](#simplex-connection-ids)
+- [Simplex queue IDs](#simplex-queue-ids)
- [Server privacy requirements](#server-privacy-requirements)
- [SMP commands](#smp-commands)
- [Correlating responses with commands](#correlating-responses-with-commands)
- [Command authentication](#command-authentication)
- [Recipient commands](#recipient-commands)
- - [Create connection command](#create-connection-command)
- - [Subscribe to connection](#subscribe-to-connection)
- - [Secure connection command](#secure-connection-command)
+ - [Create queue command](#create-queue-command)
+ - [Subscribe to queue](#subscribe-to-queue)
+ - [Secure queue command](#secure-queue-command)
- [Acknowledge message delivery](#acknowledge-message-delivery)
- - [Suspend connection](#suspend-connection)
- - [Delete connection](#delete-connection)
+ - [Suspend queue](#suspend-queue)
+ - [Delete queue](#delete-queue)
- [Sender commands](#sender-commands)
- - [Send message command](#send-message-command)
+ - [Send message](#send-message)
- [Server messages](#server-messages)
- - [Connection IDs response](#connection-ids-response)
- - [Deliver connection message](#deliver-connection-message)
+ - [Queue IDs response](#queue-ids-response)
+ - [Deliver queue message](#deliver-queue-message)
- [Subscription END notification](#subscription-end-notification)
- [Error responses](#error-responses)
- [OK response](#ok-response)
@@ -38,66 +38,45 @@
## Abstract
Simplex messaging protocol is a transport agnostic client-server protocol for
-asynchronous distributed secure unidirectional message transmission.
+asynchronous distributed secure unidirectional message transmission via
+persistent simplex message queues.
It's designed with the focus on communication security and integrity, under the
assumption that any part of the message transmission network can be compromised.
-It addresses the problems of existing communication protocols that undermine
-communication security and privacy:
-
-- Identity related problems:
-
- - visibility of user contacts to anybody observing messages
- - unsolicited messages (spam and abuse)
- - trademark issues (when usernames are used)
- - privacy issues (when phone numbers are used)
- - Participants' identities are known to the network. Depending on the identity
- type (e.g., phone number, DNS-based, username, uuid, public key, etc.) it
- creates different problems, but in all cases it exposes participants and
- their contacts graph to the network and also allows for unsolicited messages
- (spam and abuse).
-
-- [MITM attack][1]. Any mechanism of the encryption 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 compromised the server or
- communication channel.
+It is designed as a low level protocol for other application protocols to solve
+the problem of secure and private message transmission, making [MITM attack][1]
+very difficult at any part of the message transmission system.
## Introduction
The objective of Simplex Messaging Protocol (SMP) is to facilitate the secure
-and private unidirectional transfer of messages from senders to recipients.
+and private unidirectional transfer of messages from senders to recipients via
+persistent simplex queues.
SMP is independent of the particular transmission system and requires only a
reliable ordered data stream channel. While this document describes transport
over TCP, other transports are also possible.
The protocol describes the set of commands that recipient and sender can
-exchange with the SMP server to create and to operate a unidirectional
-"connection" (a data abstraction identifying one of many communication channels
-managed by the server) and to send messages from the sender to the recipient via
-the SMP server.
+exchange with the SMP server to create and to operate a unidirectional "queue"
+(a data abstraction identifying one of many communication channels managed by
+the server) and to send messages from the sender to the recipient via the SMP
+server.
-More complex communication scenarios can be designed using multiple
-connections - for example, a duplex communication channel can be made of 2
-simplex connections.
+More complex communication scenarios can be designed using multiple queues - for
+example, a duplex communication channel can be made of 2 simplex queues.
Protocol is designed with the focus on privacy and security, to some extent
deprioritizing reliability by requiring that SMP servers only store messages
until they are delivered to the recipients and, in any case, for a limited
period of time. For communication scenarios requiring more reliable transmission
the users should use several SMP servers to pass each message and implement some
-additional protocol (e.g., based on blockchain) to ensure that messages are not
-removed, inserted or re-ordered - this is out of scope of this document.
+additional protocol to ensure that messages are not removed, inserted or
+re-ordered - this is out of scope of this document.
SMP removes the need for participants' identities and provides [E2EE][2] without
-the possibility of [MITM attack][1] attack relying on two pre-requisites:
+the possibility of [MITM attack][1] relying on two pre-requisites:
- the users can establish a secure encrypted transport connection with the SMP
server. [Appendix A](#appendix-a) has a possible simple protocol of such
@@ -105,8 +84,8 @@ the possibility of [MITM attack][1] attack relying on two pre-requisites:
protocol can be used.
- the recipient can pass a single message to the sender via pre-existing secure
and private communication channel (out-of-band message) - the information in
- this message is used to establish the connection via SMP server that the
- sender will use to send the encrypted messages to the recipient.
+ this message is used to encrypt messages and to establish connection with SMP
+ server.
## SMP Model
@@ -114,35 +93,34 @@ The SMP model has three communication participants: the recipient, the message
broker (SMP server) that is chosen and, possibly, controlled by the recipient,
and the sender.
-SMP server manages multiple "simplex connections" - data records on the server
-that identify communication channels from the senders to the recipients. The
-same communicating party that is the sender in one connection, can be the
-recipient in another - without exposing this fact to the server.
+SMP server manages multiple "simplex queues" - data records on the server that
+identify communication channels from the senders to the recipients. The same
+communicating party that is the sender in one queue, can be the recipient in
+another - without exposing this fact to the server.
-The connection record consists of 2 unique random IDs generated by the server,
-one for the recipient and another for the sender, and 2 keys to authenticate the
+The queue record consists of 2 unique random IDs generated by the server, one
+for the recipient and another for the sender, and 2 keys to authenticate the
recipient and the sender respectively. The users of SMP protocol must use a
-unique key for each connection, to avoid the possibility of aggregating and
-analysing their connections in case SMP server is compromised.
+unique key for each queue, to avoid the possibility of aggregating and analysing
+their queues in case SMP server is compromised.
-Creating and using this connection requires sending commands to the SMP server
-from the recipient and the sender - they are described in detail in
+Creating and using the queue requires sending commands to the SMP server from
+the recipient and the sender - they are described in detail in
[SMP commands](#smp-commands) section.
## Out-of-band messages
The out-of band invitation message is sent via some trusted alternative channel
-by the recipient to the sender. This message is used to share the encryption
+from the recipient to the sender. This message is used to share the encryption
(a.k.a. "public") key that the sender will use to encrypt the messages (to be
-decrypted by the recipient), sender connection ID, server address and any other
+decrypted by the recipient), sender queue ID, server address and any other
information necessary to establish secure encrypted connection with SMP server
(see [Appendix A](#appendix-a) for a simple transport protocol example).
-The syntax of the message defined with [ABNF][8] is:
+The [ABNF][8] syntax of the message is:
```abnf
-outOfBandMsg = encryptionKey SP senderConnId SP server SP serverKeyHash
- ; SP is a space character in ABNF
+outOfBandMsg = encryptionKey CRLF senderConnId CRLF server CRLF serverKeyHash
encryptionKey = encoded ; base64
senderConnId = encoded
server = hostname [":" port]
@@ -155,95 +133,91 @@ serverKeyHash = encoded
`port` is optional, the default TCP port for SMP protocol is 5223.
-Defining the approach to out-of-band message passing is out of scope of the
-simplex messaging protocol. See [Appendix B](#appendix-b) for one of the
-possible practical approaches.
+Defining the approach to out-of-band message passing is out of scope of this
+protocol. See [Appendix B](#appendix-b) for one of the possible practical
+approaches.
-## Simplex connection
+## Simplex queue
-The simplex connection is the main unit of SMP protocol. It is used by:
+The simplex queue is the main unit of SMP protocol. It is used by:
-- the sender of the connection (who received out-of-band message) to send
- messages to the server using connection ID, signed by sender's 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 commands by the recepient key.
+- the sender of the queue (who received out-of-band message) to send messages to
+ the server using sender's queue ID, signed by sender's key.
+- the recepient of the queue (who created the queue and who sent out-of-band
+ message) will use it to retrieve messages from the server, signing the
+ commands by the recepient key.
- participant identities are not shared with the server - new unique keys and
- connection IDs are used for each connection.
+ queue IDs are used for each queue.
-This simplex connection can serve as a building block for more complex
-communication network. For example, two (or more, for redundancy) simplex
-connections can be used to create a duplex communication channel. Higher level
-primitives that are only known to system participants in their client
-applications can be created as well - user profiles, contacts, conversations,
-groups and broadcasts. Simplex messaging servers only have the information about
-the low-level simplex connections. In this way a high level of privacy and
-security of the conversations is provided. Application level primitives are not
-in scope of the simplex messaging protocol.
+This simplex queue can serve as a building block for more complex communication
+network. For example, two (or more, for redundancy) simplex queues can be used
+to create a duplex communication channel. Higher level primitives that are only
+known to system participants in their client applications can be created as
+well - contacts, conversations, groups and broadcasts. Simplex messaging servers
+only have the information about the low-level simplex queues. In this way a high
+level of privacy and security of the conversations is provided. Application
+level primitives are not in scope of this protocol.
This approach is based on the concept of [unidirectional networks][4] that are
used for applications with high level of information security.
-Access to each connection is controlled with unique (not shared with other
-connections) assymetric key pairs, separate for the sender and the recipient.
-The sender and the receiver have private keys, and the server has associated
-public keys to authenticate participants' commands by verifying cryptographic
-signatures.
+Access to each queue is controlled with unique (not shared with other queues)
+assymetric key pairs, separate for the sender and the recipient. The sender and
+the receiver have private keys, and the server has associated public keys to
+authenticate participants' commands by verifying cryptographic signatures.
-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.
+The messages sent into the queue are encrypted and decrypted using another key
+pair that was shared via out-of-band message - the recepient has the private key
+and the sender has the associated public key.
-**Simplex connection diagram:**
+**Simplex queue diagram:**
-
+
-Connection is defined by recipient ID `RID` unique for the server. It also has a
+Queue is defined by recipient ID `RID` unique for the server. It also has a
different unique sender ID `SID`. Sender key (`SK`) is used by the server to
verify sender's commands (identified by `SID`) to send messages. Recipient key
(`RK`) is used by the server to verify recipient's commands (identified by
`SID`) to retrieve messages.
The protocol uses different IDs for sender and recipient in order to provide an
-additional connection privacy by complicating correlation of senders and
-recipients commands sent over the network - even though they are encrypted using
-server's public key, in case this key is compromised it would still be difficult
-to correlate senders and recipients, it would require access to connections
-records on the server.
+additional privacy by complicating correlation of senders and recipients
+commands sent over the network - even though they are encrypted using server's
+public key, in case this key is compromised it would still be difficult to
+correlate senders and recipients without access to queue records on the server.
## SMP procedure
-The SMP procedure of creating a simplex connection on SMP server is explained
-using participants Alice (the recipient) who wants to receive the messages from
-Bob (the sender).
+The SMP procedure of creating a simplex queue on SMP server is explained using
+participants Alice (the recipient) who wants to receive the messages from Bob
+(the sender).
-To create a simpelex connection Alice and Bob follow these steps:
+To create and start using a simpelex queue Alice and Bob follow these steps:
-1. Alice creates a simplex connection on the server:
+1. Alice creates a simplex queue on the server:
1. decides which SMP server to use (can be the same or different server that
- Alice uses for other connections) and opens secure encrypted transport
+ Alice uses for other queues) and opens secure encrypted transport
connection to the chosen SMP server (see [Appendix A](#appendix-a)).
2. generates a new random public/private key pair (encryption key - `EK`)
that she did not use before for Bob to encrypt the messages.
3. generates another new random public/private key pair (recepient key -
`RK`) that she did not use before for her to sign commands and to decrypt
the transmissions received from the server.
- 4. sends `"CONN"` command to the server to create a simplex connection (see
- `create` in [Create connection command](#create-connection-command)). This
- command can either be anonymous or the server can be configured to use the
+ 4. sends `"CONN"` command to the server to create a simplex queue (see
+ `create` in [Create queue command](#create-queue-command)). This command
+ can either be anonymous or the server can be configured to use the
signature field to authenticate the users who are allowed to create
- connections. This connection command contains previouisly generated uniqie
- "public" key `RK` that will be used to sign the following commands related
- to the same connection, for example to subscribe to the messages received
- to this connection or to update the connection, e.g. by setting the key
- required to send the messages (initially Alice creates the connection that
- accepts unsigned commands to send messages, so anybody could send the
- message via this connection if they knew the connection ID and server
- address).
- 5. The server sends `"IDS"` response with connection IDs (`connIds`):
- - recipient ID `RID` for Alice to manage the connection and to receive the
+ queues. This command contains previouisly generated uniqie "public" key
+ `RK` that will be used to sign the following commands related to the same
+ queue, for example to subscribe to the messages received to this queue or
+ to update the queue, e.g. by setting the key required to send the messages
+ (initially Alice creates the queue that accepts unsigned messages, so
+ anybody could send the message via this queue if they knew the queue
+ sender's ID and server address).
+ 5. The server sends `"IDS"` response with queue IDs (`queueIds`):
+ - recipient ID `RID` for Alice to manage the queue and to receive the
messages.
- - sender ID `SID` for Bob to send messages to the connection.
+ - sender ID `SID` for Bob to send messages to the queue.
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)
@@ -251,73 +225,69 @@ To create a simpelex connection Alice and Bob follow these steps:
- the unique "public" key (`EK`) that Bob must use to encrypt messages.
- SMP server address and information to open secure encrypted transport
connection (see [Appendix A](#appendix-a))
- - the sender connection ID `SID` for Bob to use.
-3. Bob, having received the out-of-band message from Alice, accepts the
- connection:
+ - the sender queue ID `SID` for Bob to use.
+3. Bob, having received the out-of-band message from Alice, connects to the
+ queue:
1. generates a new random public/private key pair (sender key - `SK`) that he
- did not use before for him to sign commands to Alice's server to send the
- messages.
- 2. prepares the confirmation message for Alice to secure the connection. This
+ did not use before for him to sign messages sent to Alice's server.
+ 2. prepares the confirmation message for Alice to secure the queue. This
message includes:
- previously generated "public" key `SK` that will be used by Alice's
- server to authenticate Bob's commands to send messages, once the
- connection is secured.
+ server to authenticate Bob's messages, once the queue is secured.
- optionally, any additional information (application specific, e.g. Bob's
profile name and details).
3. encrypts the confirmation body with the "public" key `EK` (that Alice
provided via the out-of-band message).
- 4. sends the encrypted message to the server with connection ID `SID` (see
- `send` in [Send message command](#send-message-command)) to confirm the
- connection. This message to confirm the connection must not be signed -
- signed messages will be rejected until Alice secures the connection
- (below).
-4. Alice receives Bob's message from the server using recipient connection ID
- `RID` (possibly, via the same transport connection she already has opened -
- see `message` in [Deliver connection message](#deliver-connection-message)):
+ 4. sends the encrypted message to the server with queue ID `SID` (see `send`
+ in [Send message](#send-message)). This initial message to the queue must
+ not be signed - signed messages will be rejected until Alice secures the
+ queue (below).
+4. Alice receives Bob's message from the server using recipient queue ID `RID`
+ (possibly, via the same transport connection she already has opened - see
+ `message` in [Deliver queue message](#deliver-queue-message)):
1. she decrypts received message with "private" key `EK`.
- 2. even though anybody could have sent the message to the connection with ID
- `SID` before it is secured (e.g. if communication is compromised), Alice
- would ignore all messages until the decryption succeeds (i.e. the result
+ 2. even though anybody could have sent the message to the queue with ID `SID`
+ before it is secured (e.g. if communication is compromised), Alice would
+ ignore all messages until the decryption succeeds (i.e. the result
contains the expected message format). Optionally, in the client
application, she also may identify Bob using the information provided, but
it is out of scope of SMP protocol.
-5. Alice secures the connection `RID` with `"KEY"` command so only Bob can send
- messages to it (see [Secure connection command](#secure-connection-command)):
+5. Alice secures the queue `RID` with `"KEY"` command so only Bob can send
+ messages to it (see [Secure queue command](#secure-queue-command)):
1. she sends the command with `RID` signed with "private" key `RK` to update
- the connection to only accept requests signed by "private" key `SK`
- provided by Bob.
+ the queue to only accept requests signed by "private" key `SK` provided by
+ Bob.
2. From this moment the server will accept only signed commands to `SID`, so
- only Bob will be able to send messages to the connection `SID`
- (corresponding to `RID` that Alice has).
- 3. Once connection is secured, Alice deletes `SID` and `SK` - even if Alice's
- client is compromosed in the future, the attacker would not be able to
+ only Bob will be able to send messages to the queue `SID` (corresponding
+ to `RID` that Alice has).
+ 3. Once queue is secured, Alice deletes `SID` and `SK` - even if Alice's
+ client is compromised in the future, the attacker would not be able to
send messages pretending to be Bob.
-6. The simplex connection `RID` is now established on the server.
+6. The simplex queue `RID` is now ready to use.
This flow is shown on the sequence diagram below.
-**Creating simplex connection from Bob to Alice:**
+**Creating simplex queue 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 simplex connection).
- 2. he signs the command to the server connection `SID` using the "private"
- key `SK` (that only he knows, used only for this connection).
- 3. he sends `"SEND"` command to the server (see `send` in
- [Send message command](#send-message-command)), that the server will
- authenticate using the "public" key `SK` (that Alice earlier provided to
- the server).
+ Alice, only known to Alice and Bob, used only for one simplex queue).
+ 2. he signs `"SEND"` command to the server queue `SID` using the "private"
+ key `SK` (that only he knows, used only for this queue).
+ 3. he sends the command to the server (see `send` in
+ [Send message](#send-message)), that the server will authenticate using
+ the "public" key `SK` (that Alice earlier provided to the server).
2. Alice receives the message(s):
- 1. she signs `"SUB"` command to the server to subscribe to the connection
- `RID` with the "private" key `RK` (see `subscribeCmd` in
- [Subscribe to connection](#subscribe-to-connection)).
+ 1. she signs `"SUB"` command to the server to subscribe to the queue `RID`
+ with the "private" key `RK` (see `subscribe` in
+ [Subscribe to queue](#subscribe-to-queue)).
2. the server, having authenticated Alice's command with the "public" key
`RK` that she provided, delivers Bob's message(s) (see `message` in
- [Deliver connection message](#deliver-connection-message)).
+ [Deliver queue message](#deliver-queue-message)).
3. she decrypts Bob's message(s) with the "private" key `EK` (that only she
has).
4. she acknowledges the message reception to the server with `"ACK"` so that
@@ -325,24 +295,24 @@ Bob now can securely send messages to Alice:
This flow is show on sequence diagram below.
-**Sending messages from Bob to Alice via simplex connection:**
+**Sending messages from Bob to Alice via simplex queue:**
-
+
-**Simplex connection operation:**
+**Simplex queue operation:**
-
+
-Sequence diagram does not show E2EE - connection itself knows nothing about
-encryption between sender and receiver.
+Sequence diagram does not show E2EE - server knows nothing about encryption
+between sender and receiver.
A higher level protocol application protocol should define the semantics that
-allow to use two simplex connections (or two sets of connections for redundancy)
-for the bi-directional chat and for any other communication scenarios.
+allow to use two simplex queues (or two sets of queues for redundancy) for the
+bi-directional chat and for any other communication scenarios.
The SMP is intentionally unidirectional - it provides no answer to how Bob will
know that the transmission succeeded, and whether Alice received any messages.
-There may be a situation when Alice wants to securely receive the messages from
+There may be a scenario 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
@@ -351,24 +321,21 @@ 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 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.
+send encrypted messages to Alice, Bob can create the second simplex queue that
+will allow Alice to send messages to Bob in the same way, sending the second
+queue details via the first queue. If both Alice and Bob have their respective
+uniqie "public" keys (Alice's and Bob's `EK`s of two separate queues), the
+conversation can be both encrypted and signed.
-The established connections can also be used to change the encryption keys
-providing [forward secrecy][5].
+The established queues 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 simplex connections are used by the participants is not in scope of this low
-level simplex messaging protocol.
+can use multiple queues 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 queue 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.
## SMP qualities and features
@@ -378,15 +345,14 @@ The simplex messaging protocol:
- transport agnostic - the protocol does not define how clients connect to the
servers. It can be implemented over any ordered data stream channel: TCP
connection, HTTP with long polling, websockets, etc..
- - 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 out of scope of this simplex messaging
- protocol.
+ - not semantic - the protocol does not assign any meaning to queues and
+ messages. While on the application level the queues 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 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.
@@ -394,33 +360,33 @@ The simplex messaging protocol:
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
- message, it is in scope of application level protocol(s), and out of scope
- of this simplex messaging protocol.
+ - for each queue, the message recipient defines the server through which the
+ sender should send messages.
+ - while multiple servers and multiple queues can be used to pass each message,
+ it is in scope of application level protocol(s), and out of scope of this
+ simplex messaging protocol.
- servers store messages only until they are retrieved by the recipients, and
in any case, for a limited time.
- servers are required to NOT 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 SMP servers is simplex connections:
- - each connection is created and managed by the connection recipient.
+ or to determine the list of queues established by any participant - this
+ information is only stored on client devices.
+- the only element provided by SMP servers is simplex queues:
+ - each queue is created and managed by the queue 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.
- - both "public" keys are provided to the server by the connection recepient
- when the connection is established.
+ send the messages into the queue, and another unique "public" key - to
+ retrieve the messages from the queue. "Unique" here means that each "public"
+ key is used only for one queue and is not used for any other context -
+ effectively, this key is not public and does not represent any participant
+ identity.
+ - both "public" keys are provided to the server by the queue recepient when
+ the queue is created.
- the "public" keys known to the server and used to authenticate commands from
the participants are unrelated to the keys used to encrypt and decrypt the
- messages - the latter keys are also unique per each connection but they are
- only known to participants, not to the servers.
+ messages - the latter keys are also unique per each queue but they are only
+ known to participants, not to the servers.
- messaging graph can be asymmetric: Bob's ability to send messages to Alice
does not automatically lead to the Alice's ability to send messages to Bob.
@@ -429,11 +395,11 @@ The simplex messaging protocol:
Simplex messaging clients need to cryptographically sign commands:
- with the recipient's key `RK` (server to verify):
- - to subscribe to connection.
- - to secure the connection.
+ - to subscribe to queue.
+ - to secure the queue.
- to acknowledge received messages.
- - to suspend the connection.
- - to delete the connection.
+ - to suspend the queue.
+ - to delete the queue.
- with the sender's key `SK`:
- to send messages (server to verify).
@@ -453,11 +419,10 @@ The reasons to use these algorithms:
Future versions of the protocol may allow different algorithms.
-## Simplex connection IDs
+## Simplex queue IDs
-Simplex messaging servers MUST generate 2 different IDs for each new
-connection - for recipient (that created the connection) and for sender. It is
-REQUIRED that:
+Simplex messaging servers MUST generate 2 different IDs for each new queue - for
+recipient (that created the queue) and for sender. It is REQUIRED that:
- these IDs are different and unique within the server.
- based on 64-128-bit integers generated with cryptographically strong
@@ -470,10 +435,10 @@ other servers:
- logs of the client commands and transport connections in the production
environment.
-- history of deleted connections, retrieved or acknowledged messages.
-- snapshots of the database they use to store connections and messages (instead
+- history of deleted queues, retrieved or acknowledged messages.
+- snapshots of the database they use to store queues and messages (instead
simplex messaging clients must manage redundancy by using more than one
- simplex messaging server.
+ simplex messaging server).
- any other information that may compromise privacy or [forward secrecy][4] of
communication between clients using simplex messaging servers.
@@ -486,11 +451,11 @@ Each transmission between the client and the server must have this format/syntax
```abnf
transmission = [signature] CRLF signed CRLF
-signed = [connId] CRLF msg
+signed = [queueId] CRLF msg
msg = recipientCmd / send / serverMsg
recipientCmd = create / subscribe / secure / acknowledge / suspend / delete
-serverMsg = connIds / message / unsubscribed / ok / error
-connId = encoded ; empty connection ID is used with "create" command
+serverMsg = queueIds / message / unsubscribed / ok / error
+queueId = encoded ; empty queue ID is used with "create" command
signature = encoded ; empty signature can be used with "create" and "send" commands
encoded = base64
```
@@ -502,9 +467,9 @@ The syntax of specific commands and responses is defined below.
### Correlating responses with commands
-The server must send `connIds`, `error` and `ok` responses in the same order
-within each connection ID as the commands received in the transport connection,
-so that they can be correlated by the clients.
+The server must send `queueIds`, `error` and `ok` responses in the same order
+within each queue ID as the commands received in the transport connection, so
+that they can be correlated by the clients.
If the transport connection is closed before some responses are sent, these
responses should be discarded.
@@ -515,50 +480,50 @@ The SMP servers must athenticate all transmissions (excluding `create` and
`send` commands sent with empty signatures) by verifying the provided
signatures. Signature should be the hash of the first part `signed` (including
CRLF characters) of `transmission`, encrypted with the key associated with the
-connection ID (sender's or recepient's, depending on which connection ID is
-used).
+queue ID (sender's or recepient's, depending on which queue ID is used).
### Recipient commands
Sending any of the commands in this section (other than `create`, that is sent
-without connection ID) is only allowed with recipient's ID (`RID`). If sender's
-ID is used the server must respond with `"ERR AUTH"` response (see
+without queue ID) is only allowed with recipient's ID (`RID`). If sender's ID is
+used the server must respond with `"ERR AUTH"` response (see
[Error responses](#error-responses)).
-#### Create connection command
+#### Create queue command
-This command is sent by the recipient to the SMP server to create the new
-connection. The syntax is:
+This command is sent by the recipient to the SMP server to create the new queue.
+The syntax is:
```abnf
-create = %s"CONN" SP recipientKey
+create = %s"NEW" SP recipientKey
recipientKey = encoded
```
-If the connection is created successfully, the server must send `connIds`
-response with the recipient's and sender's connection IDs:
+If the queue is created successfully, the server must send `queueIds` response
+with the recipient's and sender's queue IDs:
```abnf
-connIds = %s"IDS" SP recipientId SP senderId
+queueIds = %s"IDS" SP recipientId SP senderId
recipientId = encoded
senderId = encoded
```
-This response should be sent with empty connection ID (the second part of the
+This response should be sent with empty queue ID (the second part of the
transmission).
-Once the connection is created, the recipient gets automatically subscribed to
-receive the messages from that connection, until the transport connection is
-closed. The `subscribe` command is needed only to start receiving the messages
-from the existing connection when the new transport connection is opened.
+Once the queue is created, the recipient gets automatically subscribed to
+receive the messages from that queue, until the transport connection is closed.
+The `subscribe` command is needed only to start receiving the messages from the
+existing queue when the new transport queue is opened.
-`signature` part of CONN `transmission` should an empty string; SMP servers can
-also use it to authenticate users who are allowed to create simplex connections.
+`signature` part of NEW `transmission` should an empty string; SMP servers can
+also use it to authenticate users who are allowed to create simplex queues on
+the server.
-#### Subscribe to connection
+#### Subscribe to queue
-When the simplex connection was not created in the current transport connection,
-the recipient must use this command to start receiving messages from it:
+When the simplex queue was not created in the current transport connection, the
+recipient must use this command to start receiving messages from it:
```abnf
subscribe = %s"SUB"
@@ -566,21 +531,20 @@ subscribe = %s"SUB"
If subscription is successful the server should respond with the first available
message or with `ok` response if no messages are available. The recipient will
-continue receiving the messages from this connection until the transport
-connection is closed or until another transport connection subscribes to the
-same simplex connection - in this case the first subscription should be
-cancelled and [subscription END notification](#subscription-end-notification)
-delivered.
+continue receiving the messages from this queue until the transport connection
+is closed or until another transport connection subscribes to the same simplex
+queue - in this case the first subscription should be cancelled and
+[subscription END notification](#subscription-end-notification) delivered.
The first message will be delivered either immediately or as soon as it is
available; to receive the following message the recipient must acknoledge the
reception of the message (see
[Acknowledge message delivery](#acknowledge-message-delivery)).
-#### Secure connection command
+#### Secure queue command
This command is sent by the recipient to the server to add sender's key to the
-connection:
+queue:
```
secure = %s"KEY" SP senderKey
@@ -590,7 +554,7 @@ senderKey = encoded
`senderKey` is received from the sender as part of the first message - see
[Send Message Command](#send-message-command).
-Once the connection is secured only signed messages can be sent to it.
+Once the queue is secured only signed messages can be sent to it.
#### Acknowledge message delivery
@@ -607,35 +571,35 @@ the time of message storage, whether it was delivered to the recipient or not.
Having received the acknowledgement, SMP server should immediately delete the
sent message and then send the next available message or respond with `ok` if
-there are no more messages stored in this simplex connection.
+there are no more messages stored in this simplex queue.
-#### Suspend connection
+#### Suspend queue
-The recipient can suspend connection prior to deleting it to make sure that no
+The recipient can suspend queue prior to deleting it to make sure that no
messages are lost:
```abnf
suspend = %s"OFF"
```
-The server must respond with `"ERR AUTH"` to any messages sent after the
-connection was suspended (see [Error responses](#error-responses)).
+The server must respond with `"ERR AUTH"` to any messages sent after the queue
+was suspended (see [Error responses](#error-responses)).
The server must respond `ok` to this command if it was successful.
This command can be sent multiple times (in case transport connection was
interrupted and the response was not delivered), the server should still respond
-`ok` even if the connection is already suspended.
+`ok` even if the queue is already suspended.
-There is no command to reactivate the connection. Servers must delete suspended
-connections that were not deleted after some period of time.
+There is no command to resume the queue. Servers must delete suspended queues
+that were not deleted after some period of time.
-#### Delete connection
+#### Delete queue
-The recipient can delete the connection, whether it was suspended or not.
+The recipient can delete the queue, whether it was suspended or not.
-All undelivered messages will not be delivered - they will be deleted as soon as
-command is received, before the response is sent.
+All undelivered messages will not be delivered - they should be deleted as soon
+as command is received, before the response is sent.
```abnf
delete = %s"DEL"
@@ -643,16 +607,16 @@ delete = %s"DEL"
### Sender commands
-Currently SMP defines only one command that can be used by sender - `send`
+Currently SMP defines only one command that can be used by senders - `send`
message. This command must be used with sender's ID, if recipient's ID is used
the server must respond with `"ERR AUTH"` response (see
[Error responses](#error-responses)).
-#### Send message command
+#### Send message
-This command is sent to the server by the sender both to confirm the connection
-after the sender received out-of-band message from the recipient and to send
-messages after the connection is secured:
+This command is sent to the server by the sender both to confirm the queue after
+the sender received out-of-band message from the recipient and to send messages
+after the queue is secured:
```abnf
send = %s"SEND" SP msgBody
@@ -666,26 +630,25 @@ msgBody = *OCTET ; any content of specified size - safe for binary
`stringMsg` is allowed primarily to test SMP servers, e.g. via telnet.
-The first message is sent to confirm the connection - it should contain sender's
+The first message is sent to confirm the queue - it should contain sender's
server key (see decrypted message syntax below) - this first message must be
sent without signature.
-Once connection is secured (see
-[Secure connection command](#secure-connection-command)), messages must be sent
-with the signature.
+Once queue is secured (see [Secure queue command](#secure-queue-command)),
+messages must be sent with the signature.
The server must respond with `"ERR AUTH"` response in the following cases:
-- connection does not exist or suspended,
-- connection is secured but the transmission does NOT have a signature,
-- connection is NOT secured but the transmission has a signature.
+- queue does not exist or suspended,
+- queue is secured but the transmission does NOT have a signature,
+- queue is NOT secured but the transmission has a signature.
-Until the connection is secured, the server should accept any number of unsigned
+Until the queue is secured, the server should accept any number of unsigned
messages - it both enables the legimate sender to resend the confirmation in
case of failure and also allows the simplex messaging client to ignore any
confirmation messages that may be sent by the attackers (assuming they could
-have intercepted the connection ID in the server response, but do not have a
-correct encryption key passed to sender in out-of-band message).
+have intercepted the queue ID in the server response, but do not have a correct
+encryption key passed to sender in out-of-band message).
The body should be encrypted with the recipient's "public" key (`EK`); once
decrypted it must have this format:
@@ -703,15 +666,15 @@ key and can be used in the future revisions of SMP protocol for other purposes.
### Server messages
-#### Connection IDs response
+#### Queue IDs response
-Server must respond with this message when the new connection is created.
+Server must respond with this message when the new queue is created.
-See its syntax in [Create connection command](#create-connection-command)
+See its syntax in [Create queue command](#create-queue-command)
-#### Deliver connection message
+#### Deliver queue message
-The server must deliver messages to all subscribed simplex connections on the
+The server must deliver messages to all subscribed simplex queues on the
currently open transport connection. The syntax for the message delivery is:
```abnf
@@ -721,20 +684,20 @@ timestamp = date-time; RFC3339
```
`msgId` - unique message ID generated by the server based on 32-64 bits
-cryptographically strong random number. It can be used by the clients to detect
-messages that were delivered more than once (in case the transport connection
-was interrupted and the server did not receive the message delivery
+cryptographically strong random number. It should be used by the clients to
+detect messages that were delivered more than once (in case the transport
+connection was interrupted and the server did not receive the message delivery
acknowledgement).
`timestamp` - the UTC time when the server received the message from the sender,
must be in date-time format defined by [RFC 3339][10]
-`binaryMsg` - see syntax in [Send message command](#send-message-command)
+`binaryMsg` - see syntax in [Send message](#send-message)
#### Subscription END notification
-When another transport connection is subscribed to the same simplex connection,
-the server should unsubscribe and to send the notification to the previously
+When another transport connection is subscribed to the same simplex queue, the
+server should unsubscribe and to send the notification to the previously
subscribed transport connection:
```abnf
@@ -748,12 +711,13 @@ No further messages should be delivered to unsubscribed transport connection.
The server can respond with an error response in the following cases:
- unknown command name (`"UNKNOWN"`),
-- prohibited command (`"PROHIBITED"`) - server response sent from client,
+- prohibited command (`"PROHIBITED"`) - any server response sent from client or
+ `ACK` sent without active subscription or without message delivery,
- incorrect command or transmission syntax (`"SYNTAX"`) - see error codes below
- incorrect message body size (`"SIZE"`)
- authentication error (`"AUTH"`) - incorrect signature, unknown (or suspended)
- connection, sender's ID is used in place of recipient's and vice versa, and
- some other cases (see [Send message command](#send-message-command))
+ queue, sender's ID is used in place of recipient's and vice versa, and some
+ other cases (see [Send message command](#send-message-command))
- internal server error (`"INTERNAL"`).
The syntax for error responses:
@@ -762,18 +726,18 @@ The syntax for error responses:
error = %s"ERR " errorType
errorType = %s"UNKNOWN" / %s"PROHIBITED" / %s"SYNTAX " code / %s"SIZE" / %s"AUTH" / %s"INTERNAL"
code = badTransmission / badParameters / noCredentials / hasCredentials / noConnId / msgBody
-badTransmission = "1" ; signature or connection ID are not valid base64 encoded string
+badTransmission = "1" ; signature or queue ID are not valid base64 encoded string
badParameters = "2" ; incorrect number or format of parameters
-noCredentials = "3" ; connection ID and/or signature are required but absent
-hasCredentials = "4" ; connection ID and/or signature are not allowed but present
-noConnId = "5" ; connection ID is required and absent - only used in SEND command atm
+noCredentials = "3" ; queue ID and/or signature are required but absent
+hasCredentials = "4" ; queue ID and/or signature are not allowed but present
+noConnId = "5" ; queue ID is required and absent - only used in SEND command atm
msgBody = "6" ; message body has incorrect format, it is neither a number nor starts from ":"
```
Server implementations must aim to respond within the same time for each command
in all cases when `"ERR AUTH"` response is required to prevent timing attacks
-(e.g., the server should execute signature verification even when the connection
-does not exist on the server).
+(e.g., the server should execute signature verification even when the queue does
+not exist on the server).
### OK response
@@ -796,17 +760,17 @@ level) transport protocol to communicate with the server.
Some protocol should be used to ecrypt the connection traffic - one simple
option that does not require any cetralized certificate authority is below.
-When the connection is established, the server sends the binary encryption key
-that the client should match with key or fingerprint available to them - if they
-do not match, they should terminate the connection.
+When the transport connection is established, the server sends the binary
+encryption key that the client should match with key or fingerprint available to
+them - if they do not match, they should terminate the connection.
The client should respond with the symmetric key that will be used by both the
client and the server to encrypt all traffic in the connection - this key should
be encrypted with the public key initially sent by the server.
After the symmetric key is sent to the server, all communication should happen
-in encrypted binary chunks having a fixed size of 4096 bytes irrespective of the
-size of the command/message that should be sent. Smaller messages should be
+in encrypted binary chunks having a fixed size (e.g. 4096 bytes) irrespective of
+the size of the command/message that should be sent. Smaller messages should be
padded, multiple commands/messages can be packed into a single chunk. If the
application using SMP needs to transmit a file or a larger message, it should be
broken down into fragments. The format of application level messages within SMP
@@ -823,7 +787,7 @@ For practical purposes 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 participant's device or via the video call.
Although a video call still allows for a highly sophisticated MITM attack, it
-would require that in addition to compromising simplex connection to intercept
+would require that in addition to compromising simplex queue to intercept
messages, the attacker also identifies and compromises the video connection in
another channel and substitutes the video in real time.