Twake E2EE works with a concept of 'channel keys'. It means that to write or read messages you need to have the encryption key of the message main context.

With Twake the main contexts are 'threads', any message is in a thread and so is encoded with the thread public key. When the thread is shared with channels and users, each users will receive directly or indirectly the thread private key encrypted with the user public key. Doing so, only the end user can get the thread private key because he's the only one to have access to his own private key.

Let's define three items: users, nodes, messages. Each message is in one and only one node. Each node give access to one or more users and nodes. Here is a valid topography example:

Keys

Nodes and users both have two RSA keys: a public key and a private key.

Only the public key is directly stored in database.

Private keys need to be computed by each other nodes and users when necessary.

We will discuss later how we can retrieve a private key in order to read a message.

Write a message

This is the simple workflow, every messages are simply written with the public key of its node. In the previous schema it means when any user want to create a message in Node B, then they must encrypt it using the Node B Public Key. This key is publicly available alongs the Node B entity (in the context of Twake, it means the public key is available alongs the thread entity).

That as simple as that.

Read a message

Because we use RSA keys, the message written by User A cannot be read anymore using the public key of Node B. We need to know the private key of this same Node B.

Propagate the private key

Let go back to when we sent the first message in Node B. At this time we know the public and private key: because we need to generate them before to push the message.

When sending a message there is some things to do if the user already knows the private key:

• Get the list of users and nodes awaiting access to the private key, we get a list of this format: [{user_id: "uuid", public_key: "string"}, {...}]
• Encrypt the private key of the message parent node (Node B in schema) with all public_keys in the list and send back the result to backend.
• The backend will store both public keys and encrypted private keys of nodes and users with the Node B entity.

Read the message

To read the message as User A, it needs to get the Node B private key already accessible but encrypted with User A public key. User A knows its private key so it can decrypt the Node B private key and then decrypt the message.