Keystore per conversation

[dariusc93]

While direct messaging works fine as is, group messaging does not scale all as it was expected to be. This is primarily due to how a single message is encrypted per recipient in a conversation, which while for 3 to 5 recipients may be fine, large numbers of members (eg 10+ to 50+) may not scale well, which would increase cpu processing time, memory usage as well as an increase in network usage due to how large the payload would be. A proposal here would be to go back to the original idea from several months where a conversation would have its own keystore which would store the keys of recipients generated for that conversation.

Thought Process (Simplified):

Concept A - Unique User Key Per Conversation (Group Chat, Key Push)

Summary

Each user would supply a unique private key to the conversation that would allow another user who is decrypt their messages. Keys supplied are automatically pushed out to each user upon being apart of the conversation or any changes in the recipient list, if there is an implementation to change keys around.

Conversation Creation

• A creates a conversation for B, C, and D. A generates a private key and stores it into a keystore assigned with the conversation id
• An event is transmitted over to B, C, and D, with A generated private key, along with the list of recipients.
• B, C, D will see the newly creation conversation with A private key. It stores it into a keystore encrypted with their own private key, assigned with the conversation id and will generate a key, which is stored into the same keystore for the conversation as well as transmitting their key to A as well as to each other.

Sending a Message

• Recipient A sends a message through RayGun::send_message
• Key is fetched from keystore for A and encrypts message with key.
• Encrypted message is sent to all recipients in the conversation.

Receiving a Message

• Recipients receive message from A.
• Recipients fetches A key from the keystore and decrypts it and validate the message.
• When fetching the message stored, fetch the key of the sender and decrypt the message before passing it along.

Adding Recipient

• A adds recipient E, transmitting the list of recipients as well as private key from keystore, notifying current recipients of E
  • (Optional) E may also receive keystore from A for all available recipients.
• E receives event, saving the recipients as well as A private key for the conversation, and sending its generated key to to A and all recipients.
• Recipients, upon being notified about new recipient, will send their private key for the conversation to E

Removing Recipient

• A removes recipient B, notifying current recipients of B removal.
• B receives event, destroying the conversation as well as the keys stored apart of the conversation.
• Recipients received notification upon being notified about removal of B, marking B key as stale
  • (Optional) Generate new keys for new messages after receiving update and transmit keys over to current recipient

Concept B - Unique User Key Per Conversation (Group Chat, Request)

Summary

Each user would supply a unique private key to the conversation that would allow another user who is decrypt their messages. Private keys are requested upon creation of the conversation, being encrypted with a shared key between the requester and requestee, assuming they are apart of the recipient list. If a key for the message does not exist, the user can request the key for the message to be supplied.

Conversation Creation

• A creates a conversation for B, C, and D. A generates a private key and stores it into a keystore assigned with the conversation id
• An event is transmitted over to B, C, and D with the list of recipients.
• B, C, D will see the newly creation conversation, generates a key and stores it into a keystore encrypted with their own private key, assigned with the conversation id.
• A, B. C. D`. will send a request for their unique private key, which is sent to each other encrypted by each other keypair via EDCH.
  • If eg C sends a request to D, D will verify that C is apart of the conversation by validating it with the recipient list. Once confirmed, D will generate a key with C public key, which is used to encrypt D private key for the conversation and transmit it over to C, with C storing it into its keystore assigned with the conversation id.
  • (Optional) A separate service can also be used as a means of validating the recipient list of the conversation as the group will be signed by A, which would validate the authenticity of the conversation properties.

Sending a Message

• (Refer to Concept A)

Receiving a Message

• Recipients receive message from A.
• Recipients fetches A key from the keystore and decrypts it and validate the message.
• When fetching the message stored, fetch the key of the sender and decrypt the message before passing it along.
  • If A key is not in the recipient keystore for the conversation for whatever reason, the recipient can request A key for the conversation (See Concept B, Conversation Creation for requesting). If key could not be fetched, it would be ignored for the time being.
  • If a method of trust is established in the group chat (in this case, would be through the creator of the group), one can request a key for the message from another user.

Adding Recipient

• A adds recipient E, transmitting the list of recipients, notifying current recipients of E.
• E receives event, saving the recipients as well as A private key for the conversation, and sending its generated key to to A and all recipients.
• Recipients, upon being notified about new recipient, will send their private key for the conversation to E, while E request the private keys from the recipients.

Removing Recipient

• A removes recipient B, notifying current recipients of B removal.
• B receives event, destroying the conversation as well as the keys stored apart of the conversation.
• Recipients received notification upon being notified about removal of B, marking B key as stale
  • (Optional) Generate new keys for new messages after receiving update. If done, older keys from recipients will be stale, making it so it could not be used for newer messages but can be used for decrypting older messages

Concept C - Unique Key Per Conversation (Group Chat)

Summary

A group conversation that is created would contain a single private key that would be used to encrypt/decrypt messages send to the group. This key would be created by the creator of the group, and may be changed out at any time by the creator of the group.

Conversation Creation

• A creates a conversation for B, C, and D. A generates a private key and assign it to the conversation while storing it into a keystore assigned with the conversation id.
• An event is transmitted to the recipients with A generated private key, along with the list of recipients.

Sending a Message

• (Refer to Concept A)

Receiving a Message

• (Refer to Concept A)

Adding a Recipient

• A adds recipient E, transmitting the list of recipients as well as private key from keystore for the conversation, notifying current recipients of E
• E receives event, saving the recipients as well as A private key for the conversation.

Removing Recipient

• A removes recipient B, transmitting the list of recipients, notifying current recipients of B removal.
• B receives event, destroying the conversation as well as the keys stored apart of the conversation.
• Recipients received notification upon being notified about removal of B
  • (Optional) A will generate a new group key, marking the old one as stale so newer messages will be encrypted with the newer key with older messages only being able to be decrypted with the old key.

Notes:

• Keys being transmitted will be encrypted. No exceptions
• This will be blocked while options are entered and until a option is decided
• This would be one part to resolve part of Shard message list and messages in a conversation #125
• (For Concept A) Even though the keys would be unique per conversation, one should use extreme caution when sharing keys as that can open up an attack vector. Should not be a problem here since the recipients are validated by the creator of the group chat and could possibly open of a channel of validation to cross check with other users within the conversation.
• All messages will be signed by the sender regardless of encryption method used.
• Optional processes are, as the name implies, are optional. Any implementation may have to take into consideration of other factors too.
• Messages may contain a fingerprint related to the key that would allow one to determine if said key exist in the keystore.
• Will be updated to state the pros and cons of each concept