dandri/simplexmq
1
0
Fork 0
mirror of https://github.com/simplex-chat/simplexmq.git synced 2026-03-29 12:19:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

update overview (#233)

Browse Source 
* update overview

* network/framework -> platform

* fix links

* corrections

* corrections

* correction

* correction

* corrections

* update acknowledgements

* remove old overview.md

* update cyptographic primitives, remove acknoledgement

Co-authored-by: Efim Poberezkin <8711996+efim-poberezkin@users.noreply.github.com>
This commit is contained in:
Evgeny Poberezkin
2022-01-01 13:59:03 +00:00
committed by GitHub
parent 5e29e3698e
commit 1737686c1e
2 changed files with 54 additions and 321 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
protocol/overview-tjr.md
View File

@@ -1,14 +1,29 @@
# SimpleX: messaging and application network
Revision 1, 2022-01-01
Evgeny Poberezkin
# SimpleX: messaging and application platform
## Table of contents
todo
- [Introduction](#introduction)
- [What is SimpleX](#what-is-simplex)
- [SimpleX objectives](#simplex-objectives)
- [In Comparison](#in-comparison)
- [Technical Details](#technical-details)
- [Trust in Servers](#trust-in-servers)
- [Client -> Server Communication](#client---server-communication)
- [SimpleX Messaging Protocol](#simplex-messaging-protocol)
- [SimpleX Agents](#simplex-agents)
- [Encryption Primitives Used](#encryption-primitives-used)
- [Threat model](#threat-model)
- [Acknowledgements](#acknowledgements)
## Introduction
#### What is SimpleX
SimpleX as a whole is a framework upon which applications can be built. SimpleX Chat is one such application that also serves as an example and reference application.
SimpleX as a whole is a platform upon which applications can be built. SimpleX Chat is one such application that also serves as an example and reference application.
- SimpleX Messaging Protocol (SMP) is a protocol to send messages in one direction to a recipient, relying on a server in-between. The messages are delivered via uni-directional queues created by recipients.
@@ -23,7 +38,7 @@ SimpleX as a whole is a framework upon which applications can be built. SimpleX
- SimpleX Agents interface with SimpleX Clients to provide a more high-level API intended to be used by applications. Typically they are embedded as libraries, but are designed so they can also be abstracted into local services.
*Diagram showing the SimpleX Chat app, with logical layers of the chat application interfacing with a SimpleX Agent library, which in in turn interfaces with a SimpleX Client library. The Client library in turn speaks the Messaging Protocol to a SimpleX Server.*
*Diagram showing the SimpleX Chat app, with logical layers of the chat application interfacing with a SimpleX Agent library, which in turn interfaces with a SimpleX Client library. The Client library in turn speaks the Messaging Protocol to a SimpleX Server.*
```
User's Computer Internet Third-Party Server
@@ -57,7 +72,7 @@ SimpleX as a whole is a framework upon which applications can be built. SimpleX
- Low latency: the delay introduced by the network should not be higher than 100ms-1s in addition to the underlying TCP network latency.
2. Provide better communication security and privacy than the alternative instant messaging solutions. In particular SimpleX provides better privacy of metadata (who talks to whom and when) and better security active network attackers and malicious servers. XXX I added malicious servers because I think that's a claim you want to make - i.e. the out of band key exchange was specifically because you didn't trust signal's central server, no?
2. Provide better communication security and privacy than the alternative instant messaging solutions. In particular SimpleX provides better privacy of metadata (who talks to whom and when) and better security against active network attackers and malicious servers.
3. Balance user experience with privacy requirements, prioritizing experience of mobile device users.
@@ -74,7 +89,7 @@ In comparison to more traditional messaging applications (e.g. WhatsApp, Signal,
- servers do not store any user information (no user profiles or contacts, or messages once they are delivered), and primarily use in-memory persistence.
- users can change servers with minimal disruption - even after an in-use server disappears, simply by changing the configuration on which servers the new queues are created. XXX I reworded this because I think you can make this claim. Claim that senders and recipients SHOULD use different servers for their receive queue, and then if an in-use server disappears, the user who had it as their receive queue will notice and tell its communication partners to rotate their sending queue.
- users can change servers with minimal disruption - even after an in-use server disappears, simply by changing the configuration on which servers the new queues are created.
## Technical Details
@@ -94,26 +109,26 @@ Users may trust a server because:
- Users trust their contacts and the servers they chose.
By default, servers do not retain access logs, and permanently delete messages and queues when requested. Messages persist only in memory until they cross a threshold of time, typically on the order of days.[0] There is still a risk that a server maliciously record all queues and messages (even though encrypted) sent via the same transport connection and to gain a partial knowledge of the user’s communications graph and other meta-data.
By default, servers do not retain access logs, and permanently delete messages and queues when requested. Messages persist only in memory until they cross a threshold of time, typically on the order of days.[0] There is still a risk that a server maliciously records all queues and messages (even though encrypted) sent via the same transport connection to gain a partial knowledge of the user’s communications graph and other meta-data.
SimpleX supports measures (managed transparently to the user at the agent level) to mitigate the trust placed in servers. These include rotating the queues in use between users, noise traffic, and supporting overlay networks such as Tor.
[0] While configurable by servers, a minimum value is enforced by the default software. SimpleX Agents provide redundant routing over queues to mitigate against message loss. XXX Note that I added this design (for engineering, not privacy purposes) because it seems like a concession might be needed in some scenarios. You don't have to keep it (or implement it right away.)
[0] While configurable by servers, a minimum value is enforced by the default software. SimpleX Agents provide redundant routing over queues to mitigate against message loss.
#### Client -> Server Communication
Utilizing TLS grants the SimpleX Messaging Protocol (SMP) server authentication and metadata protection to a passive network observer. But SMP does not rely on the transport protocol for message confidentiality or client authentication. The SMP protocol itself provides end-to-end confidentiality, authentication, and integrity of messages between communicating parties.
Servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels - either provided with the client library or provided in the secure introduction between clients. The offline certificate signs an online certificate used in the transport protocol handshake. [0] XXX This is a change from our previous discussion. I realized the original model of a single key is not good practice because it hamstrings you with regards to rotating the key due to suspected compromise/protocol upgrades. So instead we make it a two-cert chain. This is the same model used in Tor both for node connections and DirAuth signing.
Servers have long-lived, self-signed, offline certificates whose hash is pre-shared with clients over secure channels - either provided with the client library or provided in the secure introduction between clients. The offline certificate signs an online certificate used in the transport protocol handshake. [0]
If the transport protocol's confidentiality is broken, incoming and outgoing messages to the server cannot be correlated by message contents. Additionally, because of encryption at the SMP layer, impersonating the server is not sufficient to pass (and therefore correlate) a message from a sender to recipient - the only attack possible is to drop the messages. Only by additionally *compromising* the server can one pass and correlate messages.
XXX It's important to note in one's head that the SMP protocol does not do server authentication. Instead we rely upon the fact that an attacker who tricks the transport protocol into authenticating the server incorrectly cannot do anything with the SMP messages except drop them.
It's important to note that the SMP protocol does not do server authentication. Instead we rely upon the fact that an attacker who tricks the transport protocol into authenticating the server incorrectly cannot do anything with the SMP messages except drop them.
After the connection is established, the client sends blocks of a fixed size 16Kb, and the server replies with the blocks of the same size to reduce metadata observable to a network adversary. The protocol has been designed to make traffic correlation attacks difficult, adapting ideas from Tor, remailers, and more general onion and mix networks. It does not try to replace Tor though - SimpleX servers can be deployed as onion services and SimpleX clients can communicate with servers over Tor to further improve participants privacy.
By using fixed-size blocks, oversized for the expected content, the vast majority of traffic is uniform in nature. When enough traffic is transiting a server simultaneously, the server acts a (very) low-latency mix node. We can't rely on this behavior to make a security claim, but we have engineered to take advantage of it when we can. As mentioned, this holds true even if the transport connection is compromised.
By using fixed-size blocks, oversized for the expected content, the vast majority of traffic is uniform in nature. When enough traffic is transiting a server simultaneously, the server acts as a (very) low-latency mix node. We can't rely on this behavior to make a security claim, but we have engineered to take advantage of it when we can. As mentioned, this holds true even if the transport connection is compromised.
The protocol does not protect against attacks targeted at particular users with known identities - e.g., if the attacker wants to prove that two known users are communicating, they can achieve it. At the same time, it substantially complicates large-scale traffic correlation, making determining the real user identities much less effective.
@@ -122,7 +137,7 @@ The protocol does not protect against attacks targeted at particular users with
#### SimpleX Messaging Protocol
SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server (including IP, port, and hash of the long-lived offline key), a queue ID, and Alice's public key for her receiving queue. These introductions are similar to the PANDA key-exchange, in that if observed, the adversary can race to establish the communication channel instead of the intended participant. [0]
SMP is initialized with an in-person or out-of-band introduction message, where Alice provides Bob with details of a server (including IP, port, and hash of the long-lived offline certificate), a queue ID, and Alice's public key for her receiving queue. These introductions are similar to the PANDA key-exchange, in that if observed, the adversary can race to establish the communication channel instead of the intended participant. [0]
Because queues are uni-directional, Bob provides an identically-formatted introduction message to Alice over Alice's now-established receiving queue.
@@ -136,20 +151,24 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- Managing sets of bi-directional, redundant queues for communication partners
- Providing end-to-end encryption of messages[0]
- Providing end-to-end encryption of messages
- Rotating queues periodically with communication partners
- Noise traffic
[0] The current prototype uses RSA cryptography with ad-hoc hybrid encryption scheme, we are currently switching it to X3DH for key exchange and double ratchet protocol for E2E encryption.
#### Encryption Primitives Used
- XXX todo
- Ed448 to sign/verify commands to SMP servers (Ed25519 is also supported via client/server configuration).
- Curve25519 for DH exchange to agree:
- the shared secret between server and recipient (to encrypt message bodies - it avoids shared cipher-text in sender and recipient traffic)
- the shared secret between sender and recipient (to encrypt messages end-to-end in each queue - it avoids shared cipher-text in redundant queues).
- [NaCl crypto_box](https://nacl.cr.yp.to/box.html) encryption scheme (curve25519xsalsa20poly1305) for message body encryption between server and recipient and for E2E per-queue encryption.
- SHA256 to validate server offline certificates.
- [double ratchet](https://signal.org/docs/specifications/doubleratchet/) protocol for end-to-end message encryption between the agents:
- Curve448 keys to agree shared secrets required for double ratchet initialization (using [X3DH](https://signal.org/docs/specifications/x3dh/) key agreement with 2 ephemeral keys for each side),
- AES-GCM AEAD cipher,
- SHA512-based HKDF for key derivation.
## Threat Model
@@ -158,7 +177,7 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- A user protects their local database and key material
- The user's application is authentic, and no local malware is running
- The cryptographic primitives in use are not broken
- A user's choice of servers are not directly tied to their identity or otherwise represent distinguishing information about the user.
- A user's choice of servers is not directly tied to their identity or otherwise represents distinguishing information about the user.
#### A passive adversary able to monitor the traffic of one user
@@ -170,18 +189,17 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- determine which servers the user communicates with
- observe how much traffic is being sent, and make guesses as to its purpose XXX It occurs to me that at some point you may be able to improve SMP's traffic resistance by analyzing common traffic patterns and seeking to make them more uniform.
- observe how much traffic is being sent, and make guesses as to its purpose.
*cannot:*
- see who sends messages to the user and who the user sends the messages to
#### A passive adversary able to monitor a set of senders and recipients
*can:*
- identify who and when users are using SimpleX
- identify who and when is using SimpleX
- learn which SimpleX Messaging Protocol servers are used as receive queues for which users
@@ -205,7 +223,7 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- perform queue correlation (matching multiple queues to a single user) via either a re-used transport connection, user's IP Address, or connection timing regularities
- learn a user's IP address, track them through other IP addresses they use to access to same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
- learn a user's IP address, track them through other IP addresses they use to access the same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
- drop all future messages inserted into a queue, detectable only over other, redundant queues
@@ -221,11 +239,10 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- learn the contents of messages
- distinguish noise messages from regular messages except via timing regularities XXX the algorithm for noise traffic will undoubtedly make this attack pretty strong
- distinguish noise messages from regular messages except via timing regularities
- compromise the user's end-to-end encryption with an active attack
#### An attacker who obtained Alice's (decrypted) chat database
*can:*
@@ -238,15 +255,15 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- prevent Alice from receiving all new messages sent to her - either surreptitiously by emptying the queues regularly or overtly by deleting them
- send messages from the user to their contacts, detectable when recipients will detect it as soon as the user sends the next message, because the previous message hash won’t match (and potentially won’t be able to decrypt them in case they don’t keep the previous ratchet keys).
- send messages from the user to their contacts; recipients will detect it as soon as the user sends the next message, because the previous message hash won’t match (and potentially won’t be able to decrypt them in case they don’t keep the previous ratchet keys).
*cannot:*
- impersonate a sender and send messages to the user whose database was stolen. Doing so requires also compromising the server (to place the message in the queue) or the user's device at a subsequent time (to place the message in the database).
- impersonate a sender and send messages to the user whose database was stolen. Doing so requires also compromising the server (to place the message in the queue, that is possible until the Double-Ratchet advances forward) or the user's device at a subsequent time (to place the message in the database).
- undetectably communicate at the same time as Alice with her contacts. Doing so would result in the contact getting different messages with repeated keys
- undetectably communicate at the same time as Alice with her contacts. Doing so would result in the contact getting different messages with repeated IDs.
- undetectably monitor message queues in realtime without alerting the user they are doing so, as a second subscription request unsubcribes the first and notifies the second
- undetectably monitor message queues in realtime without alerting the user they are doing so, as a second subscription request unsubscribes the first and notifies the second.
#### A user’s contact
@@ -287,3 +304,10 @@ SimpleX agents provide higher-level operations compared to SimpleX Clients, who
- send messages to a user who they are not connected with
- enumerate queues on a SimpleX server
## Acknowledgements
Efim Poberezkin contributed to the design and implementation of SimpleX Messaging Protocol and SimpleX Agent Protocol in 2019-2021.
Adam Langley's [Pond](https://github.com/agl/pond) inspired some of the recent improvements and the structure of this document.

291
protocol/overview.md
View File

@@ -1,291 +0,0 @@
# SimpleX: messaging and application network
## Table of contents
- [SimpleX objectives](#simplex-objectives)
- [SimpleX network](#simplex-network)
- [Threat model](#threat-model)
## SimpleX objectives
1. Provide messaging infrastructure for chat and other distributed applications, both applications other than chat and applications built on top of chat. This infrastructure needs to have the following qualities:
ABOVE IS CORRECTED BASED ON THE COMMENT: It's unclear to me if you mean that the _chat_ is the infrastructure that applications build on. i.e. the chat layer (which is built on the agent layer (i think?) which is built on SimpleX Messaging queues) itself is intended to be built upon and used by applications like e.g. WhatsApp.
- Security against passive and active (man-in-the-middle) attacks: the parties should have reliable end-to-end encryption and be able to identify the presence of the active attacker who modified, deleted or added messages.
- Privacy: protect against traffic correlation attacks to determine the contacts that the users communicate with.
ABOVE IS CORRECTED BASED ON THE COMMENT: If you're going to use a word like 'hard' it's a bit of a red flag because typically people have very different definitions of 'hard'. And usually the protocol designer's version is much weaker than the critic's. Similarly "to some extent compensate". This type of content really makes section better suited for a different location. Maybe a different document, maybe after the threat model.
- Reliability: the messages should be delivered even if some participating network servers or receiving clients fail, with “at least once” delivery guarantee.
- Integrity: the messages sent in one direction are ordered in a way that sender and recipient agree on; the recipient can detect when a message was removed or changed.
- Asynchronous delivery: it should not be required that both communicating parties (client devices, services or applications) are online for reliable message delivery.
- Low latency: the delay introduced by the network should not be higher than 100ms-1s in addition to the underlying TCP network latency.
2. Provide better communication privacy, in particular meta-data privacy (who talks to whom and when), and security, in particular security against active attacks, than the alternative instant messaging solutions.
3. Balance user experience with privacy requirements, prioritizing experience of mobile device users.
## SimpleX network
### Overview
SimpleX network provides asynchronous messaging infrastructure that aims to deliver on the above objectives and to avoid the disadvantages of the alternative solutions.
The key differences of SimpleX network are:
- participants do not need to have globally unique addresses to communicate, instead they use redundant unidirectional (simplex) messaging queues, with a separate set of queues for each contact.
- connection requests are passed out-of-band, non-optionally protecting key exchange against man-in-the-middle attack.
- message queues provided by network servers are used by the clients to create more complex communication scenarios, such as duplex one-to-one communication, transmitting files, group communication without central servers and content/communication channels (requiring a separate type of server to host them, which is out of scope of this document).
- servers do not store any user information (no user profiles, contacts or messages, once they are delivered).
ABOVE IS CORRECTED BASED ON THE COMMENT: This isn't really appropriate for this document. Firstly, there's nothing technically limiting the server from _not_ using memory persistence. Secondly, even if you corrected it to "by default" - the point of this document isn't to describe how things works when everyone behaves honestly, it's to describe what the capabilities/limitations of an attacker are when they behave maliciously.
- users can change server provider(s) without losing their communication contacts, simply by changing the configuration on which servers the new queues are created.
SimpleX network has design similar to P2P networks, but unlike most P2P networks it consists of clients and servers, without dependency on any centralized component. Servers provide anonymous unidirectional message queues in order to:
- continuously accept messages for the recipients, even when they are offline.
- provide recipient anonymity, as the messaging queues do not identify the users, and different addresses of the same queue are used for senders and recipients to provide additional protection against server traffic correlation, in case transport connections are compromised.
COMMENT TO THE ABOVE: Editorially, this paragraph is not helpful. At this point in the document we haven't really described enough to figure out what all of this means. "recipient anonymity", "users", "addresses", "server traffic", "transport connections" - all of these are kind of ambiguous at this point in the document.
Coincidentally, SimpleX network reminds [Pond messenger](https://github.com/agl/pond) design, the main differences are:
- Clients can receive messages via multiple servers (in Pond users use one home server and it serves as a user permanent address),
- Clients do not need to poll servers to receive messages, the messages from subscribed queues are delivered via an open transport connection as they are received by the servers, resulting in low latency of message delivery.
The protocol has been designed to make traffic correlation attacks difficult, adapting ideas from Tor, remailers, and more general onion and mix networks. It does not try to replace Tor though, and Tor can be used both as a transport layer by the clients, and the servers can deployed as Tor hidden services to further improve participants privacy.
By using fixed-size blocks, oversized for the expected content, the vast majority of traffic is uniform in nature. Traffic correlation is an attack that can be improved with machine learning models, trading false positives or false negatives. When enough traffic is transiting a server simultaneously, the server acts a (very) low-latency mix node. We can't rely on this behavior to make a security claim, but we have engineered to take advantage of it when we can. This holds true even if the transport connection (TLS generally) is compromised as the incoming and outgoing traffic has no identifiers or cipher-text in common.
The protocol does not protect against attacks targeted at particular users with known identities - e.g., if the attacker wants to prove that two known users are communicating, they can achieve it. At the same time, it substantially complicates large-scale traffic correlation, making determining the real user identities much less effective than with any alternative solution known to us.
### SimpleX servers
Clients communicate with servers (but not with other clients) using SimpleX Messaging Protocol (SMP) running over some transport protocol that provides server authentication, confidentiality with forward secrecy, integrity and transport channel binding (to prevent SMP commands replay).
Users can use multiple servers. They choose the servers they use to receive the messages through, and they communicate with the servers chosen by the recipients to send messages.
It is assumed that users have some degree of trust to the servers, for one of the following reasons:
- They deploy and control the servers themselves from the available open-source code. The advantage of self-deployed servers is that users have full control of server information and activity, but the downside is that it is easier to correlate incoming and outgoing messages by observing server traffic, assuming small number of messages sent via user-hosted servers and irregular communication time. It can be mitigated by:
- sending noise traffic.
- future protocol versions can add configurable per queue message delivery delays (compromising on one of the design objectives of low latency).
- using SMP servers via an onion routing or mix network.
- They use servers from the trusted commercial providers. The more clients the provider has, the more ineffective it becomes to use the meta-data about the communication times to correlate the sent and received traffic of the server. Even if transport confidentiality is compromised, there is no additional meta-data to correlate by, as the incoming and outgoing traffic is uniform in nature, having fixed size blocks and no identifiers or cipher-text in common.
- To some extent, users trust their contacts and the servers they chose that the users send messages to. The client applications could further improve user trust to the servers chosen by their contacts by supporting either the list of servers that are “allowed to send to” or “prohibited to send to” (e.g., known trusted or compromised servers, certain IP ranges, server geographical locations etc.).
The servers can maliciously or for any other reason record queues and messages (even though encrypted) sent via the same transport connection to gain a partial knowledge of the user’s contacts graph and other meta-data. User clients can mitigate it by using some overlay network that protects the privacy of TCP connections, e.g., Tor, and by sending noise traffic between the end users.
ABOVE IS CORRECTED BASED ON THE COMMENT: This risk is not unique to volunteers and indeed would not be a difficult request to make in a pen register from law enforcement.
The servers authorize users to access (send/receive/etc.) their message queues via a digital signature of transmissions using a unique key pair different for each queue sender and recipient, so no information that is required for the server to authorize users allows to aggregate user communications across multiple queues.
### Transport
SimpleX network does not rely on transport or overlay network for server or client authentication. SMP protocol itself must provide integrity, forward secure confidentiality of communicating parties and mutual authentication even if transport protocol (but not the server) is compromised by the active attacker.
To protect against MITM attack on the transport, the clients should verify server self-signed certificate during TLS handshake by validating its pre-shared hash of the certificate in the server address (either as part of client configuration or passed in SMP connection request).
Clients use TLS1.3 protocol to connect to the server, restricting supported cryptographic protocols as defined in SimpleX Messaging Protocol.
After TCP transport connection is established, and the server is authenticated, the client sends blocks of a fixed size 16Kb, and the server replies with the blocks of the same size. When the actual message is smaller, it should be padded before encryption, and if it is larger, it can be split to chunks by the client application. The first blocks from the client and the server should include protocol version so that the party with the higher version can confirm compatibility and the transport channel identifier as described in SMP protocol.
Client can terminate the server transport connection without losing any messages – removal of the message from the server and the delivery of the next message happens when the client acknowledges the message reception (normally, after it is persisted in the client’s database).
Depending on the privacy requirements of the users, the client can use a separate transport connection per queue, or receive messages from multiple queues via a single transport connection, for efficiency. In our implementations this configuration will be available to the end users. At the same time, we will aim to minimize available user choices that affect security and privacy, making all options as clear as possible, and present them under a single "privacy slider", analogous to Tor's security slider.
### Server implementation
- does not store user access logs.
- does not store messages after the client has received them.
- permanently removes queues after they are deleted by the users
- only stores messages in transit in server operating memory; as clients are expected to use multiple servers to deliver each message, the message loss in one of the servers is acceptable.
AMENDED BASED ON THE COMMENT: Saying it's acceptable because they "can use" seems like a disconnect... If you're going to go so far as to say 'it's fine don't worry about it' then I would say you should really "expect" clients to use multiple servers to deliver a message.
### SimpleX clients and agents
Clients are assumed to be running on the trusted devices and can use the locally encrypted storage for messages, contacts, groups and other resources.
SimpleX clients implementing application-level protocols communicate with SimpleX servers via agents. SimpleX agents can be accessed in one of the following ways:
- via TCP network using trusted network connection or an overlay transport network.
- via local port (when the agent runs on the same device as a separate process).
- via agent library, when the agent logic is included directly into the client application.
The last option is the most secure, as it reduces the number of attack vectors in comparison with other options. The current implementation of SimpleX Chat uses this approach.
SimpleX agents provide the following operations:
- Creating and managing bi-directional (duplex) client connections and delivering messages via redundant groups of SimpleX queues.
- Exchanging keys and providing end-to-end encryption. The current prototype uses RSA cryptography with ad-hoc hybrid encryption scheme, we are currently switching it to X3DH for key exchange and double ratchet protocol for E2E encryption.
Communication between the client and the agent and the communication between the agents (via end-to-end encrypted messages delivered via SMP protocol) is described by SimpleX Agent Protocol.
Bi-directional client connections consist of multiple “send” and multiple “receive” queues (for redundancy) that agents use to send and receive messages; each queue should be used for limited amount of time, the rotation of queues is negotiated using SimpleX Agent Protocol.
There are two ways that SimpleX network users can establish the connection:
- Users communicate the initial connection invitation out-of-band, via link or via QR code. This out-of-band communication is assumed secure against active attacks and insecure against passive attacks. Once the connection is established that users are assumed to have confirmed out-of-band, the connection can no longer be compromised even if out-of-band invitation was obtained by the attacker. This out-of-band invitation does not contain any personal information, only the address of the queue and public key for the key exchange for end-to-end encryption.
- Users can create a “contact queue(s)” on SMP servers that would be used to receive connection requests. The important distinction with commonly used addressing systems is that this queue is only used to pass the connection request and not for subsequent messages. So, while it is possible to spam users who created such contact queues with connection requests, they can be removed without disrupting the communication with the existing contacts.
The reply queue addresses and the key exchange for the reply queues is negotiated via the direct queue.
### Message encryption
Messages are encrypted end-to-end using double ratchet protocol. Once the sending client deletes messages it won’t be able to decrypt them again. While messages are numbered within the queue, this only reveals to the servers how messages have been exchanged in a given queue that has a limited lifetime, so the total number of messages exchanged between contacts is not revealed.
The next queue to use is negotiated between agents in encrypted messages, and in most cases, it will be on another server (unless the client is configured to use one server, which is not recommended).
### Client storage
It is assumed that the client device and the storage is trusted, but clients can implement storage encryption using a user-provided passphrase.
## Threat model
### Assumptions
User protects their information and keys.
SimpleX Chat software is authentic.
User device is not compromised, excluding the scenarios below where it is explicitly stated it is compromised.
Used cryptographic primitives are not compromised.
The used servers are not directly tied to someone's identity or have and distinguishing information about the users.
### SimpleX Messaging Protocol server
**can:**
- learn a user's IP address, track them through other IP addresses they use to access to same queue, and infer information (e.g. employer) based on the IP addresses, as long as Tor is not used.
- learn when a queue recipient or sender is online via transmission times.
- lie about the state of a queue to the recipient and/or to the sender (e.g. suspended or deleted when it is not).
- prevent message delivery.
- correlate multiple queues to a single user in case they are accessed via the same transport connection or from the same IP address.
- correlate multiple queues to a single user based on the time they are accessed.
- know how many messages is sent via the queue, clients can mitigate it with noise traffic.
- add, drop, duplicate or corrupt messages, but it will be detected by the client on SimpleX Agent Protocol level. Using multiple servers to deliver each message mitigates the loss of messages.
**cannot:**
- decrypt messages
- compromise e2e encryption with MITM attack (as server is only used to pass one of two keys in DH exchange, the first key is passed out-of-band)
### A passive adversary able to monitor a set of senders and recipients
**can:**
- learn who is using SimpleX Chat.
- learn when messages are sent and received.
- learn which SimpleX Messaging Protocol servers are used.
- in case of low traffic on the servers, correlate senders and recipients within the monitored set by the time messages sent and received.
- observe the approximate size of the files transmitted – to O(log log M) of file size precision.
**cannot, even in case of compromised transport protocol:**
- correlate senders and recipients by the content of messages (as different queue IDs are used for senders and recipients, with additional encryption layer in the delivered messages).
### A passive adversary able to monitor the traffic of one user
**can:**
- observe when a user is using SimpleX Chat.
- learn when messages are sent and received.
- block SimpleX Chat traffic.
- determine which servers the user communicates with.
- observe the approximate size of files transmissions and receptions.
**cannot:**
- see who sends messages to the user and who the user sends the messages to
### An attacker who obtained user’s decrypted chat database
**can:**
- see the history of all messages
- see shared profiles of contacts and groups
- receive new user messages, but the user will be alerted that an unknown device is connected to their message queues, as long as they are online at the same time, as message queues only allow one active subscription, and when any client subscribes to the queue, currently subscribed client is unsubscribed and notified.
- remove user messages from the queue, but the user will detect it when they receive the next message, as the number and the hash of the previous message won’t match.
- remove user messages from the queue continuously, preventing a user from receiving any messages and detecting that some messages are missing, but the user would detect it by the absence of status updates from their contacts that can be regularly sent even when no user-created messages are sent by their contacts.
- delete user’s message queues, so the contacts won’t be able to send messages.
- send messages from the user to their contacts, but the recipients will detect it as soon as the user sends the next message, because the previous message hash won’t match (and potentially won’t be able to decrypt them in case they don’t keep the previous ratchet keys).
**cannot:**
- impersonate a sender and send messages to the user whose database was stolen without also compromising the server (to place the message in the queue) or the user's device at a subsequent time (to place the message in the database).
### A user’s contact
**can:**
- spam the user with messages.
- forever retain messages from the user.
**cannot:**
- cryptographically prove to a third-party that a message came from a user (assuming a user’s device is not seized)
- prove that two contacts they have is the same user. Implementation should take care to only use correct cryptographic keys associated with a given queue (or connection, for E2E keys) for this claim to hold true.
- two contacts cannot confirm if they are communicating with the same user.
### An attacker with Internet access
**can:**
- DoS SimpleX messaging servers.
- spam the user who created a “contact queue” (queue for accepting connection requests) by sending multiple connection requests.
**cannot:**
- send messages to the user who they are not connected with.