Kryptografia klucza publicznego: RSA, ECDSA i PGP

Problem, którego szyfrowanie symetryczne nie rozwiąże

Zanim pojawiła się kryptografia asymetryczna, całe szyfrowanie opierało się na wspólnym tajnym kluczu — obie strony musiały znać to samo hasło lub klucz, zanim mogły bezpiecznie się komunikować. Rodziło to oczywisty problem jajka i kury: jak w ogóle bezpiecznie wymienić klucz? Nie zaszyfrujesz klucza nim samym, a osobiste spotkania nie skalują się do milionów połączeń HTTPS.

Kryptografia klucza publicznego, opracowana w latach 70. przez Diffiego, Hellmana, Rivesta, Shamira i Adlemana, rozwiązuje to niezwykłą sztuczką matematyczną: parą kluczy, w której to, co zaszyfruje jeden klucz, może odszyfrować tylko drugi. Jeden klucz jest publiczny, drugi pozostaje prywatny. Możesz rozesłać swój klucz publiczny po całym internecie — atakujący, który go przechwyci, nic nie zyska.

Jak działa RSA

RSA to najbardziej znany algorytm asymetryczny. Jego bezpieczeństwo opiera się na problemie faktoryzacji liczb całkowitych: pomnożenie dwóch dużych liczb pierwszych jest banalne, ale rozłożenie iloczynu z powrotem na te liczby jest obliczeniowo niewykonalne przy odpowiednio dużych kluczach.

Generowanie kluczy w uproszczeniu:

1. Wybierz dwie duże losowe liczby pierwsze, p i q (każda ponad 1024 bity)
2. Oblicz n = p × q (moduł, jawny)
3. Oblicz φ(n) = (p−1)(q−1)
4. Wybierz wykładnik publiczny e (zwykle 65537)
5. Oblicz wykładnik prywatny d taki, że e × d ≡ 1 (mod φ(n))

Klucz publiczny to (e, n). Klucz prywatny to (d, n). Szyfrowanie: szyfrogram = wiadomość^e mod n. Deszyfrowanie: wiadomość = szyfrogram^d mod n.

RSA służy do wymiany kluczy i podpisów cyfrowych, a nie do szyfrowania dużych ilości danych — jest o rzędy wielkości wolniejszy niż AES. W TLS RSA (lub ECDH) negocjuje klucz sesji, a właściwy strumień danych szyfruje AES.

Minimalny zalecany rozmiar klucza: dziś 2048 bitów; dla bezpieczeństwa długoterminowego 3072 lub 4096 bitów.

Kryptografia krzywych eliptycznych (ECC)

ECC zapewnia bezpieczeństwo równoważne RSA przy znacznie mniejszych kluczach, dlatego jest preferowana we współczesnych systemach. 256-bitowy klucz ECC daje mniej więcej takie bezpieczeństwo jak 3072-bitowy klucz RSA.

Zamiast faktoryzacji ECC opiera się na problemie logarytmu dyskretnego na krzywej eliptycznej: mając punkt początkowy G na krzywej i wynik Q = k×G, znalezienie k jest obliczeniowo niewykonalne. Kluczem prywatnym jest skalar k, a publicznym — punkt Q.

ECDSA (Elliptic Curve Digital Signature Algorithm) służy do podpisywania — zabezpiecza transakcje Bitcoina, uzgadnianie TLS 1.3 i certyfikaty podpisywania kodu. ECDH (Elliptic Curve Diffie-Hellman) służy do wymiany kluczy. Najpopularniejsze krzywe to P-256 (NIST), P-384 i Curve25519 (ceniona za odporność na błędy implementacji i potencjalne furtki w krzywych NIST).

Podpisy cyfrowe: dowód autentyczności

Kryptografia asymetryczna nie tylko szyfruje — umożliwia też podpisy cyfrowe:

1. Nadawca oblicza skrót wiadomości (np. SHA-256)
2. Nadawca szyfruje skrót swoim kluczem prywatnym — to jest podpis
3. Odbiorca odszyfrowuje podpis kluczem publicznym nadawcy, odzyskując skrót
4. Odbiorca samodzielnie oblicza skrót wiadomości i porównuje — jeśli się zgadzają, wiadomość jest autentyczna i niezmieniona

Podpisy cyfrowe zapewniają uwierzytelnienie (podpisać mógł tylko posiadacz klucza prywatnego) i integralność (każda zmiana wiadomości zmienia skrót). Stanowią podstawę certyfikatów TLS, podpisywania kodu i uwierzytelniania poczty (S/MIME, DKIM).

PGP i sieć zaufania

PGP (Pretty Good Privacy) i jego otwarta implementacja GPG stosują kryptografię klucza publicznego do szyfrowania poczty i plików. Przebieg pracy:

• Wygeneruj parę kluczy: gpg --full-generate-key
• Wyeksportuj i udostępnij klucz publiczny: gpg --export --armor you@example.com
• Zaimportuj klucz kontaktu: gpg --import their_key.asc
• Zaszyfruj plik: gpg --encrypt --recipient them@example.com secret.txt
• Podpisz wiadomość: gpg --sign --armor message.txt

PGP stosuje model sieci zaufania (web of trust): zamiast polegać na centralnych urzędach certyfikacji (CA), użytkownicy podpisują nawzajem swoje klucze, poręczając za ich autentyczność. Jeśli Alicja ufa Bartkowi, a Bartek podpisał klucz Celiny, Alicja może w pewnym stopniu zaufać Celinie. Ten zdecentralizowany model różni się od hierarchicznego modelu CA stosowanego w TLS.

Urzędy certyfikacji i model zaufania TLS

Gdy przeglądarka łączy się z https://bank.com, weryfikuje tożsamość serwera za pomocą certyfikatu TLS — dokumentu zawierającego klucz publiczny serwera, podpisanego przez zaufany urząd certyfikacji. System i przeglądarka mają wbudowanych ok. 100–150 zaufanych głównych CA. Łańcuch zaufania: główny CA → pośredni CA → certyfikat serwera.

Ten scentralizowany model ma znaną słabość: każdy zaufany CA może podpisać certyfikat dla dowolnej domeny. Środki zaradcze to Certificate Transparency (wszystkie wydane certyfikaty muszą być publicznie rejestrowane), rekordy DNS CAA (ograniczają, które CA mogą wydawać certyfikaty dla Twojej domeny) i HPKP (obecnie wycofany na rzecz CT).

Poufność przyszła (forward secrecy)

Tradycyjna wymiana kluczy RSA ma poważną wadę: jeśli atakujący nagra dziś zaszyfrowany ruch, a później zdobędzie klucz prywatny serwera, odszyfruje wszystkie wcześniej nagrane sesje. Doskonała poufność przyszła (PFS) rozwiązuje to, używając dla każdej sesji efemerycznych kluczy Diffiego-Hellmana lub ECDH — klucz sesji nigdy nie trafia na dysk i jest usuwany po użyciu. TLS 1.3 wymaga PFS. Audytując konfigurację TLS serwera, sprawdź, czy włączone są wyłącznie zestawy szyfrów ECDHE lub DHE, a nie statyczna wymiana kluczy RSA.