residual/rechat
Watch
3
0
Fork
You've already forked rechat
 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Design: encrypted groups (Encryption V1) #10

New issue
Open
opened 2026-10-17 18:41:39 +00:00 by muse-lantern · 0 comments
muse-lantern commented 2026-10-17 18:41:39 +00:00
Member
Copy link

proj-rechat-encryption

End-to-end encrypted groups. Builds on the key auth model in #6.

V1: Shared Group Key

  • Each encrypted group generates a unique symmetric key on creation
  • Key distributed to members on join (encrypted with each member's public key)
  • Messages encrypted with group key — one encryption per message, all members decrypt
  • Membership change → key rotation: on leave/kick, generate new key, redistribute to remaining members. Ex-members hold the old key but can't read new messages.
  • key_registered flag required to join (no keys = can't participate)

Future: Hybrid (MLS-lite)

  • Group has rotating symmetric message key for speed
  • Message key distributed per-recipient (encrypted with each member's pubkey)
  • Membership change → rotate message key, redistribute
  • Best of both: fast symmetric crypto + per-user revocation

Alternative Considered: Per-Recipient

  • Each message encrypted N times (N = member count) with each member's public key
  • True forward secrecy but O(N) fan-out per message. Rejected for V1 due to scaling cost.

Notes

  • Standard IRC clients cannot participate in encrypted groups (no crypto support). Opt-in per group — forces official/custom client, which is acceptable.
  • Keypairs already exist on both sides from the auth challenge flow (#6), so no additional key exchange needed.
  • Server stores only ciphertext for encrypted groups. Cannot read message contents.
proj-rechat-encryption End-to-end encrypted groups. Builds on the key auth model in #6. ## V1: Shared Group Key - Each encrypted group generates a unique symmetric key on creation - Key distributed to members on join (encrypted with each member's public key) - Messages encrypted with group key — one encryption per message, all members decrypt - **Membership change → key rotation:** on leave/kick, generate new key, redistribute to remaining members. Ex-members hold the old key but can't read new messages. - `key_registered` flag required to join (no keys = can't participate) ## Future: Hybrid (MLS-lite) - Group has rotating symmetric message key for speed - Message key distributed per-recipient (encrypted with each member's pubkey) - Membership change → rotate message key, redistribute - Best of both: fast symmetric crypto + per-user revocation ## Alternative Considered: Per-Recipient - Each message encrypted N times (N = member count) with each member's public key - True forward secrecy but O(N) fan-out per message. Rejected for V1 due to scaling cost. ## Notes - Standard IRC clients cannot participate in encrypted groups (no crypto support). Opt-in per group — forces official/custom client, which is acceptable. - Keypairs already exist on both sides from the auth challenge flow (#6), so no additional key exchange needed. - Server stores only ciphertext for encrypted groups. Cannot read message contents.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
residual/rechat#10
No description provided.