Algorytm Diffiego-Hellmana — jak działa wymiana klucza (z przykładem)

Algorytm Diffiego-Hellmana rozwiązuje jeden konkretny problem: jak dwie strony, które nigdy wcześniej się nie kontaktowały, mogą uzgodnić wspólny tajny klucz, wymieniając dane wyłącznie przez kanał, który ktoś podsłuchuje. Co ważne, podsłuchujący widzi całą wymianę, a i tak nie potrafi odtworzyć uzgodnionego klucza. Opublikowali go w 1976 roku Whitfield Diffie i Martin Hellman, a jego bezpieczeństwo opiera się na tzw. problemie logarytmu dyskretnego.

To nie jest algorytm szyfrowania — sam w sobie niczego nie ukrywa. Jego produktem jest wspólny sekret, którym strony karmią potem szybki szyfr symetryczny, taki jak AES. Poniżej pokażę mechanizm najpierw na intuicyjnej analogii, potem na konkretnych liczbach, a na końcu omówię, dlaczego sam DH nie wystarcza i co się dziś stosuje w jego miejsce.

Problem: wspólny klucz przez jawny kanał

Szyfry symetryczne, jak AES, używają tego samego klucza do zaszyfrowania i odszyfrowania — więcej o tym w tekście o szyfrowaniu symetrycznym. Rodzi to kłopot: skąd obie strony mają wziąć ten sam klucz, skoro łączą się po raz pierwszy przez internet, który z założenia jest podsłuchiwany? Wysłanie klucza wprost odpada — przechwyciłby go każdy po drodze.

Diffie i Hellman pokazali, że klucza wcale nie trzeba wysyłać. Można go wspólnie wyliczyć, wymieniając jedynie wartości, z których nie da się praktycznie odtworzyć sekretu. To był przełom: pierwsza praktyczna metoda ustalenia wspólnej tajemnicy bez wcześniejszego bezpiecznego kanału.

Analogia z mieszaniem kolorów

Zanim przejdziemy do liczb, pomaga klasyczny obraz z farbami. Mieszanie kolorów jest łatwe, ale rozdzielenie gotowej mieszanki z powrotem na składniki — bardzo trudne. Na tej asymetrii stoi cały pomysł.

1. Alicja i Bob jawnie ustalają wspólny kolor bazowy, np. żółty. Podsłuchujący też go widzi.
2. Każde z nich wybiera swój tajny kolor i trzyma go w sekrecie — Alicja czerwony, Bob niebieski.
3. Każde miesza kolor bazowy ze swoim tajnym i wysyła wynik drugiej stronie. Te mieszanki lecą jawnym kanałem.
4. Alicja dolewa swój tajny czerwony do mieszanki Boba, a Bob swój tajny niebieski do mieszanki Alicji. Oboje otrzymują identyczny kolor końcowy.

Podsłuchujący ma kolor bazowy i obie mieszanki, ale żeby uzyskać kolor końcowy, musiałby „odjąć” tajny kolor jednej ze stron — a tego z gotowej mieszanki się nie da. W prawdziwym algorytmie farby zastępuje arytmetyka modularna.

Jak to działa na liczbach — konkretny przykład

Przełóżmy analogię na matematykę. Mieszanie kolorów to potęgowanie modulo liczba pierwsza, a „nierozdzielalność” to problem logarytmu dyskretnego.

Strony jawnie ustalają dwie publiczne wartości: dużą liczbę pierwszą p oraz generator g. Dla czytelności weźmiemy śmiesznie małe liczby — p = 23, g = 5:

1. Alicja losuje tajną liczbę a = 6. Liczy A = g^a mod p = 5^6 mod 23 = 8. Wysyła Bobowi 8.
2. Bob losuje tajną liczbę b = 15. Liczy B = g^b mod p = 5^15 mod 23 = 19. Wysyła Alicji 19.
3. Alicja liczy wspólny klucz: s = B^a mod p = 19^6 mod 23 = 2.
4. Bob liczy wspólny klucz: s = A^b mod p = 8^15 mod 23 = 2.

Oboje dostali tę samą liczbę — 2 — choć nigdy jej nie przesłali. Działa to, bo matematycznie (g^a)^b i (g^b)^a to to samo g^{ab} mod p. Podsłuchujący zna p, g, 8 i 19, ale żeby wyliczyć wspólny sekret, musiałby odzyskać tajne a lub b z wartości publicznych — czyli rozwiązać logarytm dyskretny.

Uwaga: Liczby 23 i 5 to tylko ilustracja — są trywialne do złamania. W praktyce p ma co najmniej 2048 bitów (ok. 600 cyfr dziesiętnych), a tajne wykładniki są odpowiednio duże. Dopiero przy takiej skali logarytm dyskretny staje się obliczeniowo nieosiągalny.

Dlaczego to jest trudne do odwrócenia

