Technical Architecture
Last updated
Last updated
In order to decrease the number of interactions a user does with their Metamask wallet when encrypting their messages, users generate their own unique keys for encryption creating a user identity. To ensure the privacy and security of our user’s unencrypted identity private key, we only store them in the users private session and never in our database.
The diagram above shows the process of generating the user’s unique identity. When a user signs in to the Motherboard app for the first time, a user is asked for 2 Metamask interactions. The first one is signing a message to prove wallet ownership before proceeding to the onboarding process. Before a user can fully submit their application, a user has to sign another message that allows them to generate their unique user identity. We only save their unencrypted private key in their own session storage and their generated public identity address is being saved into our secured database. Users will need to decrypt their private key and save it to the session storage every time they log in to the chat app.
For repeat users, once they login to their selected DAO, verify their wallet ownership and proceed to the chat app, they will be prompted with a Decrypt Patch Key button where they will be asked to sign a message using Metamask in order to generate their unique user identity key. After a user has fetched their unique user identity key and stored it in their own session storage they will now be able to retrieve their encrypted conversations and send messages.
Once a user has signed a message with their wallet and retrieved their unique user identity, they will be able to access the chat app allowing them to create direct or group conversation. Our system uses the general asymmetric encryption process wherein there is a usage of one’s public key and one’s private key to encrypt and decrypt a message and protect it from unauthorized access or use. When a user sends a message, we are actually sending two encrypted messages. The first one is encrypted using the sender’s identity public key(your own identity public key) and the second one is encrypted using the receiver’s identity public key that we pulled from our database. Our system automatically encrypts the messages that return an encrypted string ciphered from the encrypted object with hex-strings which is essential in securing short messages. In order to receive and read the encrypted messages, our system uses the user’s private key that is stored on their own session storage. We first verify the sender using the signature generated during the encryption process and then start decrypting the message for the user.
The group chat encryption involves both the asymmetric and symmetric encryption processes. The asymmetric encryption makes use of a user’s public key and private key for encryption while the symmetric encryption encrypts using symmetric and shares the key with all the participants of the group chat.
In the group chat encryption, our system is securing the messages using the symmetric key to encrypt all the messages and an asymmetric algorithm to encrypt the symmetric key before it is stored in the database.
The user will also be asked to complete the same Metamask interaction which is signing a message to get their user identity private key into their own session storages. The key difference of the group chat with the single chat is that after a user has generated their identity private key into their session storage, the user will first decrypt the symmetric key of the current group chat before they can decrypt their group chat messages with their own copy of the decrypted symmetric key. To make sure we protect the privacy and security of the users’ group chat, we will never store a decrypted symmetric key in the database and it will only live in a state context.
