Šifrování na straně klienta při sdílení důvěrných údajů

Šifrování na straně klienta chrání uloženou tajnou zprávu před provozovatelem služby a před každým, kdo získá databázi, a před ničím dalším. Škodlivý JavaScript, rozšíření prohlížeče nebo uniklý odkaz ho obejdou, protože klíč putuje v odkazu. Není to všelék a za svou jedinou záruku si nechává zaplatit jinde.

Tento průvodce vysvětluje, co šifrování v prohlížeči zaručuje, kde nenápadně selhává, jak si stojí ve srovnání se šifrováním na serveru a jak obojí kombinuje LinkPilot od 29. září 2026, kdy jeho generátor jednorázových tajných odkazů přešel na šifrování v prohlížeči.

Přepsáno 19. října 2026. Původní verze článku popisovala tehdejší model šifrování na serveru, který LinkPilot používal; poznámka doplněná 29. září 2026 zaznamenala přechod. Tato verze popisuje v celém textu současný model. Úvahy o tom, co který model chrání a co ne, se nezměnily.

Co šifrování na straně klienta skutečně chrání?

Uloženou tajnou zprávu, a to před provozovatelem a před každým, kdo získá databázi. V nástroji pro tajné zprávy se šifrováním na straně klienta (říká se mu také koncové šifrování, end-to-end, E2EE) postup vypadá takto:

1. Prohlížeč vygeneruje symetrický šifrovací klíč, obvykle 256bitový klíč AES-GCM přes Web Crypto API (crypto.subtle.generateKey).
2. Obsah se tímto klíčem zašifruje v prohlížeči.
3. Na server se pošle jen šifrový text a server ho uloží pod náhodným identifikátorem.
4. Klíč se připojí ke sdílenému odkazu jako fragment (#…). Podle RFC 3986, oddíl 3.5 prohlížeče část odkazu za znakem # v požadavcích HTTP nikdy neposílají, takže se klíč na server vůbec nedostane.
5. Prohlížeč příjemce přečte fragment, stáhne šifrový text a dešifruje ho lokálně.

Server vždy vidí jen šifrový text. Provozovatel, který čte vlastní databázi, uniklá záloha databáze, soudní příkaz k vydání uložených dat: nic z toho tajnou zprávu nevydá, pokud vydrží všechny ostatní články řetězu.

Anatomie tajného odkazu s E2EE

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

Vše před znakem # putuje v požadavku a může se objevit v lozích serveru a proxy. Fragment zpracovává jen prohlížeč příjemce. Celou bezpečnostní práci odvádí tento jediný znak. Je to elegantní, a zároveň je to kořen většiny slabin popsaných dál.

Před čím šifrování na straně klienta nechrání?

Před škodlivým nebo napadeným JavaScriptem, rozšířeními prohlížeče a uniklým odkazem, protože klíč je v odkazu.

• Nechrání před škodlivým JavaScriptem. Šifrovací kód běží v prohlížeči a prohlížeč ho dostal ze serveru. Pokud server doručí upravený kód, protože se provozovatel obrátil proti uživatelům, byl k tomu donucen nebo byl hacknut, dá se tajná zpráva přečíst před zašifrováním nebo po dešifrování. To je základní hranice E2EE v prohlížeči.
• Nechrání před rozšířeními prohlížeče. Rozšíření s přístupem ke stránce vidí po dešifrování čitelný text a fragment si může přečíst přímo.
• Uniklý odkaz neudělá neškodným. Klíč je součástí odkazu. Pokud příjemce vloží celý odkaz do chatu, přepošle e-mail nebo má zapnutou synchronizaci historie prohlížeče, klíč putuje s ním. Odkaz s E2EE, jehož URL unikla, je plně čitelná tajná zpráva. Jedinou obranou je heslová fráze poslaná jiným kanálem. Proto ji LinkPilot zapracovává přímo do klíče, místo aby ji ověřoval zvlášť.
• Neumožňuje audit, skenování ani náhled obsahu. Server obsah nepřečte, takže na něm nemůže filtrovat obsah, hledat malware ani provádět ochranu před únikem dat (DLP). Kontrolní mechanismy musí místo toho pracovat se šifrovým textem a s událostmi přístupu.

Problém doručování kódu podrobně

U tohoto bodu stojí za to se zastavit: E2EE v prohlížeči znamená věřit, že server, kterému údajně nevěříte, při každém načtení stránky doručí poctivý JavaScript. Nativní aplikace se instaluje jednou, je podepsaná a má verzi. Webová stránka se stahuje znovu při každé návštěvě. Subresource integrity a zveřejněný zdrojový kód tuto mezeru zužují, ale neuzavírají.

Poctivě čteno tedy „vaše tajné zprávy nemůžeme číst“ znamená „vaše tajné zprávy nemůžeme číst pasivně“. Udělat z pasivní možnosti aktivní útok, který doručí upravený kód, je pro útočníka skutečně o stupeň těžší (aktivní útoky jsou riskantnější, cílené a dají se případně odhalit), ale není to totéž co „nemožné“. Platí to pro tvrzení LinkPilotu stejně jako pro tvrzení kohokoli jiného.

Alternativa na straně serveru

Druhý běžný přístup, který LinkPilot používal do září 2026, šifruje uložená data na serveru a zobrazení chrání hashovanou heslovou frází:

• TLS při přenosu; obsah uložený ve vyhrazené tabulce databáze se šifrováním uložených dat na úrovni disku.
• Heslové fráze se hashují v prohlížeči ještě před odesláním a porovnávají se podle hashe; samotná heslová fráze se do databáze nikdy nedostane.
• Zničení přepsáním: při prvním zobrazení, vypršení platnosti nebo zneplatnění se uložený obsah přepíše a další pokusy dostanou HTTP 410.
• Pokusy o heslovou frázi mají omezený počet a zaznamenávají se.

V tomto modelu server aktivní tajnou zprávu přečíst může. Právě to umožňuje náhled na serveru, skenování a funkce pracující s obsahem, a přesně tuto vlastnost E2EE odstraňuje. Open source nástroje jako OneTimeSecret ho stále používají. Důsledky rozebírá článek je OneTimeSecret bezpečný?

Co LinkPilot dělá dnes

Od 29. září 2026 používá LinkPilot šifrování na straně klienta a ponechává si ty kontrolní mechanismy na serveru, které obsah nepotřebují. Ze stránky bezpečnostní architektura:

• Šifrování v prohlížeči. Obsah se šifruje algoritmem AES-GCM-256 256bitovým klíčem vygenerovaným v prohlížeči odesílatele. Server ukládá šifrový text a nic jiného; klíč putuje ve fragmentu sdíleného odkazu.
• Heslová fráze jako součást klíče (Pro). Heslová fráze se zesiluje funkcí PBKDF2-SHA256 (210 000 iterací) a s klíčem odkazu se kombinuje přes HKDF-SHA256. Samotný odkaz ani samotná heslová fráze tak tajnou zprávu nedešifrují. Počet pokusů je omezen na 5 za minutu z jedné IP adresy pro každou tajnou zprávu, a to kombinací omezovače v paměti a klouzavého okna v databázi.
• Zničení po přečtení na úrovni šifrového textu. Zobrazení se zaznamenává databázovou funkcí v jediném nedělitelném kroku, takže souběžné pokusy o zobrazení nemohou tajnou zprávu prozradit dvakrát. Uložený šifrový text se přepíše na [REDACTED] a další pokusy vracejí HTTP 410.
• Zneplatnění. Tajnou zprávu jde kdykoli zneplatnit z řídicího panelu; zneplatněnou tajnou zprávu už nejde zobrazit a server vrací 410.
• Zobrazení odolné vůči náhledům. Nástroje pro náhledy odkazů a skenery e-mailů posílají požadavky GET, které vracejí jen metadata (stav a to, zda je potřeba heslová fráze). Zobrazení se zaznamená jen při výslovném zobrazení z prohlížeče.
• Časová osa auditu (Pro). Vytvoření, zobrazení, chybná heslová fráze, zničení, vypršení platnosti a zneplatnění, u každé události časové razítko, země a město podle edge sítě, řetězec prohlížeče a hash adresy s denně měněnou solí. Časová osa zaznamenává přístup, nikdy obsah.
• Soubory. Přílohy se také šifrují v prohlížeči, klíčem odvozeným od klíče odkazu. Název, velikost a typ souboru zůstávají LinkPilotu viditelné jako metadata.

Tři omezení na rovinu. Tajné zprávy vytvořené před 29. zářím 2026 byly uloženy jako čitelný text až do vypršení platnosti a nikdy nebyly přepsány. Metadata souborů jsou viditelná, i když obsah souborů ne. A platí vše z oddílu o tom, co šifrování nedělá: škodlivý JavaScript, rozšíření prohlížeče a uniklý odkaz tento model neřeší, stejně jako žádný jiný model založený na prohlížeči.

Shrnutí kompromisů

Žádný model není „bezpečnější“ obecně. Brání se různým hrozbám za různou cenu a jejich kombinace zmenšuje to, čeho se vzdáváte, ale neodstraní to.

Model podle hrozby: tři scénáře

1. Heslo k databázi pro externistu. Hrozbou je, že tajná zpráva zůstane ležet v e-mailu nebo chatu, případně se omylem přepošle. Každý model si s tím poradí díky krátké platnosti a zničení po přečtení; rozhoduje použitelnost a záznam. Praktickou volbou je šifrování v prohlížeči s heslovou frází poslanou jiným kanálem a časovou osou, která ukáže, kdy byl odkaz otevřen.

2. Novinář přijímá materiál od zdroje. Model hrozeb zahrnuje i to, že provozovatel platformy bude donucen data vydat. Provozovatel je tu součástí hrozby, takže E2EE je minimum a správnou volbou jsou nástroje postavené přímo pro tento účel, například SecureDrop, kde je celý systém navržen právě kolem této hrozby. Webový nástroj, který by mohl být donucen doručit upravený JavaScript, sám o sobě nestačí.

3. Vývojový tým, který si běžně předává přihlašovací údaje. Hrozbou je nepořádek: zapomenuté odkazy a žádný záznam o tom, kdo co viděl. Důležité funkce jsou časová osa, zneplatnění, role v pracovním prostoru a pravidla pro platnost. Dřív k nim byl potřeba server, který obsah přečte. Dnes už ne, protože pracují se šifrovým textem a s událostmi přístupu. Pravidlům pro tento scénář se věnuje stránka bezpečné sdílení hesel v týmu.

Jak vybírat

Šifrování na straně klienta zvolte, když:

• Nevěříte provozovateli, a to ani sami sobě, pokud provozujete službu na cloudové infrastruktuře, kterou nedokážete plně ověřit.
• Předpisy nebo smlouvy vyžadují, aby poskytovatel technicky nemohl obsah přečíst.
• Heslovou frázi pošlete druhým kanálem a platnost necháte krátkou, protože jinak uniklý odkaz znamená celou tajnou zprávu.

Šifrování na straně serveru zvolte, když:

• Potřebujete, aby server kontroloval obsah: skenování malwaru, ochrana před únikem dat, filtrování obsahu.
• Provozujete jednoúčelový nástroj na vlastním serveru a provozovatelem jste vy.

Hledejte obojí, když:

• Chcete provozovatele vyřadit z řetězce důvěry a přesto potřebujete časovou osu, zneplatnění, týmové role a zobrazení, které náhled odkazu nespustí. Zeptejte se dodavatele, které kontrolní mechanismy pracují se šifrovým textem a které po tichu potřebují čitelný obsah.

Je online šifrovací nástroj správná volba?

Kdo hledá online šifrovací nástroj, obvykle chce jedno ze dvou: buď převést kus textu na šifrový text, který vloží kamkoli, nebo bezpečně dostat citlivou zprávu k jednomu člověku. To první je nástroj. To druhé je postup a samotný nástroj ho nedokončí.

Stránka, do které text vložíte k zašifrování, šifruje ve vašem prohlížeči, pokud je dobře postavená. Ověřit si to můžete podle kroků v oddílu o ověřování dál v textu. Vše kolem šifrového textu ale nechává na vás: zvolit silnou heslovou frázi, poslat ji jiným kanálem, smazat šifrový text všude, kam jste ho vložili, a zjistit, zda se ho příjemci podařilo dešifrovat. Kódování není šifrování, takže nástroj pro Base64 nechrání nic. Slabá heslová fráze je v praxi nejčastější důvod, proč šifrování v prohlížeči selže.

Jednorázový tajný odkaz provádí stejné šifrování v prohlížeči a postará se i o zbytek postupu: klíč putuje ve fragmentu odkazu, uložená kopie se při prvním otevření zničí, platnost odkazu vyprší, pokud ho nikdo neotevře, a odesílatel vidí, že byla tajná zpráva zobrazena. Pro zprávu určenou člověku se proto hodí lépe. Pro šifrový text, který si potřebujete uchovat sami nebo vložit do systému, který spravujete, je lepší lokální nástroj jako age nebo GPG než jakákoli webová stránka, protože klíč se prohlížeče vůbec nedotkne.

Kdy nepoužít ani jedno

Některé důvěrné údaje by neměly cestovat přes žádný sdílený odkaz. Dlouhodobé přihlašovací údaje k účtu root, produkční podpisové klíče a hromadné exporty dat patří do správce důvěrných údajů nebo KMS s řízením přístupu, ne do URL. Pokud příjemce hodnotu potřebuje opakovaně, je položka v trezoru správce hesel lepší než opakované posílání odkazů. Jednorázové doručení slouží k předání, ne k ukládání. Hranici mezi nimi vymezuje článek tajné odkazy, nebo správci hesel.

Ověření tvrzení

Nevybírejte nástroj podle toho, který toho víc slibuje. Vybírejte podle toho, před čím se bráníte, a ověřte, že slib na obalu odpovídá architektuře pod ním:

• Je klíč ve fragmentu? Podívejte se na strukturu odkazu; klíč by měl být za znakem #.
• Vrátí obyčejné stažení odkazu tajnou zprávu? Nemělo by.
• Co dělá heslová fráze: hlídá zobrazení, nebo je součástí klíče?
• Co se zaznamenává a uvádí to provozovatel písemně?

Odpovědi LinkPilotu včetně omezení najdete na stránce bezpečnostní architektura. Pro tuto stránku platí stejný test jako pro stránky kohokoli jiného.

Související články

• Jak fungují jednorázové tajné odkazy
• Je OneTimeSecret bezpečný?
• LinkPilot vs. PrivateBin
• Tajné odkazy, nebo správci hesel
• Proč adresy URL prozrazují citlivé údaje
• Skenery odkazů a jednorázové tajné zprávy

Zdroje

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.