We’re building Worklist, a collaborative task manager where operators can’t read user data. The goal is zero‑knowledge by default while still supporting teams.
Security highlights:
- OPAQUE for auth: password never leaves the device; server stores only OPAQUE files.
- Client‑side encryption with per‑user data key and per‑work‑list keys; keys are wrapped so password changes don’t require re‑encrypting everything.
- API validates integrity with per‑membership HMAC binding keys + schema commitments, without decrypting payloads.
- Invite‑key transparency log (Merkle proofs) to prevent silent key swapping during invites.
- Attachments are encrypted client‑side before upload.
Tradeoffs: no password recovery, encrypted fields can’t be server‑searched, only minimal metadata stays plaintext.
Looking for feedback on the crypto model and threat‑model gaps.
Security highlights:
- OPAQUE for auth: password never leaves the device; server stores only OPAQUE files.
- Client‑side encryption with per‑user data key and per‑work‑list keys; keys are wrapped so password changes don’t require re‑encrypting everything.
- API validates integrity with per‑membership HMAC binding keys + schema commitments, without decrypting payloads.
- Invite‑key transparency log (Merkle proofs) to prevent silent key swapping during invites.
- Attachments are encrypted client‑side before upload.
Tradeoffs: no password recovery, encrypted fields can’t be server‑searched, only minimal metadata stays plaintext.
Looking for feedback on the crypto model and threat‑model gaps.