From 078bc91930648e919434a0a5fddbf1c2722ce0e7 Mon Sep 17 00:00:00 2001 From: Evgeny Poberezkin Date: Mon, 23 Dec 2019 23:18:17 +0000 Subject: [PATCH] docs: simplex connection --- diagrams/simplex1.mmd | 8 + diagrams/simplex1.svg | 498 ++++++++++++++++++++++++++++++++++++++++++ diagrams/simplex2.mmd | 26 +++ diagrams/simplex2.svg | 498 ++++++++++++++++++++++++++++++++++++++++++ readme.md | 44 ++++ 5 files changed, 1074 insertions(+) create mode 100644 diagrams/simplex1.mmd create mode 100644 diagrams/simplex1.svg create mode 100644 diagrams/simplex2.mmd create mode 100644 diagrams/simplex2.svg diff --git a/diagrams/simplex1.mmd b/diagrams/simplex1.mmd new file mode 100644 index 000000000..d4e9ad3d5 --- /dev/null +++ b/diagrams/simplex1.mmd @@ -0,0 +1,8 @@ +graph LR + S("sender (key 1)") --> C + C --> R("receiver (key 2)") + R --> C + subgraph connection + C{{"verify sender (1) ---> pubsub <---> verify receiver (2)"}} + end + \ No newline at end of file diff --git a/diagrams/simplex1.svg b/diagrams/simplex1.svg new file mode 100644 index 000000000..3f5cd1f35 --- /dev/null +++ b/diagrams/simplex1.svg @@ -0,0 +1,498 @@ +
connection
verify sender (1) ---> pubsub <---> verify receiver (2)
sender (key 1)
receiver (key 2)
\ No newline at end of file diff --git a/diagrams/simplex2.mmd b/diagrams/simplex2.mmd new file mode 100644 index 000000000..47842dab4 --- /dev/null +++ b/diagrams/simplex2.mmd @@ -0,0 +1,26 @@ +sequenceDiagram + participant S as sender (client) + participant A as API + participant Q as pubsub + participant P as publisher + participant R as receiver (client) + note over R: sign subscription (1) + R ->> P: subscribe to messages + note over P: verify subscriber (1) + alt subscriber verified? + P -->> Q: subscribe + else + P ->> R: reject subscription + end + note over S: sign message (2) + S ->> A: send message + note over A: verify sender (2) + alt sender verified? + A -->> Q: queue message + activate Q + else + A ->> S: reject message + end + Q -->> P: take message + deactivate Q + P ->> R: deliver message diff --git a/diagrams/simplex2.svg b/diagrams/simplex2.svg new file mode 100644 index 000000000..55af1592d --- /dev/null +++ b/diagrams/simplex2.svg @@ -0,0 +1,498 @@ +sender (client)APIpubsubpublisherreceiver (client)sign subscription (1)subscribe to messagesverify subscriber (1)subscribereject subscriptionalt[ subscriber verified? ]sign message (2)send messageverify sender (2)queue messagereject messagealt[ sender verified? ]take messagedeliver messagesender (client)APIpubsubpublisherreceiver (client) \ No newline at end of file diff --git a/readme.md b/readme.md index 535ec94b9..de069df67 100644 --- a/readme.md +++ b/readme.md @@ -13,6 +13,20 @@ The problems of existing chat solutions this system intends to solve: - Visiblity of user profile information to chat system and other chat users. +## Requirements + +- User profile is only visible to the proifle connections, but not to the chat network +- User profile is not stored on the server. +- Profile connections are not stored on the server. +- It should not be possible to construct the list of user connections by analysing server database or any logs. +- It should not be possible, other than by compromising the client, to send messages from another user profile. +- It should not be possible, other than by compromising all servers the user is connected to, to prevent message delivery to a user. +- All participants of the conversation should be able to: + - prove that the received messages were actually sent by another party. + - prove that the sent messages were received by another party. + - prove sent/received time/delivery order - with the solution below only timestamp of another party can be proven, not the actual time. + + ## Solution - No phone numbers, user names and no DNS are used to identify to users (chat servers may choose to be accessible via DNS, but it is not required) @@ -82,6 +96,36 @@ Client apps should provide the following: Prepared with [mermaid-js](https://mermaid-js.github.io/mermaid-live-editor) +## Client-server architecture + +To allow sending the message when receiver client is not available, and to allow receiving the messages when the sender client is not available, the system relies on the client-server architecture with multiple servers. + +The communication always happens through the servers that the recepient defines, that manages simplex connections (see below). + +Servers store messages only until delivered to the recepients, they do not store any message history or delivery log. + +Servers do not have visibility of the message senders and message types, they only have visibility of connection address that is equal to the hash of public key used to encrypt messages sent into the connection (hash of receiver's public key). + + +## Simplex connection - the main unit of network design + +The network consists of multiple "simplex (non-duplex) connections". Access to each connection is controlled with unique (not shared with other connections) assymetric key pairs, separate for sender and the receiver. The sender and the receiver have private keys, and the server has associated public keys to verify participants. + +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. + +**Simplified simplex connection diagram:** + +![Simplex connection diagram](/diagrams/simplex1.svg) + +Connection is defined by sender's key 1 that is used to verify sender's messages and by receiver's key 2 that is used to verify subscription to messages (or requests to receive messages). + +**Simplex connection operation:** + +![Simplex connection operations](/diagrams/simplex2.svg) + +Sequence diagram does not show E2EE - connection itself knows nothing about encryption between sender and receiver. + + ### Connections between user profiles The system uses connections between user profiles (no information identifying users is stored on the servers) to send and to receive messages. Each connection is one-directional, from sender to recepient, without any correlation between connections and user profiles, and between 2 connections used to send and to receive messages to/from the same participants.