Jak działa szyfrowanie end-to-end w transferze plików
Zrozum, jak szyfrowanie end-to-end chroni Twoje pliki podczas transferu. Techniczne omówienie protokołów kryptograficznych i ich implementacji.
Szyfrowanie end-to-end w transferze plików oznacza, że bajty opuszczające Twoje urządzenie są szyfrowane kluczem, który nigdy nie dotyka serwera — i tylko zamierzony odbiorca może je odszyfrować. Według UODO naruszenie poufności danych osobowych wynikające ze stosowania jedynie szyfrowania serwerowego może skutkować karami z art. 83 RODO, nawet jeśli dostawca usług twierdzi, że dane są „zaszyfrowane". Serwer przechowuje wyłącznie szyfrogramy, niczego sensownego nie widzi i mógłby zostać zhakowany bez ujawnienia zawartości Twoich plików. Receptura kryptograficzna niemal zawsze obejmuje szyfr symetryczny jak AES-256-GCM lub XChaCha20-Poly1305 dla samego pliku, opakowany wymianą klucza taką jak X25519 ECDH lub RSA-OAEP dla materiału kluczowego.
Model zagrożeń, przed którym faktycznie broni szyfrowanie E2EE
Szyfrowanie E2EE chroni konkretnie przed: atakiem hakerów na dostawcę transferu, nakazami sądowymi, złośliwymi pracownikami, napastnikami sieciowymi przechwytującymi ruch po deszyfrowaniu TLS na serwerach proxy, kopiami zapasowymi zasobnika storage trafiającymi w niepowołane ręce oraz dostępem wewnętrznym pracowników usługi. Nie chroni przed złośliwym oprogramowaniem na urządzeniu nadawcy lub odbiorcy, phishingiem przechwytującym link deszyfrujący ani przejętymi kontami odbiorcy. Rozróżnienie to ma znaczenie, ponieważ słowo „szyfrowanie" jest często nadużywane w znaczeniu „TLS podczas transmisji plus AES-at-rest na serwerze", co pozostawia dostawcę w posiadaniu kluczy.
Szyfrowanie symetryczne dla ładunku pliku
Pliki są szyfrowane algorytmem symetrycznym, bo kryptografia klucza publicznego jest zbyt wolna dla dużych ilości danych. Nowoczesnym wyborem jest AES-256-GCM, zdefiniowany w NIST SP 800-38D, zapewniający zarówno poufność, jak i uwierzytelnioną integralność w jednym przebiegu. Losowy 256-bitowy klucz i unikalny 96-bitowy nonce (nigdy nieużywany z tym samym kluczem) chronią każdy plik. XChaCha20-Poly1305, zdefiniowany w RFC 8439, stanowi alternatywę, która jest często szybsza na urządzeniach bez sprzętowego przyspieszenia AES-NI. Obydwa algorytmy produkują szyfrogram plus 128-bitowy znacznik uwierzytelniania wykrywający jakiekolwiek manipulacje.
Derywacja klucza z hasła
Gdy szyfrowanie E2EE używa hasła, samo hasło nigdy nie jest kluczem szyfrowania — byłoby zbyt słabe wobec ataków brute force. Zamiast tego funkcja derywacji klucza jak PBKDF2-HMAC-SHA256 z co najmniej 600 000 iteracjami (wytyczne OWASP 2025), Argon2id z m=19 MiB i t=2 (RFC 9106) lub scrypt (RFC 7914) rozciąga hasło w silny klucz. Losowa sól 128-bitowa lub 256-bitowa zapobiega atakom tęczowych tablic. Wynikowy klucz szyfruje plik. Sól i liczba iteracji są przechowywane wraz z szyfrogramem, by odbiorca mógł odtworzyć klucz po wpisaniu hasła.
Opakowanie kluczem publicznym dla transferów z kontami
Gdy odbiorcy mają konta z opublikowanymi kluczami publicznymi, nie jest potrzebne wprowadzanie hasła. Nadawca generuje losowy klucz szyfrowania pliku (FEK), szyfruje plik za pomocą AES-256-GCM, a następnie szyfruje FEK kluczem publicznym odbiorcy przy użyciu uzgodnienia klucza X25519 ECDH zgodnie z RFC 7748 w połączeniu z HKDF-SHA256 zgodnie z RFC 5869. Zapakowany FEK leży obok szyfrogramu. Tylko posiadacz prywatnego klucza odbiorcy może rozpakować FEK i odszyfrować plik.
Szyfrowanie E2EE oparte na linkach z fragmentami URL
Sprytna sztuczka w transferze opartym na przeglądarce to przechowywanie klucza deszyfrowania w fragmencie URL (części po znaku #). Fragmenty nigdy nie są wysyłane do serwera w żądaniu HTTP. Link jak https://example.com/d/abc123#k=B9kZtR... niesie identyfikator pliku po stronie serwera, a klucz po stronie klienta. Przeglądarka pobiera szyfrogram, odczytuje fragment w JavaScript i odszyfrowuje lokalnie. Usługa nigdy nie widzi klucza. Zastrzeżenie: jeśli link wycieknie — w logach, zrzutach ekranu, podglądach linków w komunikatorach — klucz wycieka razem z nim.
Integralność za pomocą AEAD i skrótów
Tryby Authenticated Encryption with Associated Data (AEAD), takie jak GCM i ChaCha20-Poly1305, zapobiegają manipulacjom. Pojedyncze przekręcenie bitu w szyfrgramie powoduje niepowodzenie walidacji znacznika uwierzytelniania, a funkcja deszyfrowania zwraca błąd zamiast błędnych danych. Wiele implementacji oblicza dodatkowo skrót SHA-256 lub BLAKE3 oryginalnego tekstu jako wpis manifestu, by odbiorca mógł po odszyfrowaniu zweryfikować, że plik odpowiada temu, co zamierzał nadawca. Ma to znaczenie dla dużych plików przesyłanych w chunkach.
Szyfrowanie w chunkach dla dużych plików
Szyfrowanie 10 GB pliku jedną operacją AES-GCM wymaga utrzymania 10 GB stanu, co jest niepraktyczne w przeglądarkach. Rzeczywiste implementacje dzielą plik na chunki, zazwyczaj o wielkości 1 MB do 16 MB, i szyfrują każdy chunk niezależnie z pochodnym podkluczem i nonce opartym na liczniku. Granice chunków pozwalają też przeglądarkom strumieniować deszyfrowanie za pośrednictwem Streams API, zaczynając pobieranie na dysk zanim dotrze cały plik, i obsługiwać wznawialne uploady przy przerwach sieciowych.
Bezpieczeństwo transportu na szczycie E2EE
TLS 1.3 zdefiniowany w RFC 8446 ma nadal znaczenie ponad E2EE — nie dla poufności ładunku (który jest już zaszyfrowany), ale dla prywatności metadanych: nazw plików, rozmiarów i czasowania. TLS 1.3 z wymianą klucza z doskonałą tajemnicą przekazywania, jak X25519, oznacza, że nawet jeśli długoterminowy klucz serwera zostanie później ujawniony, zarejestrowane sesje nie dadzą się odszyfrować. TLS 1.3 plus szyfrowanie end-to-end chronią zarówno zawartość pliku, jak i wzorzec operacyjny — kto wysyła co do kogo.
Typowe błędy implementacyjne
Trzy błędy powtarzają się regularnie. Po pierwsze, ponowne użycie nonce z tym samym kluczem w AES-GCM katastrofalnie łamie poufność — zawsze używaj świeżego losowego nonce lub licznika, który nigdy się nie powtarza. Po drugie, implementacja kryptografii własnoręcznie zamiast z użyciem audytowanych bibliotek jak libsodium, Web Crypto API (SubtleCrypto) lub BoringSSL — operacje stałoczasowe mają znaczenie, by zapobiec atakom czasowym. Po trzecie, brak uwierzytelniania metadanych pliku razem z zawartością — jeśli tożsamość nadawcy, nazwa pliku lub lista odbiorców nie są w AAD, napastnik może niezauważenie podmienić metadane. HexaTransfer eliminuje te ryzyka, używając standardowych prymitywów Web Crypto po stronie klienta z przejrzanymi wzorcami.
Weryfikacja, czy usługa faktycznie stosuje E2EE
Czytaj twierdzenia marketingowe krytycznie. Prawdziwe E2EE oznacza, że dostawca nie może odszyfrować plików nawet pod przymusem nakazu sądowego. Szukaj opublikowanej dokumentacji technicznej opisującej dokładne algorytmy (AES-256-GCM, X25519, HKDF, liczby iteracji PBKDF2), kodu klienta dostępnego jako open source do audytu, i modelu zagrożeń, który przyznaje, przed czym E2EE chroni, a przed czym nie. Usługi oferujące serwerowe odzyskiwanie hasła dla zaszyfrowanych plików nie stosują prawdziwego E2EE — posiadają klucze.
Wypróbuj bezpłatnie na hexatransfer.com — bez konta, maksymalnie 10 GB.
Wysyłaj duże pliki bezpiecznie z szyfrowaniem end-to-end
Przesyłaj pliki do 10 GB za darmo z szyfrowaniem end-to-end. Bez rejestracji. Twoje pliki są szyfrowane w przeglądarce przed przesłaniem — nikt inny nie może ich odczytać.
Wyślij plik