Klucz do zrozumienia: Przygoda z algorytmem RSA w świecie kryptografii

RSA nie służy do szyfrowania całych plików, baz danych ani długich wiadomości. To jeden z najczęstszych błędów w rozumieniu tego algorytmu. Jego właściwym zadaniem jest przede wszystkim bezpieczne przekazanie niewielkiego sekretu, uwierzytelnienie strony albo złożenie podpisu cyfrowego. W praktycznym systemie RSA działa więc obok szyfru symetrycznego, funkcji skrótu, certyfikatów oraz procedur zarządzania kluczami.

Sam wzór matematyczny jest elegancki, ale nie on decyduje o bezpieczeństwie wdrożenia. Znacznie częściej problemem okazują się zły padding, wyciek klucza prywatnego, słaby generator liczb losowych, pozostawiony klucz 1024-bitowy albo aplikacja, która inaczej reaguje na poprawny i błędny szyfrogram. RSA jest sprawdzonym narzędziem, lecz nie wybacza improwizacji.

Dwie liczby pierwsze to dopiero początek

RSA, czyli Rivest–Shamir–Adleman, został publicznie opisany w 1977 roku. Należy do kryptografii asymetrycznej: zamiast jednego wspólnego sekretu wykorzystuje parę powiązanych matematycznie kluczy.

• Klucz publiczny można udostępnić innym osobom i systemom.
• Klucz prywatny musi pozostać pod wyłączną kontrolą właściciela.
• Operacja wykonana jednym kluczem może zostać zweryfikowana lub odwrócona wyłącznie przy użyciu odpowiednio powiązanego drugiego klucza.

Mechanizm zaczyna się od wyboru dwóch dużych liczb pierwszych, oznaczanych najczęściej jako p i q. Następnie obliczany jest ich iloczyn:

n = p × q

Wartość n staje się modułem RSA i wchodzi w skład klucza publicznego oraz prywatnego. Gdy mówi się o kluczu RSA 2048-bitowym, chodzi właśnie o przybliżoną długość modułu n, a nie o długość każdej liczby pierwszej. Liczby p i q mają zwykle po około połowie tej długości.

Kolejnym krokiem jest obliczenie wartości związanej z funkcją Eulera albo funkcją Carmichaela. Na tej podstawie wybiera się wykładnik publiczny e oraz odpowiadający mu wykładnik prywatny d. Muszą spełniać zależność modularną pozwalającą odwrócić operację wykonaną za pomocą drugiego wykładnika.

W typowych implementacjach wykładnik publiczny ma wartość:

e = 65 537

Nie jest to przypadkowa liczba. Jest wystarczająco mała, aby usprawnić weryfikację podpisów i szyfrowanie, a jednocześnie nie powoduje problemów charakterystycznych dla bardzo małych wykładników, takich jak 3. Samodzielne dobieranie e praktycznie nie ma sensu. Biblioteka kryptograficzna powinna zrobić to automatycznie.

Podręcznikowe operacje RSA wyglądają następująco:

• szyfrowanie: c = mᵉ mod n,
• deszyfrowanie: m = cᵈ mod n,
• podpisywanie: operacja z użyciem klucza prywatnego,
• weryfikacja podpisu: operacja z użyciem klucza publicznego.

Taki zapis pomaga zrozumieć matematykę, ale nie opisuje bezpiecznego rozwiązania. Surowego RSA nie wolno używać bez odpowiedniego schematu kodowania i paddingu. Wiadomość przed wykonaniem operacji musi zostać przekształcona według ściśle określonej procedury. Bez niej ten sam tekst prowadziłby do przewidywalnego wyniku, a matematyczne własności algorytmu otwierałyby drogę do praktycznych ataków.

Bezpieczeństwo RSA wiąże się z trudnością rozłożenia dużego modułu n na jego czynniki pierwsze. Znając p i q, można odtworzyć klucz prywatny. Znając wyłącznie odpowiednio duże n, nie potrafimy obecnie wykonać takiej faktoryzacji w rozsądnym czasie przy użyciu klasycznych komputerów.

