Jak naprawdę działa kryptografia klucza publicznego

Za każdym razem, gdy łączysz się przez SSH z serwerem lub ładujesz stronę HTTPS, dwa matematycznie powiązane klucze wykonują całą pracę. Jeden jest publiczny, drugi prywatny, a zależność między nimi umożliwia bezpieczną komunikację przez niezaufaną sieć.

Podstawowa idea

W szyfrowaniu symetrycznym jeden klucz zarówno szyfruje, jak i deszyfruje dane. To działa dobrze, jeśli obie strony już dzielą tajemnicę, ale bezpieczne rozpowszechnianie tej tajemnicy to trudna część. Kryptografia klucza publicznego (asymetryczna) rozwiązuje to, generując matematycznie powiązaną parę: klucz publiczny, który przekazujesz każdemu, i klucz prywatny, który nigdy nie ujawniasz.

Dane zaszyfrowane kluczem publicznym można odszyfrować tylko odpowiadającym mu kluczem prywatnym. Dane podpisane kluczem prywatnym może zweryfikować każdy, kto ma klucz publiczny. Te dwie właściwości pokrywają prawie wszystko, do czego to wykorzystujemy: poufność i uwierzytelnianie.

RSA, klasyczny przykład

RSA polega na fakcie, że mnożenie dwóch dużych liczb pierwszych jest szybkie, ale rozkład iloczynu z powrotem na te liczby pierwsze jest obliczeniowo intensywny w skali. Klucz RSA 2048-bitowy zbudowany jest z dwóch liczb pierwszych o długości około 1024 bity każda. Klucz publiczny to (n, e) — n będący iloczynem liczb pierwszych, e stały wykładnik jak 65537. Klucz prywatny pochodzi z użyciem funkcji Eulera n i wymaga znajomości pierwotnych liczb pierwszych.

Szyfrowanie to potęgowanie modularne: c = m^e mod n. Deszyfrowanie odwraca to przy użyciu prywatnego wykładnika d: m = c^d mod n. W praktyce nikt jednak nie szyfruje dużych payload'ów bezpośrednio RSA — jest powolny i ma limity wielkości związane z długością klucza. Zamiast tego RSA zazwyczaj otacza symetryczny klucz sesji (AES-256 na przykład), a szyfr symetryczny obsługuje główne dane. To podejście hybrydowe, które używa TLS.

Kryptografia krzywych eliptycznych i dlaczego przejmuje rynek

ECC daje ci bezpieczeństwo równoważne RSA z znacznie mniejszymi kluczami. 256-bitowy klucz ECC (taki jak secp256r1 lub Curve25519) jest mniej więcej porównywalny w sile do 3072-bitowego klucza RSA. Mniejsze klucze oznaczają szybsze uściskami dłoni i mniejszą przepustowość, dlatego nowoczesne konfiguracje TLS, implementacje SSH i protokół Signal opierają się na ECC.

Matematyka jest inna — opiera się na dyskretnym problemie logarytmu nad punktami na krzywej eliptycznej zamiast na faktoryzacji liczb całkowitych — ale zależność między kluczem publicznym i prywatnym oraz gwarancje są koncepcyjnie takie same.

Podpisy cyfrowe: druga połowa równania

Szyfrowanie zapewnia poufność danych. Podpisy udowadniają autentyczność i integralność. Aby podpisać wiadomość, hashujesz ją (SHA-256, zazwyczaj) i szyfrujesz ten hash swoim kluczem prywatnym. Każdy, kto ma twój klucz publiczny, może shasować wiadomość sam, odszyfrować twój podpis i sprawdzić, czy dwa hashe się zgadzają.

To dokładnie to, co dzieje się, gdy uruchamiasz git commit -S z kluczem GPG, lub gdy Urząd Certyfikacji podpisuje certyfikat TLS. Klucz prywatny CA podpisuje twój certyfikat; przeglądarki dostarczane są z publicznym kluczem CA wstępnie zaufanym, więc mogą zweryfikować autentyczność twojego certyfikatu bez bezpośredniego kontaktu z CA.

Gdzie to pojawia się na co dzień

Uwierzytelnianie klucza SSH to bezpośrednia aplikacja: ssh-keygen -t ed25519 generuje parę kluczy, upuszczasz publiczną połowę do ~/.ssh/authorized_keys na serwerze, a uwierzytelnianie odbywa się przez wyzwanie-odpowiedź przy użyciu klucza prywatnego, hasło nigdy nie jest transmitowane.

Handshake'i TLS używają kryptografii asymetrycznej krótko, tylko aby ustalić wspólny klucz symetryczny (poprzez wymianę kluczy ECDHE w nowoczesnych konfiguracjach), następnie przechodzą do szybkiego szyfrowania symetrycznego dla rzeczywistej sesji. Szyfrowanie email'i PGP/GPG również następuje wzorem hybrydowym — szyfrujesz wiadomość losowym kluczem AES, a następnie szyfrujesz ten klucz AES publicznym kluczem RSA lub ECC odbiorcy.

Co naprawdę psuje się w praktyce

Matematyka za RSA i ECC nie została złamana przez klasyczne obliczenia. To, co idzie źle, to prawie zawsze implementacja: słaba generacja liczb losowych przy tworzeniu kluczy (bug Debian OpenSSL z 2008 roku to przykład podręcznikowy), ponowne użycie nonce'ów w podpisach ECDSA ujawniające klucze prywatne, lub ataki padding oracle'a na słabo zaimplementowany RSA (atak Bleichenbachera na dopełnianie PKCS#1 v1.5). Obliczenia kwantowe to długoterminowe teoretyczne zagrożenie — algorytm Shora złamałby zarówno RSA, jak i ECC, gdyby istniał wystarczająco duży komputer kwantowy — dlatego NIST już standaryzował algorytmy postkwantowe takie jak ML-KEM (poprzednio Kyber) do przyszłej migracji.

Jeśli chcesz pójść dalej, ścieżka kryptografii Korra Studio obejmuje protokoły wymiany kluczy i wewnętrzne funkcje haszowania bardziej szczegółowo, a segmenty sieciowe przechodzą przez to, jak wszystko to pasuje do rzeczywistego handshake'u TLS bajt po bajcie.