Czym jest szyfrowanie po stronie klienta? Przeglądarka robi robotę

Szyfrowanie po stronie klienta oznacza, że Twoja przeglądarka lub aplikacja szyfruje pliki na Twoim urządzeniu, zanim cokolwiek trafi do sieci. Serwer otrzymuje wyłącznie zaszyfrowany tekst — dane wyjściowe AES-256-GCM nieodróżnialne od przypadkowego szumu — a klucz deszyfrujący nigdy nie opuszcza klienta. To przeciwieństwo szyfrowania po stronie serwera, gdzie dostawca posiada klucze i technicznie może odczytać Twoje pliki. Web Crypto API (window.crypto.subtle) umożliwia to w każdej nowoczesnej przeglądarce bez wtyczek, działając z prędkością około 2–3 GB/s na sprzęcie z AES-NI. Usługi takie jak HexaTransfer, SwissTransfer, Tresorit Send i Proton Drive stosują ten model, by zagwarantować prywatność plików nawet w przypadku naruszenia samej usługi.

Przeglądarka jako silnik kryptograficzny

Pięć lat temu prawdziwe szyfrowanie wymagało instalacji aplikacji desktopowej lub użycia PGP z linii poleceń. Web Crypto API, znormalizowane przez W3C w 2017 roku, zmieniło to. Udostępnia AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 i SHA-256 bezpośrednio dla JavaScript działającego w każdej popularnej przeglądarce — Chrome, Firefox, Safari, Edge.

Wydajność przestała być przeszkodą. Instrukcje Intel AES-NI osiągają 3–5 GB/s na rdzeń dla AES-256-GCM. Rozszerzenia kryptograficzne ARM na układach Apple M-series i Qualcomm Snapdragon zapewniają podobną przepustowość. Zaszyfrowanie pliku 1 GB w przeglądarce zajmuje około 300–500 ms na przeciętnym laptopie.

Pozostałym wyzwaniem jest obsługa plików większych niż pamięć przeglądarki. Streams API i ReadableStream pozwalają na przetwarzanie plików w fragmentach 4 MB, szyfrując każdy niezależnie z unikalnym IV w trybie licznikowym. W ten sposób usługi podnoszą limit do 10 GB i więcej.

Minimalny przepływ szyfrowania po stronie klienta

Oto sekwencja, którą uruchamia typowa usługa przeglądarkowa:

// 1. Wygeneruj losowy 256-bitowy klucz AES
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Odczytaj plik w fragmentach
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Zaszyfruj każdy fragment z unikalnym 12-bajtowym IV
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. Prześlij [iv || ciphertext] do serwera
}

// 5. Wyeksportuj klucz i umieść go w fragmencie URL udostępniania
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

Serwer widzi losowo wyglądające bajty, identyfikator pliku i nic więcej. Klucz istnieje tylko w pamięci przeglądarki użytkownika i w fragmencie URL.

Dlaczego to przewyższa szyfrowanie po stronie serwera

Szyfrowanie po stronie serwera oznacza, że dostawca odszyfrowuje na żądanie — by generować miniatury, uruchamiać skanowanie antywirusowe, przetwarzać zapytania wyszukiwania lub odpowiadać na żądania prawne. Ujawnienie Apple z 2023 roku pokazało, że kopie zapasowe iCloud (które nie były zaszyfrowane end-to-end do czasu uruchomienia Advanced Data Protection) były dostępne dla Apple, a zatem dla organów ścigania USA na podstawie ważnych żądań.

Szyfrowanie po stronie klienta odwraca tę sytuację. Ponieważ klucz nigdy nie trafia do dostawcy:

Nieuczciwy pracownik nie widzi nic. Inżynier z dostępem do bazy danych otrzymuje zaszyfrowany tekst.
Nakazy sądowe przynoszą zaszyfrowany tekst. Dostawca może zastosować się do nakazów, przekazując zaszyfrowany blob, który jest bezużyteczny bez klucza.
Naruszenia ujawniają zaszyfrowany tekst. Incydent LastPass z 2021 roku pokazał, że to ma znaczenie — skradzione skarbce były zaszyfrowane, a tylko użytkownicy ze słabymi hasłami głównymi naprawdę ucierpieli.
Awarie dostawcy nie kompromitują danych. Nawet jeśli firma upadnie, Twoja lokalna kopia klucza (URL) nadal odszyfrowuje plik.

Co serwer nadal może widzieć

Szyfrowanie po stronie klienta chroni zawartość pliku, ale nie wszystko. Serwer zazwyczaj obserwuje:

Rozmiar pliku — długość zaszyfrowanego tekstu przybliża długość tekstu jawnego (AES-GCM dodaje 16 bajtów narzutu na szyfrowanie plus 12-bajtowy IV).
Adresy IP przesyłania i pobierania ze znacznikami czasu.
Metadane sesji z uzgadniania TLS, w tym odcisk TLS klienta.
Zaszyfrowane nazwy plików — o ile nie są zawarte w zaszyfrowanym ładunku, mogą wyciekać.

Dobre usługi po stronie klienta szyfrują nazwy plików jako część nagłówka zaszyfrowanego tekstu i stosują dopełnienie do rozmiaru kubełków (1 MB, 10 MB, 100 MB), by zaciemnić rozmiar. Tresorit i Proton Drive explicite dokumentują ekspozycję metadanych.