To jednak tylko część obrazu. Klucza RSA nie trzeba rozkładać na czynniki, gdy napastnik może:

• wykraść go z dysku lub kopii zapasowej,
• odczytać z pamięci procesu,
• wykorzystać podatny moduł HSM,
• przewidzieć liczby wygenerowane przez słabe źródło losowości,
• zmierzyć czas wykonywania operacji,
• wywołać błędy obliczeniowe przez manipulację sprzętem,
• wykorzystać różne komunikaty zwracane po nieudanym odszyfrowaniu.

Dlatego dojrzała biblioteka stosuje między innymi blinding, stałoczasowe operacje, testy poprawności klucza oraz zabezpieczenia przed atakami bocznymi. Pisanie własnej implementacji RSA jest dobrym ćwiczeniem akademickim. Używanie jej w produkcji jest złym pomysłem.

RSA w prawdziwym systemie: podpisuje albo chroni mały sekret

Najważniejszym praktycznym rozróżnieniem jest podział na szyfrowanie i podpis cyfrowy. To dwie inne operacje, służące do innych celów.

Przy szyfrowaniu nadawca wykorzystuje klucz publiczny odbiorcy. Odbiorca odzyskuje dane kluczem prywatnym. Zapewnia to poufność, ale samo w sobie nie potwierdza, kto wysłał wiadomość.

Przy podpisie właściciel używa klucza prywatnego do podpisania skrótu danych. Każdy dysponujący kluczem publicznym może sprawdzić, czy:

• dane nie zostały zmienione,
• podpis pasuje do wskazanego klucza,
• operację wykonał podmiot kontrolujący klucz prywatny.

Nie należy opisywać podpisu jako „szyfrowania kluczem prywatnym”. To popularne uproszczenie, które prowadzi do błędnego projektowania systemów. Współczesny schemat podpisu obejmuje funkcję skrótu, kodowanie, parametry bezpieczeństwa oraz procedurę weryfikacji. Nie jest prostym odwróceniem szyfrowania.

Do szyfrowania z RSA należy stosować RSA-OAEP, najczęściej z SHA-256. Starszy mechanizm PKCS#1 v1.5 nadal występuje w systemach zgodności wstecznej, lecz w nowych projektach nie powinien być pierwszym wyborem. Błędy w obsłudze PKCS#1 v1.5 wielokrotnie prowadziły do ataków typu padding oracle, w których serwer stopniowo ujawniał informacje na podstawie sposobu odrzucania niepoprawnych danych.

Do nowych podpisów właściwym wyborem jest RSA-PSS, również zwykle łączony z SHA-256 lub SHA-384. Schemat PKCS#1 v1.5 dla podpisów nadal jest obsługiwany przez wiele narzędzi i certyfikatów, ale PSS daje lepszy margines bezpieczeństwa i jest rekomendowany przy projektowaniu nowych protokołów.

RSA ma twardy limit wielkości szyfrowanej wiadomości. Dla OAEP maksymalna długość danych wynosi:

k − 2hLen − 2

gdzie:

• k oznacza długość modułu w bajtach,
• hLen oznacza długość wyniku funkcji skrótu w bajtach.

Dla klucza RSA 2048-bitowego mamy k = 256 bajtów. SHA-256 daje skrót 32-bajtowy, zatem:

256 − 2 × 32 − 2 = 190 bajtów

To oznacza, że RSA-2048 z OAEP i SHA-256 zaszyfruje najwyżej 190 bajtów danych. Nie 190 kilobajtów i nie 190 znaków w każdej sytuacji, lecz 190 bajtów.

Dla RSA-3072 limit wynosi 318 bajtów, a dla RSA-4096 — 446 bajtów. Zwiększenie klucza nadal nie czyni RSA rozsądnym szyfrem do plików. Operacje są wolne, a szyfrogram każdego bloku ma długość całego modułu.

W praktyce stosuje się szyfrowanie hybrydowe:

