diff options
| author | metamuffin <metamuffin@disroot.org> | 2022-09-09 14:57:09 +0200 |
|---|---|---|
| committer | metamuffin <metamuffin@disroot.org> | 2022-09-09 14:57:09 +0200 |
| commit | 8e4242a02e2558d5a33b570d573774a4fb2c8278 (patch) | |
| tree | 73ef74b8d7fe2a7f7ad3652744823ca92058ac91 /readme.md | |
| parent | ae9ed91b6d841c73ccc52acecc534053c73bfb43 (diff) | |
| download | keks-meet-8e4242a02e2558d5a33b570d573774a4fb2c8278.tar keks-meet-8e4242a02e2558d5a33b570d573774a4fb2c8278.tar.bz2 keks-meet-8e4242a02e2558d5a33b570d573774a4fb2c8278.tar.zst | |
Add security paragraph
Diffstat (limited to 'readme.md')
| -rw-r--r-- | readme.md | 14 |
1 files changed, 14 insertions, 0 deletions
@@ -21,6 +21,20 @@ a web conferencing application - Prevent server from changing message sender - Have a security professional look at the code - Test some options like `camera_facing_mode` +- Signing key for each user +- Built-in storage for known keys + +## Security + +keks-meet _tries_ to be secure. However I am not a security expert. The current system works as follows: + +- The room name is set in the section of the URL (-> not sent to the server) +- The server receives a salted hash of the room name to group client of a room +- We use PBKDF2 (constant salt; 250000 iterations) to derive a 256-bit AES-GCM key +- +- All relayed message contents are encrypted with this key. + - Message recipient is visible to the server + - The server assigns user ids ## Usage |