Szyfrowanie end-to-end wyjaśnione: poradnik dla początkujących

Szyfrowanie end-to-end (E2EE) oznacza, że plik jest szyfrowany na Twoim urządzeniu kluczem, który może odtworzyć wyłącznie odbiorca. Usługa transferu przesyła zaszyfrowany tekst, ale nigdy nie posiada klucza deszyfrującego — pracownicy, hakerzy i nakazy sądowe nie mogą odczytać zawartości. W praktyce przeglądarka generuje losowy 256-bitowy klucz AES, szyfruje plik lokalnie, przesyła zaszyfrowany tekst i umieszcza klucz w łączu udostępniania po znaku # — który przeglądarki nigdy nie wysyłają do serwera. To cały mechanizm, oddzielający prawdziwą prywatność od marketingowych sloganów.

Co tak naprawdę oznacza „end-to-end"

Dwa „końce" to Ty i Twój odbiorca. Wszystko pomiędzy — routery dostawcy internetu, krawędzie CDN, serwery firmy transferowej, ISP odbiorcy — znajduje się pośrodku. Dzięki E2EE te pośrednie węzły widzą tylko zaszyfrowane bajty. Porównaj to z samym szyfrowaniem warstwy transportowej (TLS): TLS chroni dane od Twojej przeglądarki do serwera, następnie serwer je odszyfrowuje, przechowuje jako czysty tekst i ponownie szyfruje przy pobieraniu przez odbiorcę. Standardowy poziom WeTransfer działa właśnie w ten sposób — firma może i zgodnie z prawem USA oraz UE czasem musi przekazać pliki na żądanie.

Dzięki E2EE nawet jeśli prokurator wyda dostawcy nakaz, dostawca nie ma nic do przekazania poza losowo wyglądającymi bajtami. Ta właściwość sprawia, że dziennikarze, prawnicy i lekarze coraz częściej na nim nalegają.

Dlaczego sam TLS nie wystarcza

TLS 1.3 doskonale spełnia swoje zadanie: uniemożliwia atakującemu w kawiarni lub nieuczciwemu ISP podsłuchanie połączenia. Jednak TLS kończy się na serwerze. Gdy szyfrowany tunel dobiega końca, serwer przetwarza surowy plik. Jeśli ten serwer zostanie naruszony — jak miało to miejsce z Dropboxem w 2022 roku, gdy wyciekł kod źródłowy i część danych klientów — TLS nie oferuje żadnej ochrony dla plików przechowywanych w pamięci.

E2EE dodaje drugą warstwę, która przetrwa naruszenie serwera. Plik jest szyfrowany przed dotknięciem sieci i pozostaje zaszyfrowany, dopóki przeglądarka odbiorcy go nie odszyfruje. Nawet kompletny zrzut bazy danych ujawni tylko zaszyfrowany tekst i metadane.

Problem wymiany kluczy — rozwiązany

Trudną częścią E2EE jest dostarczenie klucza odbiorcy bez tego, żeby serwer go zobaczył. Nowoczesne usługi przeglądarkowe rozwiązują to za pomocą sztuczki z fragmentem URL. Łącze udostępniania wygląda tak:

https://hexatransfer.com/download/abc123#k=klucz-256-bitowy-base64

Przeglądarki traktują wszystko po # jako fragment po stronie klienta. Gdy klikasz łącze, serwer otrzymuje tylko /download/abc123 w żądaniu HTTP — fragment nigdy nie opuszcza przeglądarki. JavaScript odczytuje klucz z fragmentu, pobiera zaszyfrowany tekst i odszyfrowuje go lokalnie za pomocą metody crypto.subtle.decrypt() z Web Crypto API.

Jest to prostsze niż wymiana kluczy RSA lub Diffie-Hellman i działa dla każdego posiadającego przeglądarkę. Kompromis: każda osoba, która zdobędzie łącze, zdobędzie plik — nadal musisz udostępniać łącza przez bezpieczny kanał (Signal, osobiście, zaszyfrowana poczta).

Co serwer widzi, a czego nie może

Przy prawidłowo zaimplementowanym E2EE logi serwera zwykle zawierają: losowy identyfikator pliku, rozmiar zaszyfrowanego tekstu, adres IP przesyłania, znacznik czasu przesyłania oraz skrót SHA-256 zaszyfrowanego tekstu do deduplikacji. Serwer nie widzi: nazwy pliku, zawartości pliku, tożsamości odbiorcy ani klucza deszyfrującego. Nazwy plików są często szyfrowane wraz z zawartością i przechowywane jako część nagłówka zaszyfrowanego tekstu.