Policzenie 5^6 mod 23 jest banalne i szybkie. Ale operacja odwrotna — „do której potęgi podniesiono 5, by modulo 23 wyszło 8” — przy dużych liczbach pierwszych nie ma znanego szybkiego algorytmu dla zwykłych komputerów. Ta jednokierunkowość, podobnie jak w kryptograficznych funkcjach skrótu, jest fundamentem całego schematu. Łatwo w jedną stronę, praktycznie niewykonalnie w drugą.

Diffie-Hellman to uzgadnianie klucza, nie szyfrowanie

To częste nieporozumienie, które warto wyprostować. DH nie zastępuje AES ani RSA w roli szyfru. Jego jedyne zadanie to doprowadzić obie strony do wspólnego sekretu. Z tego sekretu wyprowadza się (zwykle przez funkcję skrótu) klucz sesji, a dopiero on szyfruje właściwy ruch szybkim algorytmem symetrycznym, takim jak AES.

Taki podział ról jest celowy. Kryptografia z kluczem publicznym (jak DH czy RSA) jest wolna, więc używa się jej tylko na starcie, do uzgodnienia klucza. Potem przejmuje go szybki szyfr symetryczny, który radzi sobie z dużą ilością danych. To dlatego HTTPS działa szybko mimo mocnego szyfrowania.

Słaby punkt: atak man-in-the-middle

Czysty Diffie-Hellman ma poważną lukę: nie potwierdza, z kim rozmawiasz. Napastnik, który kontroluje łącze, może stanąć pośrodku i uzgodnić jeden klucz z Alicją (udając Boba) oraz drugi z Bobem (udając Alicję). Obie strony myślą, że mają bezpieczny kanał, a w rzeczywistości całość przechodzi przez napastnika, który odszyfrowuje i ponownie szyfruje ruch.

Rozwiązaniem jest dołączenie uwierzytelniania. W protokole TLS serwer przedstawia certyfikat podpisany przez zaufany urząd, a parametry DH są podpisane kluczem serwera — klient wie, że rozmawia z prawdziwym bankiem, a nie z pośrednikiem. W SSH przy pierwszym połączeniu zapamiętujesz klucz hosta i przy kolejnych sprawdzasz, czy się zgadza. Innymi słowy: DH daje poufność, ale tożsamość trzeba zapewnić osobno.

ECDH i forward secrecy — jak to wygląda dziś

Współczesne połączenia rzadko używają klasycznego DH na liczbach pierwszych w dużych ciałach skończonych (m.in. przez ataki typu Logjam na słabe, współdzielone parametry). Standardem jest wariant na krzywych eliptycznych — ECDH. Daje to samo bezpieczeństwo przy znacznie krótszych kluczach, co przekłada się na szybsze połączenia i mniejsze zużycie zasobów.

Kluczowa jest też litera „E” na końcu skrótu ECDHE, oznaczająca wariant efemeryczny: dla każdej sesji generowane są nowe, jednorazowe klucze, które po jej zakończeniu są kasowane. Zaleta nazywa się poufnością wsteczną (forward secrecy) — nawet jeśli napastnik kiedyś zdobędzie długoterminowy klucz prywatny serwera, nie odszyfruje nagranych wcześniej sesji, bo każda miała własny, ulotny sekret. To dlatego TLS 1.3 (standard z 2018 roku) w ogóle porzucił tryby bez forward secrecy i opiera wymianę klucza wyłącznie na efemerycznym (EC)DHE.

Gdzie spotkasz Diffiego-Hellmana w praktyce

Ten mechanizm pracuje w tle praktycznie każdej bezpiecznej sesji w sieci, choć go nie widzisz:

• HTTPS (TLS) — kłódka w przeglądarce oznacza m.in. uzgodnienie klucza przez (EC)DHE.
• SSH — zdalny dostęp do serwerów zestawia klucz sesji dokładnie tą metodą.
• Sieci VPN — protokoły IPsec/IKE oraz WireGuard używają wymiany Diffiego-Hellmana; to ona stoi za bezpieczeństwem usług opisanych m.in. w porównaniu Surfshark i CyberGhost.
• Komunikatory end-to-end — protokół Signal (używany też przez WhatsApp) opiera uzgadnianie kluczy na wariancie DH.

Co zapamiętać

Diffie-Hellman to nie szyfr, lecz sprytny sposób na wspólne wyliczenie tajnego klucza przez jawny kanał — bez jego przesyłania. Bezpieczeństwo bierze się z jednokierunkowości logarytmu dyskretnego, a praktyczna odporność zależy od rozmiaru parametrów i połączenia z uwierzytelnianiem, które zamyka lukę na atak man-in-the-middle. Jeśli masz wybór w konfiguracji serwera, włączaj tryby efemeryczne na krzywych eliptycznych (ECDHE) — to one dają forward secrecy i są dziś rozsądnym domyślnym ustawieniem.