1. Generator kryptograficzny tworzy losowy klucz symetryczny, np. 256-bitowy klucz AES.
2. Dane są szyfrowane algorytmem AES-GCM albo ChaCha20-Poly1305.
3. RSA-OAEP szyfruje jedynie klucz symetryczny.
4. Odbiorca odszyfrowuje klucz prywatny, a następnie używa go do odzyskania właściwych danych.

Tak działa rozsądnie zaprojektowany system plikowy, komunikacyjny albo kopia zapasowa. RSA rozwiązuje problem przekazania klucza, a szyfr symetryczny wykonuje ciężką pracę.

Trzeba również rozumieć rolę RSA w HTTPS. Certyfikat serwera może zawierać publiczny klucz RSA, a serwer może użyć prywatnego klucza do podpisania elementów uzgadniania połączenia. We współczesnym TLS 1.3 RSA nie służy jednak do transportowania sekretu sesji. Klucze sesyjne są uzgadniane za pomocą efemerycznej wymiany Diffiego-Hellmana, najczęściej opartej na krzywych eliptycznych. Daje to forward secrecy: późniejsza kradzież klucza serwera nie pozwala automatycznie odszyfrować wcześniej zarejestrowanego ruchu.

RSA nadal spotyka się w:

• certyfikatach TLS i firmowej infrastrukturze PKI,
• podpisywaniu kodu i pakietów oprogramowania,
• podpisywaniu dokumentów elektronicznych,
• JWT z algorytmami rodziny RS256 i PS256,
• S/MIME i niektórych konfiguracjach OpenPGP,
• kartach kryptograficznych, tokenach i modułach HSM,
• systemach bankowych oraz administracyjnych utrzymujących wieloletnią zgodność.

Najbardziej irytującą cechą RSA w praktyce nie jest jego matematyka, lecz rozmiar i koszt operacji. Klucze oraz podpisy są większe niż w wielu systemach opartych na kryptografii eliptycznej, a podpisywanie prywatnym kluczem jest wyraźnie cięższe od weryfikacji. Przy bardzo dużym ruchu API albo masowym podpisywaniu tokenów różnica przekłada się na liczbę rdzeni, opóźnienia i koszty HSM.

Dobór klucza, zarządzanie sekretami i plan odejścia od RSA

RSA-1024 należy traktować jako przestarzałe. Nie powinien trafiać do nowych certyfikatów, podpisów ani mechanizmów ochrony danych. Jeżeli nadal działa w firmowym urządzeniu, aplikacji Java albo archiwalnym VPN-ie, jest to dług techniczny wymagający inwentaryzacji i planu migracji.

Dla typowych współczesnych zastosowań minimalnym praktycznym wyborem pozostaje RSA-2048. Odpowiada on w przybliżeniu 112-bitowemu poziomowi bezpieczeństwa klasycznego. To wystarczająca wartość dla wielu bieżących certyfikatów, podpisów i systemów zgodności, szczególnie gdy dane oraz klucze nie mają być chronione przez kilkanaście kolejnych lat.

RSA-3072 daje poziom zbliżony do 128-bitowego bezpieczeństwa klasycznego. Jest rozsądniejszy, gdy:

• klucz ma być użytkowany przez wiele lat,
• podpisy muszą pozostać wiarygodne długo po ich złożeniu,
• system przetwarza dane o długim okresie poufności,
• organizacja przyjęła 128-bitowy minimalny poziom bezpieczeństwa,
• narzut obliczeniowy nie jest krytyczny.

RSA-4096 nie jest automatycznie najlepszym wyborem. Zwiększa koszt generowania klucza, podpisywania i operacji prywatnych, powiększa certyfikaty oraz podpisy, a jednocześnie nie rozwiązuje problemu komputerów kwantowych. Często wybiera się go z przekonania, że „więcej bitów zawsze znaczy lepiej”. W systemie o dużej liczbie żądań może to pogorszyć wydajność bez proporcjonalnej korzyści.

Rozsądna hierarchia decyzji wygląda następująco:

• RSA-2048 — zgodność, typowe certyfikaty, systemy o umiarkowanym okresie życia;
• RSA-3072 — nowe wdrożenia wymagające wyższego poziomu bezpieczeństwa klasycznego;
• RSA-4096 — szczególne wymagania polityki bezpieczeństwa, regulacji albo interoperacyjności, po wykonaniu testów wydajności;
• algorytmy eliptyczne lub postkwantowe — gdy nie ma obowiązku pozostania przy RSA i można kontrolować zgodność całego środowiska.

Długość klucza nie pomoże, gdy źle zarządza się kluczem prywatnym. W systemie produkcyjnym klucz powinien być generowany przy użyciu sprawdzonej biblioteki lub bezpośrednio w HSM, karcie kryptograficznej bądź usłudze zarządzania kluczami. Eksportowalny plik PEM leżący obok aplikacji jest wygodny, lecz zwiększa ryzyko kopiowania, umieszczenia w repozytorium albo trafienia do obrazu kontenera.

Najważniejsze zasady operacyjne są proste:

• klucz prywatny nie powinien trafiać do kodu, GitHub Actions, obrazu Dockera ani zmiennych zapisanych w logach;
• plik z kluczem musi być szyfrowany, a hasło przechowywane oddzielnie;
• uprawnienia systemowe powinny ograniczać odczyt do konkretnego procesu lub konta;
• kopia zapasowa klucza wymaga szyfrowania, kontroli dostępu i testu odtworzenia;
• rotacja musi obejmować okres współistnienia starego oraz nowego klucza;
• usunięcie klucza wymaga sprawdzenia, czy nadal nie służy do odszyfrowywania archiwów lub weryfikacji historycznych podpisów;
• system powinien rejestrować użycie klucza, ale nigdy jego treść.

Inaczej rotuje się klucz do podpisywania, a inaczej klucz do szyfrowania. Stary publiczny klucz podpisujący może być potrzebny jeszcze przez lata do weryfikacji dokumentów i oprogramowania. Stary prywatny klucz szyfrujący może być konieczny do odczytania archiwalnych danych. Bez katalogu zależności „rotacja” często kończy się awarią albo utratą dostępu.

Nie wolno również używać jednej pary kluczy do wszystkiego. Klucz certyfikatu WWW, klucz podpisujący tokeny JWT i klucz służący do odszyfrowania kopii zapasowych powinny być rozdzielone. Wyciek jednego sekretu nie może automatycznie podważać kilku niezależnych usług.

Największe strategiczne ograniczenie RSA wynika z algorytmu Shora. Wystarczająco duży, odporny na błędy komputer kwantowy mógłby efektywnie rozkładać moduły RSA na czynniki. Takiego urządzenia zdolnego do łamania produkcyjnych kluczy RSA obecnie nie ma, ale dokładna data jego powstania pozostaje nieznana.

Nie oznacza to, że migrację można odkładać do chwili pojawienia się komunikatu o przełomie. Napastnik może przechwycić szyfrowane dane dzisiaj i przechować je do momentu, gdy ich odszyfrowanie stanie się możliwe. Ryzyko jest realne przede wszystkim dla informacji, które mają zachować poufność przez wiele lat: dokumentacji medycznej, danych państwowych, własności intelektualnej, tajemnic technologicznych i archiwów infrastruktury krytycznej.

Od 2024 roku istnieją gotowe standardy postkwantowe NIST, między innymi ML-KEM do uzgadniania kluczy, ML-DSA do podpisów oraz SLH-DSA do podpisów opartych na funkcjach skrótu. Europejska mapa drogowa zakłada rozpoczęcie przechodzenia państw członkowskich na kryptografię postkwantową do końca 2026 roku, a migrację infrastruktury krytycznej najpóźniej do końca 2030 roku.

Nie jest to polecenie, aby jutro usunąć wszystkie klucze RSA. Pierwszym etapem powinna być kryptograficzna inwentaryzacja:

