Szyfrowanie E2E zdjęć — jak naprawdę działa (i czym różni się od haseł na pliki)
„Nasze dane są szyfrowane!" — to mantra każdej chmury, komunikatora i serwisu cloud storage. Ale czy to samo znaczy w Dropbox, WhatsApp i w Fotopliki? Nie. Różnica tkwi w jednym pytaniu: kto ma klucz?. Ten artykuł wyjaśnia end-to-end encryption (E2E) po polsku, bez matematyki — tak żeby nawet nietechniczna osoba rozumiała, dlaczego „serwer nie widzi zawartości" to nie marketingowe blaga, tylko matematyczna gwarancja.
3 poziomy szyfrowania — najważniejsza różnica
Gdy firma mówi „stosujemy szyfrowanie", może mieć na myśli jedno z trzech:
Poziom 1: Szyfrowanie w transporcie (TLS / HTTPS)
Dane są szyfrowane w drodze między Twoją przeglądarką a serwerem. Każda strona z „https://" ma to od 2015 r. Ale na serwerze — dane są już odszyfrowane. Serwer widzi treść.
Poziom 2: Szyfrowanie w spoczynku (at rest)
Dane na dysku serwera są zaszyfrowane (np. AES-256). Jeśli ktoś ukradnie dysk — bełkot. Ale serwer ma klucz i w trakcie działania odszyfrowuje dane w RAM. Dropbox, Google Drive, iCloud działają tak domyślnie.
Poziom 3: End-to-end encryption (E2E)
Dane są szyfrowane na urządzeniu nadawcy (Twojej przeglądarce) i odszyfrowane dopiero na urządzeniu odbiorcy. Serwer nigdy nie zna klucza i widzi wyłącznie bełkot. Nawet jeśli serwer zostanie zhackowany, skonfiskowany przez policję, sprzedany — atakujący nie odczyta treści. Przykłady: Signal, WhatsApp (częściowo), Fotopliki.pl, ProtonMail.
Kluczowa różnica: na poziomach 1-2 dostawca może Cię podsłuchać. Może być zmuszony przez sąd do wydania treści. Może mieć nieuczciwego pracownika. Może być zhackowany. Na poziomie 3 — technicznie nie może. Klucza nie ma.
Analogia z sejfem
Wyobraź sobie 3 scenariusze wysłania dokumentu do adwokata:
AES-256-GCM — dlaczego właśnie to?
Fotopliki (i większość E2E serwisów) używa AES-256-GCM. Rozbierzmy ten alfabet:
- AES (Advanced Encryption Standard) — algorytm szyfrowania symetrycznego. Symetryczny = ten sam klucz szyfruje i odszyfrowuje. Opracowany w 2001 przez Belgów (Rijndael), przyjęty przez NIST jako standard. Używany przez US Government dla dokumentów TOP SECRET.
- 256 — długość klucza w bitach. Jest wersja AES-128 (wystarczająca na 50-100 lat) i AES-256 (wystarczająca na „forever", nawet przy hipotetycznych komputerach kwantowych + algorytmie Grovera → efektywnie AES-128, wciąż dobrze).
- GCM (Galois/Counter Mode) — tryb operacji. Daje szyfrowanie + integrację (authentication) w jednym. Jeśli atakujący zmodyfikuje choć 1 bit zaszyfrowanego pliku — odszyfrowanie zawiedzie, nie cicho zwróci śmieci. To kluczowe dla integralności.
Złamanie AES-256 brute-force (próba wszystkich 2^256 kluczy) wymagałoby: przekroczenia liczby atomów we wszechświecie liczby operacji. Nawet z hipotetycznym komputerem wielkości galaktyki pracującym przez wiek wszechświata — kilka procent przeszukanej przestrzeni. Realne ryzyko: błąd implementacji (nie dotyczy natywnego `crypto.subtle` w przeglądarce) albo wyciek klucza przez inny kanał.
Gdzie jest klucz? Magia fragmentu URL
Kluczowy trick w E2E web-apps: klucz jest w URL po znaku #. Dla przykładu:
https://www.fotopliki.pl/abc123#SeCrEtKeY_256bit_base64_here
Wszystko po # to tzw. fragment URL. Zgodnie ze specyfikacją HTTP (RFC 3986 z 2005, ale konwencja od 1994), fragment nie jest wysyłany przez przeglądarkę w żądaniu HTTP. Służył pierwotnie do „skocz do kotwicy #section1" — przeglądarka sama obsługuje to lokalnie.
Dla E2E daje to idealny mechanizm:
- Nadawca generuje losowy klucz AES-256 w swojej przeglądarce (`crypto.subtle.generateKey`).
- Nadawca szyfruje plik lokalnie tym kluczem.
- Zaszyfrowany plik trafia na serwer (serwer widzi bełkot).
- Klucz trafia do URL po znaku #. URL wygląda jak
fotopliki.pl/abc123#KLUCZ. - Nadawca wysyła URL odbiorcy (SMS, email, dowolny kanał).
- Odbiorca otwiera link. Przeglądarka pyta serwer tylko o
abc123(część przed #) → dostaje bełkot. - JavaScript w przeglądarce odczytuje klucz z fragmentu URL (dostępny lokalnie) i odszyfrowuje bełkot lokalnie.
- Odbiorca widzi zdjęcie.
W żadnym momencie serwer nie widzi klucza. Nawet w logach serwera URL zapisany jest tylko do abc123, bez fragmentu.
Haslo na plik vs E2E — częsta konfuzja
„Mój Dropbox też mogę zahasłować" — słyszę często. To nie jest E2E. Różnica:
| Hasło na pliku (np. ZIP+password) | E2E (Fotopliki, Signal) | |
|---|---|---|
| Kto ma klucz | Ty + odbiorca (przekazane osobno) | Ty + odbiorca (automatycznie w URL) |
| Siła klucza | Słabość hasła użytkownika (często 8-12 znaków = 30-60 bitów entropii) | Losowy klucz 256-bitowy (kosmiczna entropia) |
| Dostawca chmury widzi treść | TAK (hasło nie jest na poziomie chmury) | NIE (zaszyfrowane już u Ciebie) |
| UX | Musisz przekazać hasło osobnym kanałem | Klucz w URL, jedno wysłanie |
| Podatność | Brute-force hasła (GPU hashcat) | Matematyczna niewykonalność brute-force |
Co NIE chroni E2E
Ważne — E2E nie jest magiczną pigułką. Są rzeczy, których nie rozwiązuje:
- Atak na urządzenie końcowe. Malware w Twojej przeglądarce widzi plik przed szyfrowaniem i po odszyfrowaniu. E2E nie chroni przed keyloggerem.
- Screenshot odbiorcy. Gdy odbiorca widzi zdjęcie na ekranie — może zrobić zrzut ekranu, sfotografować telefonem. Właśnie dlatego fotopliki.pl ma hold-to-reveal UI (trzeba trzymać palec) i 60s burn timer — zmniejsza, ale nie eliminuje tego ryzyka.
- Metadata. Serwer wie, że Ty (z tego IP) wysłałeś plik do kogoś (kto otworzył z tamtego IP). Treść nieznana — ale pattern komunikacji może być informacyjny.
- Traffic analysis. Rozmiar zaszyfrowanego pliku jest w przybliżeniu taki sam jak oryginalnego. Obserwator może zgadywać typ pliku.
Dla full anonymity — potrzebujesz też Tor Browser (maskuje IP). Dla ochrony przed screenshot odbiorcy — możesz jedynie zarządzać zaufaniem do odbiorcy (E2E chroni kanał, nie zaufanego kontaktu).
Jak zweryfikować, że serwis naprawdę używa E2E?
- Open source kod kryptograficzny. Powinien być dostępny na GitHub/GitLab. Jeśli serwis twierdzi E2E ale kod crypto zamknięty — red flag.
- Klucz w URL po #. Zwróć uwagę na strukturę linku. Jeśli wszystkie dane są przed #, a po # nic nie ma — to nie jest E2E web.
- Audyt bezpieczeństwa. Signal, ProtonMail mają publiczne audyty. Mniejsze serwisy często nie — ale open source + praktyka daje dobrą heurystykę.
- „Zero knowledge" w polityce prywatności. Szukaj frazy „serwis nie ma dostępu do treści" lub „nie możemy odszyfrować Twoich danych".
FAQ
Czym E2E różni się od zwykłego szyfrowania?
Zwykłe szyfrowanie (HTTPS, dyskowe) — serwer/dostawca ma klucz i może odszyfrować. E2E — klucz ma tylko nadawca i odbiorca; serwer widzi wyłącznie bełkot i technicznie nie może odszyfrować.
Czy AES-256 jest nieprzełamalny?
W praktyce tak. Brute-force wymagałby ~10^77 operacji — więcej niż atomów we wszechświecie. NSA używa AES-256 dla TOP SECRET. Realne ataki — nie na matematykę, tylko implementację lub wyciek klucza.
Po co klucz w URL po #?
Fragment URL (po #) NIE jest wysyłany do serwera w HTTP request (od RFC 3986). Klucz pozostaje tylko w przeglądarce odbiorcy — pasuje idealnie do E2E.
Co jeśli ktoś przechwyci link?
Atakujący może odszyfrować plik — ALE link jest ważny tylko do pierwszego otwarcia (60s burn) lub 48h max. Kanał przesyłu linku też ma znaczenie.
Czy RODO wymaga E2E?
Nie wprost, ale art. 32 wymaga „odpowiednich środków technicznych". E2E jest najsilniejszym dostępnym. UODO w decyzjach 2023-2024 kilkakrotnie wskazywał E2E jako best practice dla danych tożsamości i medycznych.
Wypróbuj E2E w praktyce
Fotopliki.pl — prawdziwa E2E (klucz w URL po #), bez rejestracji. Zobacz sam, jak to działa.
Wyślij zaszyfrowane zdjęcie →