Zero-knowledge · Udostępnianie PDF

Udostępnianie PDF zero-knowledge, wyjaśnione rzetelnie.

Termin „szyfrowane end-to-end" bywa nadużywany. Oto faktyczny mechanizm kryptograficzny stojący za linkiem zero-knowledge do PDF — AES-256-GCM, zarządzanie kluczem, tryb fragmentu vs tryb hasła oraz to, czego serwer dosłownie nie może zrobić.

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

sendWyślij link zero-knowledge Jak to działa

Co tutaj oznacza „zero-knowledge"

Użyteczna definicja, oczyszczona z marketingu: usługa przechowująca udostępniany plik nie posiada żadnych informacji — kryptograficznych ani operacyjnych — których można by użyć do jego odszyfrowania. Klucz nigdy nie dotyka serwera, dlatego serwer nie może go ujawnić w żadnych okolicznościach.

memory

Szyfrowanie odbywa się w Twojej przeglądarce

Nie na serwerze, nie w nadzorowanym przez nas workerze — w Twojej karcie, przez window.crypto.subtle. Można to zweryfikować w DevTools.

cloud_off

Wysyłany jest wyłącznie szyfrogram

Treść żądania to szyfrogram AES-256-GCM. PDF, nazwa pliku ani metadane nigdy nie trafiają na serwer w czytelnej postaci.

vpn_key

Klucz wędruje z odbiorcą

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

block

Brak odzyskiwania = brak tylnych furtek

Zgubiłeś link, zapomniałeś hasła? Plik znika na zawsze. Zero-knowledge oznacza brak ścieżki odzyskiwania, która osłabiłaby gwarancję.

Jak powstaje link zero-knowledge do PDF

Dokładny opis tego, co robi przeglądarka nadawcy, serwer i przeglądarka odbiorcy — z prawdziwymi 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 vs tryb hasła

Dwa sposoby przekazania klucza odbiorcy. Ta sama gwarancja szyfrogramu, inne kompromisy między wygodą a ryzykiem wycieku.

Tryb fragmentu

Klucz wędruje w skrócie URL (`#`)

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

Dla odbiorcy jeden krok — kliknij link.
Niski próg, odpowiedni dla niskiej i średniej wrażliwości.
Ryzyko: jeśli link wycieknie w zrzucie ekranu lub przez synchronizację przeglądarki, plik wycieknie razem z nim.
Stosuj, gdy ufasz kanałowi (komunikator z podpisami, wewnętrzny czat).

Tryb hasła

Klucz wyprowadzony z hasła (PBKDF2)

Nadawca wybiera hasło. Przeglądarka wyprowadza 256-bitowy klucz przez PBKDF2-SHA256 z 310 000 iteracji na 128-bitowej, losowej soli. Sól jest przechowywana po stronie serwera; hasło przekazywane jest poza serwisem (telefon, Signal, osobiście).

Udostępnianie dwuczynnikowe: link i hasło podróżują osobno.
Sam link nie wystarcza — szyfrogram pozostaje nieczytelny.
Siła hasła ma znaczenie: 310 000 iteracji spowalnia atak siłowy, ale nie ratuje 6-znakowego hasła.
Stosuj, gdy link może zostać przekazany dalej lub przechowany w niezbyt zaufanym miejscu.

Cecha	Tryb fragmentu	Tryb hasła
Nośnik klucza	Skrót URL (`#`)	Hasło + sól
Czy serwer kiedykolwiek widzi klucz	Nie	Nie
Co przechowuje serwer	Szyfrogram + IV	Szyfrogram + IV + sól
Próg dla odbiorcy	Kliknij link	Kliknij link + wpisz hasło
Wyciek przez zrzut ekranu	Tak (link = klucz)	Nie (sam link jest bezużyteczny)
Odporność na atak siłowy	256-bit losowe	Zależy od hasła
Najlepsze zastosowanie	Niskoprogowe udostępnianie zaufanymi kanałami	Udostępnianie wyższej wrażliwości

Dlaczego szyfrogram przechowywany na serwerze nadal Cię chroni

Częste pytanie: „Jak to jest prywatne, skoro leży na Waszym serwerze?". Odpowiedź: szyfrogram nie jest plikiem. Bez klucza to po prostu losowo wyglądające bajty. Co to oznacza w praktyce.

storage

Naruszenie bazy = wyciek szyfrogramu

Jeśli atakujący przejmie naszą bazę danych, wychodzi z niej z nieprzejrzystymi bajtami. Odzyskanie pojedynczego pliku wymagałoby złamania 256-bitowego klucza siłowo — niemożliwe w ramach znanych praw fizyki.

gavel

Wezwanie sądowe daje szyfrogram

Sąd może nakazać nam wydanie tego, co posiadamy. To, co posiadamy, to szyfrogram. Nakaz sądowy nie wytworzy retroaktywnie klucza, którego nigdy nie przechowywaliśmy.

group

Dostęp wewnętrzny staje się bezużyteczny

Nawet nielojalny pracownik z pełnymi uprawnieniami do bazy danych nie odczyta plików. Gwarancja jest egzekwowana matematyką, a nie kontrolą dostępu.

timer

Wygasanie wzmacnia gwarancję

Szyfrogram zostaje usunięty po wygaśnięciu (24 godziny w planie bezpłatnym, do 30 dni w planie Pro). Potem znika nawet sam szyfrogram — jedyna kopia pliku znajduje się tam, gdzie został odszyfrowany.