Przydatny test: zapytaj dostawcę, co przekażą na podstawie nakazu sądowego. Uczciwa usługa E2EE powie „zaszyfrowane bloki i logi IP". Jeśli mogą dostarczyć pliki jako czysty tekst, szyfrowanie nie jest end-to-end.

Algorytmy działające w tle

Rzeczywiste stosy E2EE zbiegają się na krótkiej liście dobrze zaudytowanych elementów:

AES-256-GCM do masowego szyfrowania plików. GCM zapewnia zarówno poufność, jak i uwierzytelnienie, więc naruszony zaszyfrowany tekst nie zostanie odszyfrowany, zamiast generować błędne dane.
PBKDF2 z co najmniej 100 000 iteracji lub Argon2id do wyprowadzania kluczy z haseł użytkownika, gdy dodawana jest ochrona hasłem.
SHA-256 do skrótów integralności.
TLS 1.3 jako zewnętrzny transport, ponieważ wielowarstwowa ochrona jest tania.

Unikaj usług nadal używających AES-CBC bez HMAC (podatne na manipulacje), MD5 lub SHA-1 (złamane) lub PBKDF2 z mniej niż 10 000 iteracji (podatne na atak brute-force na nowoczesnych GPU).

E2EE dla transferu plików a dla komunikatorów

Signal spopularyzował E2EE dla czatu za pomocą protokołu Double Ratchet, który rotuje klucze po każdej wiadomości dla zachowania tajemnicy przekazywania. Transfer plików nie wymaga takiej złożoności, ponieważ jest jednorazowy — nie utrzymujesz trwającej rozmowy. Jeden symetryczny klucz na plik, generowany od nowa przy każdym przesyłaniu, jest zarówno prostszy, jak i łatwiejszy do audytu.

Czego transfer plików potrzebuje, a komunikatory nie: przesyłania podzielonego na fragmenty z możliwością wznowienia (pliki mogą mieć 10 GB), weryfikacji integralności między fragmentami oraz łączy działających bez konta odbiorcy. Tresorit, Proton Drive, SwissTransfer i HexaTransfer stosują to podejście z drobnymi różnicami.

Weryfikacja, czy usługa jest naprawdę end-to-end

Cztery praktyczne testy przed zaufaniem dostawcy:

Otwórz DevTools → Network podczas przesyłania małego pliku. Jeśli widzisz czysty tekst w treści żądania, nie jest zaszyfrowany po stronie klienta.
Poszukaj klucza w fragmencie URL (po #). Brak klucza fragmentu zwykle oznacza, że serwer go posiada.
Przeczytaj politykę prywatności pod kątem sformułowań takich jak „nie możemy uzyskać dostępu do Twoich plików" w połączeniu z technicznym opisem przyczyny.
Sprawdź, czy kod klienta jest audytowalny — open source lub przynajmniej udokumentowany. Zamknięte binaria z deklaracjami E2EE są sygnałem ostrzegawczym.

Usługi, które przechodzą wszystkie cztery testy: SwissTransfer (poziom z szyfrowaniem po stronie klienta), Tresorit Send, łącza udostępniania Proton Drive i HexaTransfer.

Czego E2EE nie chroni

E2EE to nie magia. Nie chroni przed:

Zagrożonym punktem końcowym. Jeśli Twój laptop ma złośliwe oprogramowanie, atakujący odczytuje pliki przed szyfrowaniem.
Wyciekiem łącza udostępniania. Każda osoba z łączem może pobrać i odszyfrować plik.
Słabymi hasłami przy transferach chronionych hasłem. PBKDF2 spowalnia brute-force, ale „lato2024" nadal pada w sekundy.
Korelacją metadanych. Znaczniki czasu, rozmiary plików i adresy IP nadal mogą wiele powiedzieć.

Połącz E2EE z wygasającymi łączami (24 godziny to rozsądna wartość domyślna), limitami pobierania (często 1–10 pobrań) i silnymi hasłami dla wrażliwych transferów.

Sprawdzenie w praktyce

Dla szybkiej weryfikacji: prześlij testowy plik 5 MB, otwórz łącze udostępniania w oknie prywatnym bez fragmentu (usuń wszystko po #) i spróbuj pobrać. Prawdziwa usługa E2EE nie odszyfruje pliku. Jeśli plik otworzy się mimo to, serwer od początku posiadał klucz.

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