Co server ukládá a loguje

Stručně

Server je hloupý prostředník: drží veřejné klíče a dočasné šifrované balíčky, nemá žádný privátní klíč, neukládá plaintext ani kontakt na odesílatele.

1. Princip: hloupý prostředník

GrataQ server je záměrně navržen jako pasivní přepravce. Jeho jediná úloha je přijmout od odesílatele již zašifrovaný balíček, podržet ho po dobu platnosti a vydat ho příjemci — a dále vydávat veřejné klíče a podepsané jednorázové pre-keys, aby odesílatel věděl, čím má šifrovat. Server nemá žádný privátní klíč: nedrží privátní klíč identity ani privátní klíče pre-keys, a proto sám nemůže nic dešifrovat.

Šifrování i dešifrování probíhá výhradně na koncových zařízeních. Obsah souboru je zašifrovaný už u odesílatele v prohlížeči a rozšifrovat ho dokáže jedině příjemce ve své aplikaci. I kdyby byl server kompromitován, útočník získá jen nečitelné bloby a veřejné klíče — nikoli obsah souborů a nemůže ani podstrčit falešný klíč, protože podpis pre-key by neseděl proti ověřené doméně příjemce.

2. Co server UKLÁDÁ

Datový model na serveru tvoří čtyři jádrové entity — Account, PreKey, Blob a Session — doplněné o volitelný kontaktní e-mail příjemce a fakturační údaje u placených tarifů. Tabulka níže rozlišuje, zda je daný údaj uložen šifrovaně (server obsah nevidí), jako veřejný klíč, nebo jako metadata v čitelné podobě.

Údaj	Podoba	Účel	Doba uchování
Identifikátor účtu (ID)	veřejné — odvozeno z veřejného klíče (SHA-256 otisk veř. ML-DSA klíče)	adresování příjemce	po dobu existence účtu
Veřejný ML-DSA klíč příjemce	veřejný klíč	ověřování podpisů a identita	po dobu existence účtu
Branding (název, logo, ověřená doména)	metadata — needitovatelná data zadaná příjemcem	zobrazení odesílateli na upload stránce	po dobu existence účtu
Pre-keys (veřejný ML-KEM klíč + ML-DSA podpis)	veřejné	výměna klíče pro jednotlivý soubor	do spotřebování — jednorázové
Šifrovaný blob (zašifrovaný soubor)	šifrované — server obsah nevidí	doručení souboru příjemci	dle retence tarifu / do vyzvednutí
Session token	krátkodobý token	autentizace relace příjemce	krátká platnost
Kontaktní e-mail pro upozornění	metadata — uložen (jen pokud si příjemce zapne; placené tarify)	notifikace na nový soubor	do vypnutí funkce / zrušení účtu
Fakturační údaje	metadata — uložen (placené tarify)	vystavení daňového dokladu	dle účetních a daňových předpisů

3. Co server NEUKLÁDÁ

Stejně důležité jako to, co na serveru je, je to, co na něm nikdy není:

Žádný privátní klíč — ani privátní klíč identity příjemce, ani privátní klíče pre-keys. Privátní klíče nikdy neopustí zařízení příjemce. Bez nich nelze nic dešifrovat.
Žádná nešifrovaná data ani plaintext souborů — server vidí výhradně nečitelné zašifrované bloby.
Žádný e-mail ani telefon odesílatele — odesílatel se neregistruje, server o něm nevede žádné kontaktní údaje.
Žádné heslo — identita je kryptografický klíč, ne heslo. Server tedy neukládá žádné heslo ani jeho hash.

Údaje o odesílateli, které sám dobrovolně vyplní (např. jméno nebo poznámka, pokud si je příjemce vyžádá), jsou součástí zašifrovaného balíčku — server je vidí jen v nečitelné podobě a přečte je až příjemce ve své aplikaci.

4. Co server LOGUJE (provozní záznamy)

Pro bezpečný a stabilní provoz vede server technické provozní záznamy. Buďme konkrétní — typicky jde o:

IP adresu požadavku,
čas požadavku,
velikost zašifrovaného balíčku (počet bajtů přeneseného blobu),
typ operace (např. nahrání, vyzvednutí, vyžádání pre-key, autentizace),
čítače pro rate-limiting (omezení frekvence požadavků).

Účelem těchto záznamů je bezpečnost a ochrana proti zneužití (např. proti DoS útokům a automatizovanému zahlcení). Záznamy se uchovávají jen po nezbytně nutnou dobu pro tyto účely.

Poctivě o metadatech

IP adresa a čas přenosu jsou serveru viditelné — jsou to metadata. Server tedy v zásadě vidí, kdo (z jaké IP), kdy a jak velký balíček prošel, i když obsah balíčku nevidí. Útočník s přístupem k serveru by získal komunikační metadata, nikdy však obsah souborů.

5. Šifrování při uložení a přenosu

Obsah je zašifrovaný už u odesílatele, ještě než opustí jeho zařízení: payload se šifruje AES-256-GCM klíčem odvozeným přes ML-KEM (post-kvantová výměna klíče) z veřejného pre-key příjemce. Server takto zašifrovaný blob jen přijme a uloží — klíč k jeho rozšifrování nemá.

Přenos mezi klientem a serverem je navíc chráněn TLS 1.3. Bloby leží na úložišti v Evropské unii pouze jako nečitelná data; šifrování obsahu je nezávislé na TLS, takže obsah zůstává chráněný i v klidovém stavu na úložišti.

6. Kdo má přístup

K veřejným klíčům (ID, veřejný ML-DSA klíč, podepsané pre-keys, branding) — kdokoli. Jsou ze své podstaty veřejné; slouží k tomu, aby vám lidé mohli bezpečně posílat soubory.
K šifrovaným blobům — fakticky jen příjemce. Jako jediný drží privátní klíč potřebný k dešifrování. Nikdo jiný, ani provozovatel, obsah nerozšifruje.
Provozní personál — vidí pouze šifrovaná data a provozní metadata (viz sekce 4), nikdy ne obsah souborů.

7. Retence a mazání

Doba, po kterou šifrovaný blob zůstane na serveru, závisí na tarifu příjemce:

Tarif	Maximální retence blobu
Zdarma	7 dní
Profesionální	30 dní
Instituce	90 dní
Enterprise	až 180 dní

Po vyzvednutí lze blob smazat okamžitě ručně, nebo ho po uplynutí retence odstraní automatický úklid; smazání je nevratné. Nedokončené (přerušené) uploady se rovněž uklízejí, aby na úložišti nezůstávaly osiřelé fragmenty. Podrobnosti o limitech jsou v ceníku; právní rámec uchování viz ochrana osobních údajů.

8. Co NESLEDUJEME vůbec

Žádné sledování uživatelů

V aplikaci ani na tomto webu neběží žádná analytika, žádné sledovací cookies třetích stran a žádné profilování. Nevytváříme profily uživatelů ani návštěvníků a jejich chování nesledujeme.

9. Kde data leží (region)

Veškerá data — veřejné klíče, šifrované bloby i provozní záznamy — jsou uložena na serverech v Evropské unii.

Související dokumenty: podrobný protokol a architektura v whitepaperu, předpoklady útočníka a hranice ochrany v modelu hrozeb, životní cyklus klíčů v dokumentu životní cyklus klíčů, a právní rámec zpracování v ochraně osobních údajů.