60dc128c63
* link pods to notification service * push encryption poc * decrypt room key poc * read user key from mmkv and cast into a pkcs * push decrypt poc (iOS) * expose needed watermelon methods * watermelon -> database * indent & simple-crypto update * string extensions * storage * toBase64 -> toData * remove a forced unwrap * remove unused import * database driver * improvement * folder structure & watermelon bridge * more improvement stuff * watermelon -> database * reuse database instance * improvement * database fix: bypass watermelon cache * some code improvements * encryption instances * start api stuff * network layer * improve notification service * improve folder structure * watermelon patch * retry fetch logic * rocketchat class * fix try to decrypt without a roomKey * fallback to original content that is translated * some fixes to rocketchat logic * merge develop * remove unnecessary extension * [CHORE] Improve reply notification code (iOS) * undo sign changes * remove mocked value * import direct from library * send message request * reply notification with encrypted message working properly * revert apple sign * fix api onerror * trick to display sender name on group notifications * revert data.host change * fix some multithread issues * use sendername sent by server * small improvement * Bump crypto lib * Update ios/NotificationService/NotificationService.swift * add experimental string * remove trailing slash * remove trailing slash on reply * fix decrypt messages Co-authored-by: Diego Mello <diegolmello@gmail.com> |
||
|---|---|---|
| .. | ||
| README.md | ||
| constants.js | ||
| encryption.js | ||
| index.js | ||
| room.js | ||
| utils.js | ||
README.md
Rocket.Chat Mobile
E2E Encryption
Note: This feature is currently in beta. Uploads will not be encrypted in this version. You can check this documentation for further information about the web client.
How it works
- Each user has a public and private key (asymmetric cryptography).
- The user private key is stored encrypted on the server and it can be decrypted on clients only using the user E2E encryption password.
- A room key is generated using the public key of each room member (symmetric cryptography).
- Users can decrypt the room key using their private key.
- Each room has a unique identifier which make users able to request a room key.
- The room unique identifier is called
e2eKeyIdand it's a property of theroomcollection. - The room key is called
E2EKeyand it's a property of thesubscriptioncollection. - After the room key is decrypted, the user is able to encrypt and decrypt messages of the room.
User keys
- If the user doesn't have keys neither locally nor on the server, we create and encrypt them using a random password. These encrypted keys are sent to the server (so other clients can fetch) and saved locally.
- If the user have keys stored on server, but doesn't have them stored locally, we fetch them from the server and request a password to decrypt the keys.
Room keys
- If the room has a
E2EKey, we decrypt it using the user key. - If the room doesn't have a
E2EKey, but has ae2eKeyId, we emit an event on stream-notify-room-users sending theroomIdand thee2eKeyIdrequesting theE2EKeyfrom any online room member. - If the room have none of them, we create new ones and send them back to the server.