Szyfrowanie po stronie klienta chronione hasłem

Wiele usług pozwala użytkownikom dodać hasło na szczycie fragmentu URL. Przepływ:

Przeglądarka generuje losową 128-bitową sól i wyprowadza klucz za pomocą PBKDF2-HMAC-SHA-256 z 600 000 iteracji (zalecenie OWASP z 2023 roku) lub Argon2id z memory=64 MB, iterations=3.
Plik jest szyfrowany wyprowadzonym kluczem.
Sól trafia do fragmentu URL; hasło jest komunikowane poza pasmem.
Odbiorca wpisuje hasło, które lokalnie wyprowadza klucz.

To zamienia jednokartowe udostępnianie (URL wystarczy) w dwuczynnikowe: atakujący potrzebuje zarówno łącza, jak i hasła. PBKDF2 z 600 000 iteracji sprawia, że każda próba brute-force kosztuje na nowoczesnym GPU około 10 sekund, więc hasła potrzebują co najmniej 40 bitów entropii, by oprzeć się zdeterminowanym atakującym — myśl o co najmniej 10 znakach z różnorodnego alfabetu.

Przesunięcie zaufania: od usługi do kodu klienta

Szyfrowanie po stronie klienta przesuwa granicę zaufania. Wcześniej ufałeś usłudze, że dobrze obsługuje Twój tekst jawny. Teraz ufasz JavaScript, który usługa dostarcza do Twojej przeglądarki przy każdym ładowaniu strony. Złośliwa aktualizacja mogłaby eksfiltrować klucz przed szyfrowaniem lub w jego trakcie.

Istnieją trzy zabezpieczenia, różniące się rygorem:

Subresource Integrity (SRI) dla tagów script zapewnia, że skrót JS odpowiada znanej wartości.
Audyty kodu przez firmy takie jak Cure53, NCC Group lub Trail of Bits weryfikują, że logika szyfrowania jest prawidłowa.
Odtwarzalne kompilacje pozwalają niezależnym stronom potwierdzić, że dostarczony kod odpowiada opublikowanemu źródłu.
Nagłówki Content Security Policy (CSP) blokują skrypty stron trzecich, które mogłyby manipulować szyfrowaniem.

Najbardziej rygorystyczne podejście, stosowane przez pmcrypto Proton Mail i niektórych klientów opartych na Electron, dostarcza podpisane binaria zamiast świeżego JavaScript przy każdej wizycie. Usługi przeglądarkowe rezygnują z części tego rygoru na rzecz wygody braku instalacji.

Przypadki użycia, gdzie szyfrowanie po stronie klienta błyszczy

Kilka scenariuszy, w których szyfrowanie po stronie klienta jest warte nieco wolniejszego pierwszego ładowania:

Dokumenty prawne i medyczne. HIPAA 45 CFR § 164.312 i tajemnica adwokacka oba znacząco korzystają z architektur, w których dostawca jest ślepy.
Dziennikarstwo i ochrona źródeł. Wysyłanie nieredagowanych dokumentów, gdzie nawet ekspozycja metadanych niesie ryzyko.
Własność intelektualna korporacji. Pakiety zarządu, modele finansowe, materiały M&A, gdzie zagrożenia wewnętrzne u dostawcy transferu plików są realistyczną obawą.
Dokumenty osobiste. Zeznania podatkowe, paszporty, wyniki badań medycznych — pliki, które byłyby krępujące w nagłówku o naruszeniu danych.

Dla plików o niskiej wrażliwości (zdjęcie ze spotkania, przepis kulinarny) tradycyjne szyfrowanie po stronie serwera jest w porządku.

Jak rozpoznać prawdziwe szyfrowanie po stronie klienta

Cztery oznaki, że usługa naprawdę szyfruje po stronie klienta:

Fragmenty URL niosą klucz. Łącze udostępniania zawiera tekst po # wyglądający jak losowe bajty zakodowane w base64.
Przesyłania są zaszyfrowanym tekstem. Otwórz DevTools → Network podczas przesyłania; treść żądania powinna wyglądać jak losowe bajty, a nie nazwa pliku.
Duże pliki nadal działają szybko. Prawdziwy przepływ po stronie klienta strumieniuje fragmenty; nie ponownie przesyła przez bramkę szyfrowania po stronie serwera.
Polityka prywatności mówi „nie możemy odszyfrować Twoich plików". Połączone z technicznym białym papierem, a nie samym marketingiem.

Usługi spełniające te kryteria: poziom E2EE SwissTransfer, Tresorit Send, wspólne łącza Proton Drive, Mega.nz i HexaTransfer. Niespełniające: WeTransfer (standard), Google Drive, łącza udostępniania Dropbox.

Sprawdzenie w praktyce

Jeśli chcesz wypróbować szyfrowanie po stronie klienta, otwórz DevTools i obserwuj zakładkę Network podczas przesyłania pliku. Powinieneś zobaczyć zaszyfrowany blob trafiający do serwera i klucz w pasku URL, który nigdy nie pojawia się w żadnym żądaniu. To cała obietnica.

Wypróbuj na hexatransfer.com — bezpłatnie, bez konta, do 10 GB.