TL;DR
Worklist uses ChaCha20-Poly1305 encryption with zero-knowledge architecture. Your data is encrypted on your device before reaching our servers using documented cryptographic primitives. We physically cannot read your tasks, even with full database access. A backup key you save can restore access once if you lose your password, without giving Worklist a decryption key. It supports GDPR data minimization and can help with HIPAA/SOC 2 technical safeguards when paired with required agreements and operational controls.
Our core principle.
Your data is encrypted on your device before it ever reaches our servers. We designed Worklist so that we — the company — cannot decrypt, read, or access your work lists, tasks, or comments. This is called zero-knowledge architecture.
What makes Worklist different.
Traditional task managers.
What competitors do
- • Store your data in plaintext on their servers
- • Can read every task, comment, and file you create
- • May scan your content for ads, AI training, or “features”
- • Vulnerable to data breaches exposing everything
Worklist (zero-knowledge).
What we do
- • Encrypts on your device before sending to our servers
- • We cannot decrypt your tasks, even if we wanted to
- • No scanning, no AI training on your private work
- • Data breaches reveal nothing meaningful — only encrypted blobs
How zero-knowledge encryption works.
You create your account.
When you register, your password never leaves your browser in plaintext. Instead:
- We use the OPAQUE PAKE protocol so our servers never see your plaintext password
- After successful registration or login, OPAQUE gives your browser a secret export key we never receive
- A random 32-byte “data key” is generated on your device
- This data key is encrypted locally with a wrapping key derived from that OPAQUE export key
- The encrypted data key is stored on our servers — but we can’t decrypt it without the client-side unlock material
- You can download a one-time backup key. It wraps the same data key in your browser, and we store only an encrypted recovery wrapper
Key point: the unlock key and data key are handled in your browser. We store only encrypted wrappers, never plaintext passwords or workspace keys.
Why store the encrypted data key?
So you can log in from any device. When you switch computers or use your phone, we send the encrypted blob, your browser unlocks it locally after secure sign-in, and you’re back in. Without storing it, you’d need to manually copy a 32-byte key between devices — terrible UX for the same security.
You create a work list or task.
Every piece of sensitive data gets encrypted on your device:
- Work list titles, descriptions, and settings
- Task titles, bodies, checklists, and comments
- Repeating task templates and schedules
- Everything is encrypted using ChaCha20-Poly1305 AEAD (a modern, audited cipher)
- Each work list has its own unique encryption key derived from your data key
Our servers store only the encrypted ciphertext — they cannot read the plaintext.
You invite team members.
When sharing work lists with teammates:
- Each member gets their own encrypted copy of the work list key
- Keys are exchanged using HPKE (Hybrid Public Key Encryption)
- Public keys are published to a transparency log (Merkle tree) to prevent man-in-the-middle attacks
- If you remove a member, the work list key is rotated and all remaining members get new encrypted copies
Our servers verify without decrypting.
You might wonder: “If the server can’t decrypt, how does it enforce permissions?”
We use HMAC proofs — cryptographic signatures that prove you have the right to access data without revealing the plaintext.
- Your browser computes an HMAC (keyed hash) of the encrypted data using a membership-specific key
- The server validates the HMAC to confirm you’re an active member
- Tampering or replaying someone else’s data fails the HMAC check
- We never decrypt the payload — just verify integrity and authorization
What our servers can (and cannot) see.
We CANNOT see
- × Work list titles or descriptions
- × Task titles, bodies, or checklists
- × Comments or discussions
- × Repeating task templates
- × Any content inside encrypted payloads
- × Your password (even hashed)
We CAN see
- ✓ User account email (for login)
- ✓ Membership relationships (who’s in which work list)
- ✓ Task status (open/closed) and priority
- ✓ Due dates and timestamps
- ✓ Delegation assignments (user IDs only)
- ✓ Metadata needed for queries (IDs, created dates)
Why some metadata is visible: Certain fields (like task status and due dates) must be stored in plaintext so our servers can efficiently filter queries, enforce due date reminders, and maintain database indexes. These fields contain no sensitive content — only operational metadata that enables the app to function.
Security guarantees.
Password-authenticated unlocking (client-only).
Your password never leaves your device in plaintext. Successful OPAQUE authentication gives your browser an export key that locally unwraps your data key. That data key is then expanded using HKDF to derive separate keys for each work list.
Server cannot decrypt payloads.
Our backend code never calls decrypt operations on user data. It only validates HMAC proofs to confirm authorization.
Key rotation on member changes.
When a member is removed or leaves, the work list key is rotated. All remaining members receive new encrypted copies, ensuring the departed member cannot decrypt future content.
Invite key transparency.
Public keys for invitations are logged in an append-only Merkle tree. Clients verify inclusion and consistency proofs, preventing the server from silently substituting keys to intercept work list data.
Backup keys stay zero-knowledge.
A backup key is generated in your browser and must be saved by you. It creates a separate encrypted wrapper for the same data key; we store only the recovery credential file and encrypted wrapper, so we cannot reset your password or read your data without that saved key.
Open source cryptography.
We use battle-tested libraries: strong-box (ChaCha20-Poly1305), OPAQUE (password authentication), HKDF (key derivation), Argon2id (OPAQUE password hardening and legacy migration), and HPKE (key exchange). All our crypto code is open source and auditable.
How we verify our security.
Our security claims are verifiable, not just marketing. Here’s how we ensure our zero-knowledge architecture works as promised:
- Open-source cryptographic code available on GitHub for public audit by security researchers
- Battle-tested libraries including ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497), and HPKE
- Cryptographic proofs (HMAC) that mathematically prevent server-side decryption
- Transparency logs (Merkle trees) to detect key substitution attacks
- Client-side unlocks from OPAQUE export keys ensure we never see your password or encryption keys
- One-time backup keys are generated and stored by the user, never by Worklist
Trade-offs of zero-knowledge.
A backup key can restore access after password loss.
Save a backup key once and keep it private. If you lose your password, that key lets you reset it and keep access to encrypted data. Because Worklist does not keep a copy, accounts without a saved backup key remain unrecoverable.
No server-side search.
Because your task content is encrypted, we can’t provide server-side full-text search across all your tasks. Search happens in your browser after decryption.
Mitigation: We optimize client-side search with indexed lookups and fast decryption to keep it performant.
Technical specifications.
| Symmetric Encryption | ChaCha20-Poly1305 AEAD (via strong-box library) |
| Data Key Unlock | OPAQUE export key + HKDF-SHA256 — derives local wrapping keys for the encrypted data key |
| Key Hierarchy | HKDF-SHA256 — derives work list and membership keys from data key |
| Password Authentication | OPAQUE PAKE (Ristretto255 curve) |
| Backup Keys | One active one-time backup key per user; generated client-side and stored by the user |
| Key Exchange (Invites) | HPKE (Hybrid Public Key Encryption) with X25519 |
| Integrity Proofs | HMAC-SHA256 |
| Serialization | CBOR (Concise Binary Object Representation) |
| Key Size | 256-bit (32 bytes) for all symmetric keys |
All cryptographic operations happen in your browser using WebCrypto APIs and audited WASM modules compiled from Rust.
Audits & transparency.
Open source crypto stack.
Our entire cryptographic implementation is open source and available on GitHub. We welcome security researchers to audit our code.
View on GitHubCompliance.
Our zero-knowledge architecture supports GDPR data minimization and can help with HIPAA or SOC 2 technical safeguards. Regulated PHI still requires a written agreement or BAA, plus the operational controls and vendor confirmation your compliance program requires.
Common questions.
What happens if you get hacked?
If an attacker gains access to our database, they’d only see encrypted blobs — essentially random bytes. Without your password-authenticated unlock or a saved backup key, the data is mathematically impossible to decrypt with current technology.
Can government agencies force you to decrypt my data?
No, because we genuinely cannot. We don’t have the keys. Even with a warrant or court order, we can only provide the encrypted ciphertexts — which are useless without your password-authenticated unlock or a backup key you saved.
What if I forget my password?
If you saved a backup key, you can use it once to reset your password and keep access to your encrypted data. If you did not save a backup key, Worklist cannot recover the data for you.
How is this different from “encrypted at rest”?
“Encrypted at rest” means data is encrypted on the server’s hard drives, but the server still has the keys to decrypt it. End-to-end encryption means only you (the endpoints) have the keys — the server never has plaintext access.
Can Worklist employees see my data?
No. Our backend code is designed to never decrypt user payloads. Even database administrators with full access to our servers cannot read your work lists or tasks.
What if I want to export my data?
You can export your decrypted data anytime from the app. Since decryption happens in your browser, you’ll get readable JSON/CSV files — not encrypted blobs.
References & standards.
Our cryptographic choices follow industry standards and peer-reviewed specifications.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Our symmetric encryption standard
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Zero-knowledge password authentication
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Key exchange for team invitations
- 04 RFC 9106: Argon2 Memory-Hard Function — Password-based key derivation
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Federal cryptographic guidance
- 06 GDPR Article 32: Security of Processing — EU data protection requirements
Ready for real privacy?
Join teams who trust Worklist to keep their work truly private. Start your free trial — no credit card required.
Start free trialHave security questions? Email us at security@worklist.app