Metody szyfrowania plików w transferze: porównanie

Usługi transferu plików stosują w 2026 roku pięć głównych podejść kryptograficznych: wyłącznie TLS (dane szyfrowane w tranzycie, ale przechowywane w postaci jawnej na serwerze), serwerowy AES-256 w spoczynku (dostawca posiada klucze), klientowy AES-256-GCM przez Web Crypto API (end-to-end, klucz we fragmencie URL), XChaCha20-Poly1305 (rozszerzone nonce, stosowany przez libsodium i Tresorit) oraz szyfrowanie hybrydowe OpenPGP (Curve25519 ECC plus klucze sesji AES-256, stosowany przez Proton). Właściwy wybór zależy od modelu zagrożenia, ograniczeń wydajnościowych i wymogów regulacyjnych. To porównanie wyjaśnia, co każda metoda robi i gdzie zawodzi.

Pięć modeli szyfrowania

Model pierwszy: wyłącznie TLS 1.3. Plik jest szyfrowany podczas transmisji sieciowej, a następnie przechowywany na serwerze w postaci jawnej. Przykłady: podstawowy FTP przez TLS (FTPS), dowolny upload HTTP POST bez szyfrowania w spoczynku. Chroni przed pasywnym podsłuchem sieciowym, przed niczym innym.

Model drugi: TLS plus serwerowy AES-256 w spoczynku. AES-256 szyfruje przechowywany plik; dostawca posiada klucz główny (często w AWS KMS, GCP Cloud KMS lub odpowiedniku). Przykłady: WeTransfer, SwissTransfer, Dropbox. Chroni przed kradzieżą z cold storage, nie chroni przed dostępem insajdera, nakazem sądowym ani kompromitacją żywego serwera.

Model trzeci: klientowy E2EE z kluczem symetrycznym. Przeglądarka lub klient generuje 256-bitowy klucz, szyfruje za pomocą AES-256-GCM i umieszcza klucz we fragmencie URL lub kanale out-of-band. Przykłady: HexaTransfer, potomkowie protokołu Firefox Send. Serwer widzi wyłącznie zaszyfrowany tekst i nie może odszyfrować go pod żadnym warunkiem.

Model czwarty: uwierzytelnione szyfry strumieniowe. XChaCha20-Poly1305 używa 24-bajtowych nonce (wobec 12-bajtowych w ChaCha20-Poly1305), co sprawia, że kolizje ograniczenia urodzinowego są niewykonalne dla bardzo dużych plików. Przykłady: libsodium secretbox (Internxt), Tresorit Send. Wybierany, gdy akceleracja sprzętowa AES-NI nie jest powszechna (starsze urządzenia Android, IoT), bo ChaCha20 działa szybko w oprogramowaniu.

Model piąty: hybrydowy klucz publiczny plus symetryczny. OpenPGP (RFC 9580, aktualizacja 2024) używa ECC Curve25519 lub RSA-4096 do szyfrowania klucza sesji AES-256 dla każdego pliku. Przykłady: Proton Drive, tradycyjne szyfrowanie GPG. Umożliwia asymetryczne zarządzanie kluczami; nie potrzeba wspólnego sekretu między nadawcą a odbiorcą, jeśli posiadamy klucz publiczny odbiorcy.

AES-256 kontra ChaCha20: co naprawdę się różni

Oba to 256-bitowe szyfry symetryczne. AES-256 jest standardem NIST (FIPS 197) i ma akcelerację sprzętową (AES-NI na x86, ARM Cryptography Extensions na urządzeniach mobilnych). Na nowoczesnym sprzęcie AES-256-GCM działa z prędkością 2-4 GB/s na rdzeń. ChaCha20-Poly1305 w czystym oprogramowaniu osiąga 1-2 GB/s na rdzeń, czyli szybciej niż AES na sprzęcie bez AES-NI. Dla laptopa szyfrującego plik 4 GB oba kończą w mniej niż dwie sekundy — wąskim gardłem jest sieć. Kryptograficznie oba są uważane za jednakowo bezpieczne w 2026 roku.

RSA jest w dużej mierze martwy w transferze plików

RSA-4096 szyfruje 512 bajtów tekstu jawnego na operację. Bezpośrednie użycie RSA do szyfrowania pliku 1 GB jest absurdalne — trzeba by go podzielić na miliony 512-bajtowych bloków. Wzorzec jest zawsze hybrydowy: RSA opakowuje klucz sesji AES-256 per plik, AES szyfruje zawartość. ECC Curve25519 wyparła RSA w większości nowych projektów: jest szybsza, ma mniejsze klucze (256-bitowy ECC odpowiada bezpieczeństwu 3072-bitowego RSA) i jest odporna na ataki czasowe. OpenPGP w 2024 roku rekomenduje teraz Curve25519 (X25519 do wymiany kluczy) zamiast RSA. RSA nadal spotyka się w starszych wdrożeniach SFTP.

Dlaczego klucze we fragmencie URL mają znaczenie