• gdzie RSA jest używany,
• do czego służy dana para kluczy,
• jakie systemy obsługują OAEP, PSS i algorytmy postkwantowe,
• jak długo dane muszą pozostać tajne,
• które urządzenia są zależne od starego oprogramowania,
• czy formaty certyfikatów i protokoły pozwalają zmienić algorytm bez przebudowy całego systemu.

Dopiero potem można wdrażać rozwiązania hybrydowe, testować nowe formaty kluczy i planować wymianę protokołów. Największym błędem nie jest dziś samo korzystanie z RSA. Jest nim brak wiedzy, gdzie RSA działa i jak długo organizacja pozostanie od niego zależna.

FAQ

Czy RSA-2048 nadal jest bezpieczny?
Tak, w typowych zastosowaniach klasycznych nadal jest powszechnie uznawany za bezpieczny, pod warunkiem użycia właściwego paddingu, sprawdzonej biblioteki i poprawnej ochrony klucza prywatnego. Nie zapewnia jednak odporności postkwantowej.

Czy można zaszyfrować plik bezpośrednio za pomocą RSA?
Technicznie można dzielić dane na małe bloki, ale nie powinno się tego robić. Plik należy zaszyfrować algorytmem AES-GCM lub ChaCha20-Poly1305, a RSA-OAEP wykorzystać wyłącznie do ochrony losowego klucza symetrycznego.

Ile danych mieści RSA-2048 z OAEP?
Przy OAEP z SHA-256 maksymalnie 190 bajtów. Limit wynika z długości modułu i narzutu schematu kodowania.

Który padding wybrać?
Do szyfrowania wybierz RSA-OAEP, najlepiej z SHA-256. Do nowych podpisów wybierz RSA-PSS. Surowe RSA bez paddingu nie nadaje się do bezpiecznych zastosowań.

Czy RSA-4096 chroni przed komputerem kwantowym?
Nie. Dłuższy moduł zwiększa odporność na klasyczną faktoryzację, ale algorytm Shora dotyczy całej rodziny RSA. RSA-4096 może opóźnić ataki klasyczne, lecz nie zmienia kategorii zagrożenia kwantowego.

Czy klucz publiczny trzeba chronić?
Nie musi być tajny, ale trzeba chronić jego autentyczność. Podmiana klucza publicznego pozwala napastnikowi podszyć się pod właściwego właściciela. Dlatego stosuje się certyfikaty, zaufane repozytoria kluczy i weryfikację odcisków.

Co się dzieje po wycieku klucza prywatnego?
Klucz należy natychmiast wycofać, unieważnić powiązany certyfikat i wygenerować nową parę. Trzeba też ustalić, czy wyciek umożliwia odszyfrowanie archiwalnych danych, fałszowanie podpisów albo podszywanie się pod usługę.

Czy można napisać RSA samodzielnie?
Do nauki — tak. Do systemu produkcyjnego — nie. Poprawna implementacja wymaga bezpiecznego generatora, paddingu, operacji stałoczasowych, ochrony przed atakami bocznymi, walidacji kluczy i bezpiecznej obsługi błędów.

Czy trzeba już zastępować RSA algorytmami postkwantowymi?
Nie każdy system wymaga natychmiastowej wymiany, ale każdy powinien zostać zinwentaryzowany. Najwyższy priorytet mają dane o wieloletniej poufności, infrastruktura krytyczna oraz rozwiązania, których modernizacja potrwa kilka lat.

Pierwszy krok nie polega na zwiększeniu każdego klucza do 4096 bitów. Najpierw wyszukaj RSA-1024, surowe RSA, szyfrowanie PKCS#1 v1.5 oraz klucze prywatne zapisane w kodzie lub obrazach kontenerów. Usuń te problemy, zanim rozpoczniesz kosztowną migrację całej infrastruktury. Potem sprawdź, które systemy korzystają z RSA dłużej, niż wynosi wymagany okres poufności danych, i dla nich przygotuj plan przejścia na mechanizmy postkwantowe lub hybrydowe.