TL;DR
Worklist nutzt ChaCha20-Poly1305-Verschlüsselung mit Zero-Knowledge-Architektur. Ihre Daten werden mit militärtauglicher Kryptografie auf Ihrem Gerät verschlüsselt, bevor sie unsere Server erreichen. Selbst mit vollem Datenbankzugriff können wir Ihre Aufgaben physisch nicht lesen. Die Architektur unterstützt DSGVO-Datenminimierung und kann bei technischen Schutzmaßnahmen für HIPAA/SOC 2 helfen, wenn die erforderlichen Vereinbarungen und operativen Kontrollen bestehen.
Unser Grundprinzip.
Ihre Daten werden auf Ihrem Gerät verschlüsselt, bevor sie unsere Server überhaupt erreichen. Wir haben Worklist so entworfen, dass wir — das Unternehmen — Ihre Arbeitslisten, Aufgaben und Kommentare nicht entschlüsseln, lesen oder darauf zugreifen können. Das nennen wir Zero-Knowledge-Architektur.
Was Worklist anders macht.
Klassische Aufgabenverwaltung.
Was die Konkurrenz tut
- • Speichert Ihre Daten im Klartext auf ihren Servern
- • Kann jede Aufgabe, jeden Kommentar und jede Datei lesen
- • Scannt Inhalte ggf. für Werbung, KI-Training oder „Features“
- • Anfällig für Datenlecks, die alles offenlegen
Worklist (Zero-Knowledge).
Was wir tun
- • Verschlüsselt auf Ihrem Gerät, bevor Daten an unsere Server gehen
- • Wir können Ihre Aufgaben nicht entschlüsseln, selbst wenn wir wollten
- • Kein Scannen, kein KI-Training mit Ihrer privaten Arbeit
- • Datenlecks legen nichts Brauchbares offen — nur verschlüsselte Blöcke
Wie Zero-Knowledge-Verschlüsselung funktioniert.
Sie erstellen Ihr Konto.
Bei der Registrierung verlässt Ihr Passwort den Browser nie im Klartext. Stattdessen:
- Ihr Browser leitet mit Argon2id einen Wrapping Key aus Ihrem Passwort ab
- Auf Ihrem Gerät wird ein zufälliger 32-Byte-„Data Key“ erzeugt
- Dieser Data Key wird mit dem passwortabgeleiteten Wrapping Key verschlüsselt
- Der verschlüsselte Data Key liegt auf unseren Servern — aber wir können ihn ohne Ihr Passwort nicht entschlüsseln
- Wir verwenden das OPAQUE PAKE-Protokoll, damit unsere Server Ihr Klartextpasswort nie sehen
Kernpunkt: Der Wrapping Key verlässt Ihr Gerät nie. Ohne Ihr Passwort ist der verschlüsselte Data Key für uns wertlos.
Warum den verschlüsselten Data Key überhaupt speichern?
Damit Sie sich von jedem Gerät anmelden können. Wenn Sie den Computer wechseln oder Ihr Telefon nutzen, senden wir Ihnen den verschlüsselten Blob, Sie geben Ihr Passwort erneut ein, um es lokal zu entschlüsseln, und sind wieder drin. Ohne dieses Vorgehen müssten Sie einen 32-Byte-Schlüssel manuell zwischen Geräten kopieren — schreckliche UX bei gleicher Sicherheit.
Sie erstellen eine Arbeitsliste oder Aufgabe.
Jedes sensible Datenstück wird auf Ihrem Gerät verschlüsselt:
- Listentitel, Beschreibungen und Einstellungen
- Aufgabentitel, -inhalte, Checklisten und Kommentare
- Vorlagen für wiederkehrende Aufgaben und Zeitpläne
- Alles wird mit ChaCha20-Poly1305 AEAD verschlüsselt (eine moderne, geprüfte Chiffre)
- Jede Arbeitsliste hat einen eigenen, aus Ihrem Data Key abgeleiteten Schlüssel
Unsere Server speichern nur den verschlüsselten Ciphertext — den Klartext können sie nicht lesen.
Sie laden Teammitglieder ein.
Beim Teilen von Arbeitslisten mit Kolleg:innen:
- Jedes Mitglied erhält eine eigene verschlüsselte Kopie des Listenschlüssels
- Schlüssel werden per HPKE (Hybrid Public Key Encryption) ausgetauscht
- Öffentliche Schlüssel werden in einem Transparenz-Log (Merkle Tree) veröffentlicht, um Man-in-the-Middle-Angriffe zu verhindern
- Wird ein Mitglied entfernt, wird der Listenschlüssel rotiert und alle Verbleibenden bekommen neue verschlüsselte Kopien
Unsere Server prüfen, ohne zu entschlüsseln.
Sie fragen sich vielleicht: „Wenn der Server nicht entschlüsseln kann, wie setzt er Berechtigungen durch?“
Wir nutzen HMAC-Beweise — kryptografische Signaturen, die Ihre Zugriffsberechtigung belegen, ohne den Klartext preiszugeben.
- Ihr Browser berechnet einen HMAC (Keyed Hash) der verschlüsselten Daten mit einem mitgliedschaftsspezifischen Schlüssel
- Der Server validiert den HMAC, um Ihre aktive Mitgliedschaft zu bestätigen
- Manipulationen oder Replays fremder Daten scheitern an der HMAC-Prüfung
- Wir entschlüsseln den Inhalt nie — wir prüfen nur Integrität und Autorisierung
Was unsere Server (nicht) sehen.
Wir sehen NICHT
- × Listentitel oder Beschreibungen
- × Aufgabentitel, -inhalte oder Checklisten
- × Kommentare oder Diskussionen
- × Vorlagen für wiederkehrende Aufgaben
- × Beliebige Inhalte in verschlüsselten Paketen
- × Ihr Passwort (auch nicht als Hash)
Wir sehen
- ✓ E-Mail des Kontos (für die Anmeldung)
- ✓ Mitgliedschaftsbeziehungen (wer in welcher Liste ist)
- ✓ Aufgabenstatus (offen/erledigt) und Priorität
- ✓ Fälligkeitsdaten und Zeitstempel
- ✓ Delegationszuweisungen (nur Nutzer-IDs)
- ✓ Metadaten für Abfragen (IDs, Erstellungsdaten)
Warum manche Metadaten sichtbar sind: Bestimmte Felder (wie Aufgabenstatus und Fälligkeiten) müssen im Klartext liegen, damit Server Abfragen effizient filtern, Erinnerungen senden und Datenbank-Indizes pflegen können. Diese Felder enthalten keine sensiblen Inhalte — nur betriebliche Metadaten, die die App funktionsfähig machen.
Sicherheits garantien.
Passwortbasiertes Entsperren (nur clientseitig).
Ihr Passwort verlässt Ihr Gerät nie im Klartext. Argon2id streckt es zu einem Wrapping Key, der Ihren Master-Datenschlüssel entschlüsselt. Dieser wird per HKDF zu eigenen Schlüsseln pro Arbeitsliste erweitert.
Server kann Inhalte nicht entschlüsseln.
Unser Backend-Code ruft nie Entschlüsselungsoperationen auf Nutzerdaten auf. Er validiert nur HMAC-Beweise zur Autorisierung.
Schlüsselrotation bei Mitgliederwechsel.
Wird ein Mitglied entfernt oder verlässt das Team, wird der Listenschlüssel rotiert. Alle Verbleibenden erhalten neue verschlüsselte Kopien, damit das ausgeschiedene Mitglied keine künftigen Inhalte entschlüsseln kann.
Transparenz für Einladungsschlüssel.
Öffentliche Schlüssel für Einladungen werden in einem Append-only-Merkle-Tree protokolliert. Clients prüfen Inklusions- und Konsistenzbeweise, sodass der Server keine Schlüssel heimlich austauschen kann.
Open-Source-Kryptografie.
Wir setzen auf erprobte Bibliotheken: strong-box (ChaCha20-Poly1305), Argon2id (Schlüsselableitung), OPAQUE (Passwortauthentifizierung) und HPKE (Schlüsselaustausch). Der gesamte Krypto-Code ist Open Source und prüfbar.
Wie wir unsere Sicherheit verifizieren.
Unsere Sicherheitsaussagen sind nachprüfbar, kein Marketing. So stellen wir sicher, dass die Zero-Knowledge-Architektur wie versprochen funktioniert:
- Open-Source-Krypto-Code auf GitHub, frei zugänglich für externe Sicherheitsprüfungen
- Erprobte Bibliotheken inklusive ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) und HPKE
- Kryptografische Beweise (HMAC), die serverseitige Entschlüsselung mathematisch ausschließen
- Transparenz-Logs (Merkle Trees) zum Erkennen von Schlüssel-Substitutionsangriffen
- Clientseitige Schlüsselableitung mit Argon2id sorgt dafür, dass wir Passwort und Schlüssel nie sehen
Trade-offs von Zero-Knowledge.
Keine Passwortwiederherstellung.
Vergessen Sie Ihr Passwort, können wir Ihre Daten nicht wiederherstellen. Es gibt keine „Passwort zurücksetzen und Daten behalten“-Option, weil uns die Schlüssel zur Entschlüsselung fehlen.
Keine serverseitige Suche.
Da Aufgabeninhalte verschlüsselt sind, können wir keine serverseitige Volltextsuche über alle Aufgaben anbieten. Die Suche läuft nach der Entschlüsselung in Ihrem Browser.
Abhilfe: Wir optimieren die Client-Suche mit indizierten Lookups und schneller Entschlüsselung, damit sie performant bleibt.
Technische Spezifikationen.
| Symmetrische Verschlüsselung | ChaCha20-Poly1305 AEAD (via strong-box Library) |
| Passwort-Stretching | Argon2id (64 MiB Speicher, 3 Iterationen, Parallelität 1) — leitet Wrapping Key aus dem Passwort ab |
| Schlüsselhierarchie | HKDF-SHA256 — leitet Listen- und Mitgliedschaftsschlüssel aus dem Data Key ab |
| Passwortauthentifizierung | OPAQUE PAKE (Ristretto255-Kurve) |
| Schlüsselaustausch (Einladungen) | HPKE (Hybrid Public Key Encryption) mit X25519 |
| Integritätsbeweise | HMAC-SHA256 |
| Serialisierung | CBOR (Concise Binary Object Representation) |
| Schlüsselgröße | 256 Bit (32 Byte) für alle symmetrischen Schlüssel |
Alle kryptografischen Operationen laufen in Ihrem Browser über WebCrypto-APIs und geprüfte, aus Rust kompilierte WASM-Module.
Audits & Transparenz.
Open-Source-Krypto-Stack.
Unsere komplette kryptografische Implementierung ist Open Source und auf GitHub verfügbar. Wir laden Sicherheitsforscher:innen ausdrücklich zur Code-Prüfung ein.
Auf GitHub ansehenCompliance.
Unsere Zero-Knowledge-Architektur unterstützt DSGVO-Datenminimierung und kann bei technischen Schutzmaßnahmen für HIPAA oder SOC 2 helfen. Regulierte PHI erfordern weiterhin eine schriftliche Vereinbarung oder BAA sowie die operativen Kontrollen und Anbieterbestätigung, die Ihr Compliance-Programm verlangt.
Häufige Fragen.
Was passiert, wenn ihr gehackt werdet?
Verschafft sich jemand Zugriff auf unsere Datenbank, sieht er nur verschlüsselte Blöcke — im Grunde zufällige Bytes. Ohne Ihr Passwort (das wir nie speichern) lassen sich die Daten mit heutiger Technologie mathematisch nicht entschlüsseln.
Können Behörden euch zur Entschlüsselung zwingen?
Nein, weil wir es schlicht nicht können. Wir haben die Schlüssel nicht. Selbst mit Durchsuchungsbeschluss können wir nur die verschlüsselten Ciphertexte herausgeben — ohne Ihr Passwort sind sie wertlos.
Wie unterscheidet sich das von „encrypted at rest“?
„Encrypted at rest“ heißt, dass Daten auf den Servern verschlüsselt liegen — der Server hat aber die Entschlüsselungsschlüssel. Ende-zu-Ende-Verschlüsselung bedeutet, dass nur Sie (die Endpunkte) die Schlüssel haben — der Server hat nie Klartextzugriff.
Können Worklist-Mitarbeitende meine Daten sehen?
Nein. Unser Backend ist so gebaut, dass er Nutzerdaten nie entschlüsselt. Selbst Datenbankadmins mit Vollzugriff können Ihre Arbeitslisten oder Aufgaben nicht lesen.
Was, wenn ich meine Daten exportieren möchte?
Sie können Ihre entschlüsselten Daten jederzeit aus der App exportieren. Da die Entschlüsselung in Ihrem Browser läuft, erhalten Sie lesbare JSON-/CSV-Dateien — keine verschlüsselten Blöcke.
Referenzen & Standards.
Unsere kryptografischen Entscheidungen folgen Industriestandards und peer-reviewed Spezifikationen.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Unser Standard für symmetrische Verschlüsselung
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Zero-Knowledge-Passwortauthentifizierung
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Schlüsselaustausch für Team-Einladungen
- 04 RFC 9106: Argon2 Memory-Hard Function — Passwortbasierte Schlüsselableitung
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Bundesweite kryptografische Leitlinie
- 06 GDPR Article 32: Security of Processing — EU-Datenschutzanforderungen
Bereit für echten Datenschutz?
Schließen Sie sich Teams an, die Worklist vertrauen, ihre Arbeit wirklich privat zu halten. Kostenlos testen — ohne Kreditkarte.
Kostenlose Testphase startenSicherheitsfragen? Schreiben Sie uns an security@worklist.app