HexaTransfer i protokół Firefox Send umieszczają klucz szyfrowania we fragmencie URL (część po znaku #). Przeglądarki zgodnie ze specyfikacją (RFC 3986) nigdy nie przesyłają fragmentów w żądaniu HTTP. Oznacza to, że serwer otrzymuje żądanie GET /plik/abc123, lecz nigdy nie widzi fragmentu zawierającego klucz. Gdy użytkownik wkleja lub klika pełny URL, fragment pozostaje w pamięci przeglądarki i zasila odszyfrowanie po stronie klienta. To architektonicznie elegancki sposób dostarczenia udostępnialnego linku E2EE bez kanału pomocniczego.

End-to-end kontra serwerowe: test modelu zagrożenia

Szyfrowanie serwerowe chroni przed jednym scenariuszem: fizyczną kradzieżą urządzenia przechowującego. Jeśli dysk zostanie skradziony, AES-256 w spoczynku utrzymuje dane nieprzejrzyste do momentu kompromitacji KMS. Szyfrowanie end-to-end chroni przed wszystkim, co serwer może zrobić: nakazem sądowym, dostępem insajdera, ransomwarem atakującym żywe dane czy przymusem ze strony państwa. Jeśli model zagrożenia to „dysk skradziony z centrum danych" — serwerowe wystarczy. Jeśli to „rząd, przeciwnik lub konkurent zmusza usługę do wydania danych" — chroni tylko E2EE.

Uwierzytelnione szyfrowanie jest obowiązkowe

Zwykły AES-CBC bez MAC umożliwia ataki padding oracle (BEAST, Lucky13), które mogą odszyfrować zaszyfrowany tekst za pomocą zapytań z wybranym szyfrogramem. Nowoczesny transfer plików musi używać AEAD: AES-256-GCM (NIST SP 800-38D) lub ChaCha20-Poly1305 (RFC 8439). Znacznik Poly1305 lub GCM uwierzytelnia zaszyfrowany tekst i wszelkie dane towarzyszące (rozmiar pliku, nonce, nagłówek nazwy pliku). Jeśli bit ulegnie zmianie podczas transmisji, odszyfrowanie głośno zawiedzie. Każdy, kto nadal stosuje AES-CBC bez opakowania HMAC w 2026 roku, żyje w roku 2010.

Derywacja kluczy dla transferów chronionych hasłem

Gdy użytkownik wpisuje hasło do ochrony transferu, nie można użyć go bezpośrednio jako klucza AES — ma niską entropię i jest podatne na atak brute-force. Nowoczesna derywacja kluczy: PBKDF2-SHA-256 z 600 000 iteracji (rekomendacja OWASP z 2023), scrypt z N=2^17 lub Argon2id z pamięcią 19 MiB i 2 iteracjami. HexaTransfer używa PBKDF2 z 600 000 iteracji. Tresorit używa Argon2id. Oba opierają się łamaniu haseł akcelerowanym przez GPU. Dostawcy stosujący nadal PBKDF2 z 10 000 iteracji (wytyczne z 2015 roku) mają niewystarczające zabezpieczenia.

Tabela porównawcza

| Metoda | Poufność | Uwierzytelnianie | Serwer widzi tekst jawny | Kwestia kwantowa | |---|---|---|---|---| | Wyłącznie TLS 1.3 | W tranzycie | Tak (MAC w zestawie szyfr.) | Tak | Wymiana kluczy zagrożona | | Serwerowy AES-256 | W spoczynku i tranzycie | Tak | Tak (posiada klucz) | Niskie | | Klientowy AES-256-GCM | Pełna droga | Tak (znacznik GCM) | Nie | Niskie | | XChaCha20-Poly1305 | Pełna droga | Tak (znacznik Poly1305) | Nie | Niskie | | OpenPGP (Curve25519 + AES-256) | Pełna droga | Tak (MDC/OCB) | Nie | Curve25519 zagrożona |

Rozważania post-kwantowe

Algorytm Shora zagraża Curve25519 i RSA po pojawieniu się dużych komputerów kwantowych. Szyfry symetryczne (AES-256, ChaCha20) są osłabiane, lecz nie łamane przez algorytm Grovera; 256-bitowe klucze zachowują post-kwantową siłę 128-bitową — nadal niewykonalną obliczeniowo. NIST ustanowił standard ML-KEM (Kyber) w 2024 roku do post-kwantowej enkapsulacji kluczy. Signal przeszedł na PQXDH w 2023 roku. Usługi transferu plików jeszcze powszechnie nie adoptowały post-quantum, lecz okno ryzyka „zbierz teraz, odszyfruj później" oznacza, że długoterminowe archiwa powinny dziś stosować 256-bitowe szyfrowanie symetryczne.

Jak wybrać metodę

Jednorazowy wrażliwy transfer, krótka retencja: klientowy AES-256-GCM z kluczami we fragmencie URL. Implementacją jest HexaTransfer. Trwające workflow podlegające regulacjom: XChaCha20-Poly1305 z logami audytów (Tresorit). Wielu odbiorców z zarządzaniem kluczami: OpenPGP (Proton Drive, GPG). Duża zdecentralizowana dystrybucja: libsodium secretbox plus kodowanie wymazywania (Internxt na Storj). Niepoufne, wysokie wolumeny: TLS i szyfrowanie w spoczynku jest akceptowalne.

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