warningUczciwe ograniczenia

Zero-knowledge nie rozwiązuje problemu bezpieczeństwa urządzenia końcowego. Złośliwe oprogramowanie na komputerze nadawcy lub odbiorcy może wykraść klucz z pamięci. Skompromitowane rozszerzenie przeglądarki może odczytać już odszyfrowany plik. A link przekazany dalej w czacie grupowym unieważnia każdą kryptograficzną gwarancję. Architektura podnosi koszt naruszenia; nie eliminuje całego ryzyka.

Zero-knowledge vs inne „bezpieczne" opcje

Klarowne porównanie typowych sposobów udostępniania PDF. Wiele opcji oznaczonych jako „bezpieczne" zapewnia szyfrowanie w trakcie przesyłu, ale nie jest zero-knowledge.

Opcja	TLS w transporcie	Czy serwer może odczytać plik	Wygasanie	Konto odbiorcy
Załącznik e-mail	Zwykle tak	Tak — na każdym etapie	Bezterminowo	Niewymagane
Publiczny link chmurowy	Tak	Tak	Opcjonalne	Czasem
PDF chroniony hasłem	Tak	Tak (jeśli plik jest na hostingu)	Nigdy	Niewymagane
PDF Pro (tryb fragmentu)	Tak	Nie	24 h / 30 dni	Niewymagane
PDF Pro (tryb hasła)	Tak	Nie	24 h / 30 dni	Niewymagane

Powiązane lektury

Najczęściej zadawane pytania

Co tak naprawdę oznacza udostępnianie PDF zero-knowledge?

Oznacza, że serwer przechowujący udostępniany plik dosłownie nie jest w stanie go odszyfrować. Klucz szyfrujący jest generowany w przeglądarce nadawcy, nigdy nie zostaje przesłany, a odtworzyć go może wyłącznie przeglądarka odbiorcy — z fragmentu URL albo z hasła przekazanego nadawcą poza serwisem. Gwarancję egzekwuje kryptografia, a nie polityka kontroli dostępu, którą moglibyśmy zmienić.

Jakiego szyfrowania używa PDF Pro w udostępnianiu zero-knowledge?

Symetryczne szyfrowanie AES-256-GCM z 96-bitowym, losowym wektorem inicjującym dla każdego pliku. W trybie hasła klucze są wyprowadzane przy użyciu PBKDF2-SHA256 z 310 000 iteracji na 128-bitowej, losowej soli. Cała kryptografia działa w natywnym Web Crypto API przeglądarki.

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

Tryb fragmentu umieszcza 256-bitowy klucz w skrócie URL (po #), a przeglądarki nigdy nie wysyłają tego na żaden serwer. Każdy, kto ma pełny link, może odszyfrować plik. Tryb hasła wyprowadza klucz z hasła wybranego przez nadawcę; szyfrogram pozostaje bez niego nieczytelny. Tryb hasła jest bezpieczniejszy, gdy link może wyciec; tryb fragmentu jest wygodniejszy w niskoprogowym udostępnianiu. Zobacz tabelę porównawczą powyżej.

Czy fragment URL naprawdę jest bezpiecznym nośnikiem klucza szyfrującego?

Zgodne ze standardami przeglądarki nigdy nie przesyłają na serwer części fragmentu URL (po #). Pozostaje on po stronie przeglądarki i widoczny jest wyłącznie dla JavaScriptu działającego w karcie odbiorcy. To właśnie sprawia, że sam link do udostępniania pełni rolę poświadczenia deszyfrującego — klucz wędruje z odbiorcą, nie z wysyłką. Możesz to potwierdzić w karcie Sieć przeglądarki: URL żądania jest obcinany na ? lub #.

Czy PDF Pro lub sąd może odczytać pliki zapisane w trybie zero-knowledge?

Nie. Serwer przechowuje szyfrogram AES-256-GCM oraz wektor inicjujący (a w trybie hasła także sól). Bez klucza, którego nigdy nie otrzymaliśmy, dane są kryptograficznie nieodróżnialne od losowych bajtów. Możemy ujawnić tylko to, co posiadamy — szyfrogram.

Co się stanie, gdy stracę link lub zapomnę hasła?

Plik jest trwale nieodzyskiwalny. Tak zostało to zaprojektowane — zero-knowledge oznacza brak ścieżki odzyskiwania, ponieważ taka ścieżka wymagałaby przechowywania klucza. Zapisz hasło w menedżerze haseł, a link przechowuj w trwałym miejscu.

Czy udostępnianie PDF zero-knowledge jest darmowe?

Tak. Bezpłatny plan obsługuje szyfrowanie AES-256-GCM bez konieczności rejestracji i 24-godzinny czas wygasania linków. Limit pliku w planie bezpłatnym to około 25 MB na transfer; plan Pro wydłuża czas wygasania do 30 dni i podnosi limity rozmiaru pliku.

Czy odbiorca potrzebuje konta?

Nie. Odbiorca klika link, jego przeglądarka odszyfrowuje plik lokalnie za pomocą Web Crypto API i pobiera dokument — bez rejestracji, bez instalacji, bez ściany rejestracyjnej między nim a plikiem.

Wyślij link zero-knowledge. Niech wygaśnie zgodnie z harmonogramem.

Szyfrowanie AES-256-GCM w Twojej przeglądarce. Bez rejestracji, bez jawnego tekstu po stronie serwera, bez tylnej furtki do odzyskiwania.

sendUtwórz zaszyfrowany link