Szyfrowanie end-to-end

Sposób ochrony komunikacji, w którym dane są szyfrowane na urządzeniu nadawcy i odszyfrowywane dopiero u odbiorcy, dzięki czemu nawet dostawca usługi nie ma do nich wglądu.

Szyfrowanie end-to-end (E2EE) to model ochrony komunikacji, w którym wiadomość zostaje zaszyfrowana na urządzeniu nadawcy i odszyfrowana dopiero na urządzeniu odbiorcy. Kluczem, który pozwala odczytać treść, dysponują wyłącznie końcówki rozmowy — nie ma go ani serwer pośredniczący, ani dostawca usługi. W praktyce oznacza to, że nawet firma prowadząca komunikator widzi tylko zaszyfrowany ciąg bajtów, a nie to, co naprawdę napisałeś.

Działa to dzięki kryptografii asymetrycznej. Każdy uczestnik ma parę kluczy: publiczny (rozdawany innym) i prywatny (który nigdy nie opuszcza urządzenia). Nadawca szyfruje treść tak, że odczytać ją da się tylko kluczem prywatnym odbiorcy. W nowoczesnych komunikatorach dochodzi do tego forward secrecy — klucze sesyjne zmieniają się przy każdej wiadomości, więc przejęcie jednego klucza nie odsłania całej historii rozmowy.

E2EE służy przede wszystkim ochronie przed podsłuchem na drodze: dostawcą, operatorem sieci, atakującym podsłuchującym ruch czy administratorem serwera. To inny zakres niż „szyfrowanie w tranzycie” (np. samo TLS/HTTPS), gdzie serwer i tak widzi treść w postaci jawnej.

Przykład z praktyki

Najczęściej cytowany przykład to Signal Protocol — protokół używany przez aplikację Signal, a także przez WhatsApp i wiadomości w Messengerze. Łączy on Diffie-Hellmana (wymiana kluczy), tzw. Double Ratchet (rotacja kluczy sesyjnych) oraz mechanizm prekluczy do startu rozmowy. Jeśli chcesz dotknąć E2EE w terminalu, najprościej przez GPG:

  • gpg --gen-key — tworzysz parę kluczy.
  • gpg --encrypt --recipient [email protected] plik.txt — szyfrujesz tak, że odczyta tylko Alice.
  • gpg --decrypt plik.txt.gpg — Alice odszyfrowuje swoim kluczem prywatnym.

Częste błędy i mity

Po pierwsze: E2EE nie chroni metadanych. Treść owszem, ale „kto, do kogo, kiedy i jak często” zwykle dalej jest widoczne. Po drugie: jeśli robisz backup rozmów do chmury bez szyfrowania, kopia może być czytelna dla dostawcy — sam komunikator nic tu nie pomoże. Po trzecie: bezpieczeństwo zależy od weryfikacji tożsamości. Bez sprawdzenia safety number (kodu/QR potwierdzającego klucz rozmówcy) jesteś podatny na atak man-in-the-middle. I po czwarte: E2EE chroni kanał, nie urządzenie — jeśli ktoś ma dostęp do Twojego odblokowanego telefonu, szyfrowanie przestaje cokolwiek znaczyć.

Pojęcia powiązane: kryptografia asymetryczna, klucz publiczny i prywatny, forward secrecy, TLS, atak man-in-the-middle, PGP/GPG, Signal Protocol, metadane.