What does client-side encrypted PDF sharing actually mean?

It means the server storing your shared file literally cannot decrypt it. The encryption key is generated in the sender's browser, never uploaded, and only the recipient's browser can reconstruct it — either from the URL fragment or from a passphrase the sender shares out-of-band. The server only ever holds ciphertext.

What encryption does PDF Pro use for client-side encrypted sharing?

AES-256-GCM symmetric encryption with a 96-bit random initialization vector per file. For passphrase mode, keys are derived via PBKDF2-SHA256 with 310,000 iterations over a 128-bit random salt.

What is the difference between fragment mode and passphrase mode?

Fragment mode puts the 256-bit key in the URL hash (after #), which browsers never send to the server. Anyone with the full link can decrypt. Passphrase mode derives the key from a passphrase the sender picks — the ciphertext stays unreadable without it. Passphrase mode is safer if the link leaks; fragment mode is easier for low-friction sharing.

Is a URL fragment really safe as an encryption key carrier?

Compliant browsers never transmit the fragment portion of a URL (after #) to the server. It stays client-side. That's what makes the share link itself the decryption credential — the key rides with the recipient, not with the upload.

Can PDF Pro or a court read files stored via client-side encrypted sharing?

No. The server stores AES-256-GCM ciphertext plus an initialization vector (plus a salt in passphrase mode). Without the key — which we never received — that data is cryptographically indistinguishable from random bytes. We can only disclose ciphertext, which is what we have.

What happens if I lose the link or forget the passphrase?

The file is permanently unrecoverable. This is by design — client-side encryption means no recovery path, because a recovery path would require us to hold the key.

Is client-side encrypted PDF sharing free?

Yes. The free tier supports AES-256-GCM encryption and 24-hour link expiry with no signup required. The free-tier file cap is approximately 25 MB per transfer; Pro extends the expiry window and raises file limits.

Does the recipient need an account?

No. The recipient clicks the link, their browser decrypts locally via the Web Crypto API, and they download the file — no signup, no install.

Szyfrowane po stronie klienta · Udostępnianie PDF

Udostępnianie PDF szyfrowane po stronie klienta — wyjaśnione jak należy.

„Szyfrowanie end-to-end" bywa używane swobodnie. Oto rzeczywisty mechanizm kryptograficzny stojący za linkiem do PDF szyfrowanego po stronie klienta — AES-256-GCM, obsługa klucza, tryb fragmentu kontra hasło-fraza i to, czego serwer dosłownie nie może zrobić. Uwaga: „zero-knowledge" na tej stronie odnosi się do tego, że serwer nie posiada żadnych informacji, którymi mógłby odszyfrować plik, a nie do formalnych dowodów wiedzy zerowej (ZKP) — produkt nie używa ZKP.

lockAES-256-GCM vpn_keyPBKDF2-SHA256 · 310,000 linkFragment lub hasło-fraza memoryWeb Crypto API

sendWyślij zaszyfrowany link Jak to działa

Co tu oznacza „zero-knowledge"

Najpierw szybkie rozróżnienie: ten system nie używa dowodów wiedzy zerowej (ZKP). Sformułowanie „zero-knowledge" na tej stronie odnosi się do słabszej, ale praktycznie użytecznej własności: serwer przechowujący Twój udostępniony plik nie ma żadnej wiedzy — ani kryptograficznej, ani operacyjnej — która pozwoliłaby go odszyfrować. Klucz nigdy nie dotyka serwera, więc serwer nie może go ujawnić w żadnych okolicznościach. Mechanizm to zwykłe szyfrowanie po stronie klienta plus klucz, który podróżuje wyłącznie we fragmencie URL (lub jest wyprowadzony z hasła-frazy, której serwer nigdy nie widzi).

memory

Szyfrowanie odbywa się w Twojej przeglądarce

Nie na serwerze, nie w workerze, którego nie kontrolujesz — w Twojej karcie, poprzez window.crypto.subtle. Weryfikowalne w DevTools.

cloud_off

Wysyłany jest tylko szyfrogram

Treść uploadu to szyfrogram AES-256-GCM. PDF, nazwa pliku i metadane nigdy nie docierają do serwera w czytelnej formie.

vpn_key

Klucz podróżuje z odbiorcą

Albo we fragmencie URL (nigdy nie wysyłany na serwery), albo wyprowadzony z hasła-frazy wybranej przez nadawcę. W obu przypadkach nigdy go nie widzimy.

block

Brak odzyskiwania = brak backdoora

Zgubiłeś link albo zapomniałeś hasła-frazy? Plik znika na zawsze. Skoro klucz nigdy nie dociera do naszego serwera, nie istnieje ścieżka odzyskiwania, która osłabiłaby gwarancję.

Jak zbudowany jest link do PDF szyfrowanego po stronie klienta

Krok po kroku przez to, co robią przeglądarka nadawcy, serwer i przeglądarka odbiorcy — z faktycznymi wywołaniami Web Crypto.

1 — Przeglądarka nadawcy

// 256-bit AES key, generated locally key = crypto.subtle.generateKey({name:"AES-GCM", length:256}) // fresh 96-bit IV per file iv = crypto.getRandomValues(new Uint8Array(12)) // encrypt locally; GCM gives us an auth tag for integrity ct = crypto.subtle.encrypt({name:"AES-GCM", iv}, key, pdfBytes) // upload ciphertext + iv (and salt, if passphrase mode) id = await PUT("/api/transfer", ct, {iv, expiry})

2 — Postać linku do udostępniania

// fragment mode: key lives after # link_f = `https://pdfpro.tools/s/<ID>#<KEY>` // passphrase mode: no key in the link; recipient must know the passphrase link_p = `https://pdfpro.tools/s/<ID>`

3 — Serwer przechowuje nieprzejrzyste bajty

ciphertext = ??? // random-looking, unreadable iv = 12-byte nonce salt = 16-byte random (passphrase mode only) expiry = 24h free / 30d Pro

4 — Przeglądarka odbiorcy

// browsers never transmit the URL fragment to the server rawKey = /* from location.hash OR */ PBKDF2(passphrase, salt, 310_000, "SHA-256") ct = await GET("/api/transfer/" + id) pdf = crypto.subtle.decrypt({name:"AES-GCM", iv}, importKey(rawKey), ct) // browser serves pdf to Downloads

Tryb fragmentu kontra tryb hasła-frazy

Dwa sposoby przeniesienia klucza do odbiorcy. Ta sama gwarancja szyfrogramu, różne kompromisy między wygodą a ryzykiem wycieku.

Tryb fragmentu

Klucz podróżuje w skrócie URL (`#`)

Najprostszy przepływ: skopiuj link, wklej w czacie do odbiorcy, gotowe. Część URL po # nie jest wysyłana przez żadną zgodną przeglądarkę do żadnego serwera WWW — to właśnie zachowuje klucz w prywatności.

Jeden krok dla odbiorcy — kliknięcie w link.
Niskie tarcie, odpowiednie dla udostępniania o niskiej i średniej wrażliwości.
Ryzyko: jeśli link wycieknie na zrzucie ekranu albo przez synchronizację przeglądarki, plik wycieka razem z nim.
Stosuj, gdy ufasz kanałowi (podpisany komunikator, czat wewnętrzny).

Tryb hasła-frazy

Klucz wyprowadzony z hasła-frazy (PBKDF2)

Nadawca wybiera hasło-frazę. Przeglądarka wyprowadza 256-bitowy klucz za pomocą PBKDF2-SHA256 z 310 000 iteracji nad losową 128-bitową solą. Sól jest przechowywana po stronie serwera; hasło-fraza jest udostępniane innym kanałem (telefon, Signal, osobiście).

Dwuskładnikowe udostępnianie: link i hasło-fraza podróżują osobno.
Sam link nie wystarczy — szyfrogram pozostaje nieczytelny.
Siła hasła-frazy ma znaczenie: 310k iteracji spowalnia brute force, ale nie uratuje 6-znakowego hasła.
Stosuj, gdy link może zostać przesłany dalej lub przechowywany w miejscu, któremu nie do końca ufasz.

Właściwość	Tryb fragmentu	Tryb hasła-frazy
Nośnik klucza	Skrót URL (`#`)	Hasło-fraza + sól
Czy serwer kiedykolwiek widzi klucz	Nie	Nie
Serwer przechowuje	Szyfrogram + IV	Szyfrogram + IV + sól
Wysiłek odbiorcy	Kliknięcie linku	Kliknięcie linku + wpisanie hasła-frazy
Podatne na wyciek przez zrzut ekranu	Tak (link = klucz)	Nie (sam link bezużyteczny)
Odporne na brute force	256-bitowa losowość	Zależnie od hasła-frazy
Najlepsze dla	Niskotarciowego udostępniania zaufanymi kanałami	Udostępniania o wyższej wrażliwości

Dlaczego szyfrogram przechowywany na serwerze nadal Cię chroni

Często pada pytanie: „skoro jest na waszym serwerze, jak może być prywatny?" Odpowiedź brzmi: szyfrogram to nie plik. Bez klucza to tylko losowo wyglądające bajty. Oto, co to oznacza w praktyce.

storage

Włam do bazy = wyciek szyfrogramu

Gdyby atakujący skompromitował naszą bazę, wyszedłby z nieprzejrzystymi bajtami. Odzyskanie jednego pliku wymagałoby brute force'owania 256-bitowego klucza — niewykonalne w ramach znanej fizyki.

gavel

Wezwanie sądowe daje szyfrogram

Sąd może zmusić nas do wydania tego, co mamy. To, co mamy, to szyfrogram. Nakaz sądowy nie może retroaktywnie wytworzyć klucza, którego nigdy nie przechowywaliśmy.

group

Dostęp wewnętrzny zneutralizowany

Nielojalny pracownik z pełnymi danymi do bazy i tak nie odczyta plików. Gwarancję wymusza matematyka, a nie kontrola dostępu.

timer

Wygaśnięcie wzmacnia gwarancję

Szyfrogram jest usuwany po wygaśnięciu (24 h w wersji darmowej, do 30 dni w Pro). Potem znika nawet szyfrogram — jedyna kopia pliku istnieje tam, gdzie został rozszyfrowany.

warningUczciwe ograniczenia

Szyfrowanie po stronie klienta nie rozwiązuje bezpieczeństwa punktów końcowych. Malware na urządzeniu nadawcy lub odbiorcy może wykraść klucz z pamięci. Skompromitowane rozszerzenie przeglądarki może odczytać rozszyfrowany plik. A przesłany dalej link w czacie grupowym unieważnia każdą gwarancję kryptograficzną. Architektura podnosi koszt włamania; nie eliminuje całego ryzyka.

Szyfrowanie po stronie klienta kontra inne „bezpieczne" opcje

Jasne porównanie typowych opcji udostępniania PDF. Większość opcji oznaczonych jako „bezpieczne" jest szyfrowana w transporcie — chronią dane w locie, ale serwer odbiorczy nadal trzyma plaintext i klucz.

Opcja	TLS w transporcie	Serwer może odczytać plik	Wygaśnięcie	Konto odbiorcy
Załącznik e-mail	Zwykle tak	Tak — na każdym hopie	Na zawsze	Niewymagane
Zwykły link chmurowy do udostępniania	Tak	Tak	Opcjonalnie	Czasami
PDF chroniony hasłem	Tak	Tak (jeśli host ma plik)	Nigdy	Niewymagane
PDF Pro (tryb fragmentu)	Tak	Nie	24 h / 30 d	Niewymagane
PDF Pro (tryb hasła-frazy)	Tak	Nie	24 h / 30 d	Niewymagane

Powiązane lektury

Udostępnianie oparte na zaufaniu kontra zero-knowledge wyścig na żywo

Ten sam cel — udostępnić PDF. Zobacz, jak oba modele zaufania docierają do mety obok siebie.

cloud_upload

Udostępnianie oparte na zaufaniu

Serwer trzyma plaintext

Wgraj PDF na serwer
Serwer trzyma plaintextPlaintext
Serwer obiecuje usunąćZaufanie
Ryzyko włamania po ich stronieRyzyko
Odbiorca pobiera plaintextUjawnione

Kopie plaintextu na serwerze

Serwer może czytać

Tak

Klucze na serwerze

Tak

shield_lock

To narzędzie

Udostępnianie zero-knowledge

Zaszyfruj PDF w przeglądarceE2E
Serwer trzyma tylko szyfrogramZero-knowledge
Odbiorca odszyfrowuje lokalnieGotowe

check_circle

Już udostępnione — a serwer nie może tego odczytać.

Brak plaintextu na serwerze. Brak depozytu kluczy. Odporne na włamania z założenia.

Kopie plaintextu na serwerze

Serwer może czytać

Nie

Klucze na serwerze

Nie

Animacja uruchamia się raz na wyświetlenie — dotknij powtórz, aby zobaczyć ponownie.

Najczęściej zadawane pytania

Co naprawdę oznacza udostępnianie PDF szyfrowane po stronie klienta?

Oznacza, że serwer przechowujący Twój udostępniony plik dosłownie nie potrafi go odszyfrować. Klucz szyfrowania jest generowany w przeglądarce nadawcy, nigdy nie jest wgrywany i tylko przeglądarka odbiorcy może go odtworzyć — albo z fragmentu URL, albo z hasła-frazy, którym nadawca dzieli się innym kanałem. Gwarancję wymusza kryptografia, a nie polityka kontroli dostępu, którą moglibyśmy zmienić. Uwaga: różni się to od formalnych dowodów wiedzy zerowej (ZKP), których ten produkt nie używa.

Jakiego szyfrowania używa PDF Pro do udostępniania szyfrowanego po stronie klienta?

Symetryczne szyfrowanie AES-256-GCM z 96-bitowym losowym wektorem inicjalizacyjnym dla każdego pliku. W trybie hasła-frazy klucze są wyprowadzane przez PBKDF2-SHA256 z 310 000 iteracji nad losową 128-bitową solą. Cała kryptografia działa w natywnym Web Crypto API przeglądarki.

Jaka jest różnica między trybem fragmentu a trybem hasła-frazy?

Tryb fragmentu umieszcza 256-bitowy klucz w skrócie URL (po #), którego przeglądarki nigdy nie wysyłają na żaden serwer. Każdy z pełnym linkiem może odszyfrować. Tryb hasła-frazy wyprowadza klucz z hasła-frazy wybranego przez nadawcę; bez niego szyfrogram pozostaje nieczytelny. Tryb hasła-frazy jest bezpieczniejszy, jeśli link wycieknie; tryb fragmentu jest łatwiejszy dla niskotarciowego udostępniania. Zobacz tabelę porównawczą powyżej.

Czy fragment URL jest naprawdę bezpieczny jako nośnik klucza szyfrowania?

Zgodne przeglądarki nigdy nie przesyłają części fragmentowej URL (części po #) na serwer. Pozostaje po stronie klienta i widoczna jest tylko dla JavaScriptu działającego w karcie odbiorcy. To właśnie sprawia, że link do udostępniania sam w sobie jest poświadczeniem deszyfrowania — klucz podróżuje z odbiorcą, a nie z uploadem. Można to zweryfikować w karcie Network przeglądarki: URL żądania jest obcinany na ? lub #.

Czy PDF Pro lub sąd mogą odczytać pliki przechowywane przez udostępnianie szyfrowane po stronie klienta?

Nie. Serwer przechowuje szyfrogram AES-256-GCM plus wektor inicjalizacyjny (plus sól w trybie hasła-frazy). Bez klucza — którego nigdy nie otrzymaliśmy — te dane są kryptograficznie nierozróżnialne od losowych bajtów. Możemy ujawnić tylko szyfrogram, czyli to, co mamy.

Co się stanie, jeśli zgubię link lub zapomnę hasła-frazy?

Plik jest trwale nie do odzyskania. Tak ma być — szyfrowanie po stronie klienta oznacza brak ścieżki odzyskiwania, ponieważ taka ścieżka wymagałaby, byśmy przechowywali klucz. Zapisz hasło-frazę w menedżerze haseł i przechowuj link w trwałym miejscu.

Czy udostępnianie PDF szyfrowane po stronie klienta jest darmowe?

Tak. Wersja darmowa obsługuje szyfrowanie AES-256-GCM oraz 24-godzinne wygaśnięcie linku bez konieczności rejestracji. Limit pliku w wersji darmowej to ok. 25 MB na transfer; Pro wydłuża okno wygaśnięcia do 30 dni i podnosi limity rozmiaru pliku.

Czy odbiorca potrzebuje konta?

Nie. Odbiorca klika w link, jego przeglądarka odszyfrowuje lokalnie przez Web Crypto API i pobiera plik — bez rejestracji, bez instalacji, bez muru portalu między nim a plikiem.

Wyślij jeden link szyfrowany end-to-end. Niech wygaśnie zgodnie z planem.

Szyfrowanie AES-256-GCM w Twojej przeglądarce. Bez rejestracji, bez plaintextu po stronie serwera, bez backdoora odzyskiwania.

sendUtwórz zaszyfrowany link