Stručně
Worklist používá šifrování ChaCha20-Poly1305 a zero-knowledge architekturu. Data se šifrují na vašem zařízení kryptografií vojenské úrovně dřív, než dorazí na naše servery. I s plným přístupem do databáze fyzicky neumíme vaše úkoly přečíst. Podporuje minimalizaci dat podle GDPR a může pomoci s technickými zárukami pro HIPAA/SOC 2, pokud je doplněný o potřebné smlouvy a provozní kontroly.
Náš základní princip.
Vaše data se šifrují na vašem zařízení dříve, než dorazí na naše servery. Worklist je navržený tak, abychom my — firma — nemohli dešifrovat, číst ani přistupovat k vašim pracovním seznamům, úkolům a komentářům. Tomu se říká zero-knowledge architektura.
V čem je Worklist jiný.
Tradiční správa úkolů.
Co dělají konkurenti
- • Ukládají vaše data na serverech v čitelné podobě
- • Mohou číst každý úkol, komentář i soubor
- • Mohou obsah procházet kvůli reklamě, AI tréninku nebo „funkcím“
- • Při úniku dat odhalí všechno
Worklist (zero-knowledge).
Co děláme my
- • Šifruje na vašem zařízení ještě před odesláním na servery
- • Vaše úkoly neumíme dešifrovat, ani kdybychom chtěli
- • Žádné prohledávání, žádný trénink AI na vaší soukromé práci
- • Únik dat neodhalí nic smysluplného — jen šifrované bloky
Jak zero-knowledge šifrování funguje.
Vytvoříte si účet.
Při registraci heslo nikdy neopustí prohlížeč v čitelné podobě. Místo toho:
- Prohlížeč pomocí Argon2id odvodí z hesla obalovací klíč
- Na zařízení se vygeneruje náhodný 32bajtový „datový klíč“
- Tento datový klíč je zašifrovaný obalovacím klíčem odvozeným z hesla
- Zašifrovaný datový klíč se uloží na našich serverech — ale bez vašeho hesla ho nedešifrujeme
- Používáme protokol OPAQUE PAKE, takže servery nikdy nevidí vaše heslo v čitelné podobě
Klíčový bod: Obalovací klíč nikdy neopustí vaše zařízení. Bez vašeho hesla je pro nás zašifrovaný datový klíč k ničemu.
Proč šifrovaný datový klíč vůbec ukládáme?
Abyste se mohli přihlásit z jakéhokoli zařízení. Když přejdete na jiný počítač nebo telefon, pošleme vám zašifrovaný blok, vy znovu zadáte heslo, blok se lokálně dešifruje a jste zpět. Bez tohoto úložiště byste museli ručně přenášet 32bajtový klíč mezi zařízeními — strašný UX při stejné bezpečnosti.
Vytvoříte pracovní seznam nebo úkol.
Každý kus citlivých dat se zašifruje na vašem zařízení:
- Názvy seznamů, popisy a nastavení
- Názvy úkolů, jejich obsah, checklisty a komentáře
- Šablony opakovaných úkolů a rozvrhy
- Vše se šifruje pomocí ChaCha20-Poly1305 AEAD (moderní auditovaná šifra)
- Každý pracovní seznam má vlastní šifrovací klíč odvozený z vašeho datového klíče
Naše servery uchovávají jen zašifrovaný ciphertext — čitelný text z něj nepřečtou.
Pozvete členy týmu.
Při sdílení pracovních seznamů s kolegy:
- Každý člen dostane vlastní šifrovanou kopii klíče k seznamu
- Klíče se vyměňují přes HPKE (Hybrid Public Key Encryption)
- Veřejné klíče se publikují do logu transparentnosti (Merkle tree), což brání útokům typu man-in-the-middle
- Když člena odeberete, klíč seznamu se rotuje a všichni zbývající dostanou nové šifrované kopie
Naše servery ověřují, aniž by dešifrovaly.
Možná vás napadne: „Jak může server vynucovat oprávnění, když nedešifruje?“
Používáme HMAC důkazy — kryptografické podpisy, které dokáží, že máte právo k datům, aniž by odhalily čitelný obsah.
- Prohlížeč spočítá HMAC (klíčovaný hash) ze šifrovaných dat pomocí klíče specifického pro členství
- Server ověří HMAC, aby potvrdil, že jste aktivní člen
- Pokus o úpravu nebo přehrání cizích dat HMAC kontrolu neprojde
- Obsah nikdy nedešifrujeme — jen ověřujeme integritu a oprávnění
Co naše servery (ne)vidí.
NEVIDÍME
- × Názvy a popisy pracovních seznamů
- × Názvy úkolů, jejich obsah a checklisty
- × Komentáře a diskuze
- × Šablony opakovaných úkolů
- × Jakýkoli obsah v šifrovaných paketech
- × Vaše heslo (ani v podobě hashe)
VIDÍME
- ✓ E-mail účtu (pro přihlášení)
- ✓ Vztahy členství (kdo je v jakém seznamu)
- ✓ Stav úkolu (otevřený/uzavřený) a priorita
- ✓ Termíny a časové údaje
- ✓ Přiřazení delegací (jen ID uživatelů)
- ✓ Metadata potřebná pro dotazy (ID, data vzniku)
Proč jsou některá metadata viditelná: Některá pole (jako stav úkolu nebo termíny) musí být uložená v čitelné podobě, aby servery mohly efektivně filtrovat dotazy, posílat upomínky a udržovat indexy. Tato pole neobsahují žádný citlivý obsah — jen provozní metadata, díky kterým aplikace funguje.
Bezpečnostní záruky.
Odemykání heslem (jen na klientu).
Vaše heslo nikdy neopustí zařízení v čitelné podobě. Argon2id z něj odvodí obalovací klíč, kterým se dešifruje hlavní datový klíč. Z něj pak HKDF odvodí samostatné klíče pro každý pracovní seznam.
Server nedokáže dešifrovat data.
Backend nikdy nevolá operace dešifrování nad uživatelskými daty. Pouze ověřuje HMAC důkazy k potvrzení oprávnění.
Rotace klíčů při změně členů.
Když člena odeberete nebo odejde, klíč pracovního seznamu se rotuje. Všichni zbývající členové dostanou nové šifrované kopie, takže odešlý člen nemůže dešifrovat budoucí obsah.
Transparentnost pozvánkových klíčů.
Veřejné klíče pro pozvánky se zapisují do append-only Merkle tree. Klienti ověřují důkazy zařazení a konzistence, takže server nemůže potichu vyměnit klíče a odposlouchávat data.
Open source kryptografie.
Používáme prověřené knihovny: strong-box (ChaCha20-Poly1305), Argon2id (odvození klíčů), OPAQUE (autentizace heslem) a HPKE (výměna klíčů). Veškerý kryptografický kód je open source a auditovatelný.
Jak ověřujeme naše zabezpečení.
Naše bezpečnostní tvrzení jsou ověřitelná, ne jen marketing. Takto zajišťujeme, že zero-knowledge architektura skutečně funguje, jak slibujeme:
- Open-source kryptografický kód na GitHubu k veřejnému auditu bezpečnostními experty
- Prověřené knihovny včetně ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) a HPKE
- Kryptografické důkazy (HMAC), které matematicky brání dešifrování na serveru
- Logy transparentnosti (Merkle trees) k odhalení útoků s podvržením klíčů
- Odvozování klíčů na klientu pomocí Argon2id zajišťuje, že nikdy nevidíme vaše heslo ani šifrovací klíče
Kompromisy zero-knowledge.
Žádná obnova hesla.
Když heslo zapomenete, vaše data neobnovíme. Možnost „resetovat heslo a zachovat data“ neexistuje, protože nemáme klíče k jejich dešifrování.
Žádné serverové vyhledávání.
Protože je obsah úkolů šifrovaný, neumíme nabídnout fulltextové vyhledávání na serveru napříč všemi úkoly. Vyhledávání probíhá v prohlížeči po dešifrování.
Zmírnění: Vyhledávání v prohlížeči optimalizujeme indexovanými dotazy a rychlým dešifrováním, aby zůstalo svižné.
Technické specifikace.
| Symetrické šifrování | ChaCha20-Poly1305 AEAD (přes knihovnu strong-box) |
| Stretching hesla | Argon2id (64 MiB paměti, 3 iterace, paralelismus 1) — převádí heslo na obalovací klíč |
| Hierarchie klíčů | HKDF-SHA256 — z datového klíče odvozuje klíče pro seznamy a členství |
| Autentizace heslem | OPAQUE PAKE (křivka Ristretto255) |
| Výměna klíčů (pozvánky) | HPKE (Hybrid Public Key Encryption) s X25519 |
| Integritní důkazy | HMAC-SHA256 |
| Serializace | CBOR (Concise Binary Object Representation) |
| Velikost klíče | 256 bitů (32 bajtů) pro všechny symetrické klíče |
Všechny kryptografické operace probíhají v prohlížeči pomocí WebCrypto API a auditovaných WASM modulů zkompilovaných z Rustu.
Audity a transparentnost.
Open source kryptografický stack.
Celá naše kryptografická implementace je open source a dostupná na GitHubu. Bezpečnostní výzkumníky vítáme, ať náš kód auditují.
Otevřít na GitHubuCompliance.
Zero-knowledge architektura podporuje minimalizaci dat podle GDPR a může pomoci s technickými zárukami pro HIPAA nebo SOC 2. Regulovaná PHI stále vyžadují písemnou smlouvu nebo BAA, provozní kontroly a potvrzení dodavatele podle vašeho compliance programu.
Časté otázky.
Co se stane, když vás někdo hackne?
Pokud se útočník dostane k naší databázi, uvidí jen šifrované bloky — v podstatě náhodné bajty. Bez vašeho hesla (které neukládáme) je dnešní technologií matematicky nemožné je dešifrovat.
Mohou vás úřady donutit dešifrovat moje data?
Ne, protože to skutečně neumíme. Nemáme klíče. I se soudním příkazem můžeme poskytnout pouze šifrovaný ciphertext — bez vašeho hesla je k ničemu.
Čím se to liší od „šifrování v klidu“?
„Šifrování v klidu“ znamená, že data jsou šifrovaná na discích serveru, ale server stále má klíče k dešifrování. End-to-end šifrování znamená, že klíče máte jen vy (koncové body) — server nikdy nemá přístup k čitelným datům.
Mohou zaměstnanci Worklistu vidět moje data?
Ne. Náš backend je navržen tak, aby uživatelská data nikdy nedešifroval. Ani správci databáze s plným přístupem k serverům nepřečtou vaše pracovní seznamy ani úkoly.
Co když chci data exportovat?
Dešifrovaná data můžete kdykoli z aplikace exportovat. Dešifrování probíhá v prohlížeči, takže dostanete čitelné soubory JSON/CSV — žádné šifrované bloky.
Odkazy a standardy.
Naše kryptografické volby odpovídají průmyslovým standardům a recenzovaným specifikacím.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols — Náš standard symetrického šifrování
- 02 RFC 9497: OPAQUE Asymmetric PAKE Protocol — Zero-knowledge autentizace heslem
- 03 RFC 9180: Hybrid Public Key Encryption (HPKE) — Výměna klíčů pro týmové pozvánky
- 04 RFC 9106: Argon2 Memory-Hard Function — Odvození klíče z hesla
- 05 NIST SP 800-175B: Guideline for Using Cryptographic Standards — Federální kryptografické pokyny
- 06 GDPR Article 32: Security of Processing — Požadavky EU na ochranu osobních údajů
Připraveni na skutečné soukromí?
Připojte se k týmům, které důvěřují Worklistu, že jejich práce zůstane opravdu soukromá. Spusťte zkušební verzi — bez platební karty.
Spustit zkušební verziMáte otázky k bezpečnosti? Napište nám na security@worklist.app