RSA to jeden z tych algorytmów, które większość osób kojarzy z bezpieczną komunikacją, ale tylko część rozumie je praktycznie. W tym tekście pokazuję, jak działa kryptografia asymetryczna oparta na kluczu publicznym, gdzie naprawdę używa się tego mechanizmu i co ma największy wpływ na bezpieczeństwo wdrożenia. Patrzę na ten temat nie jak na definicję z podręcznika, tylko jak na narzędzie, które trzeba dobrze dobrać do systemu.
Najważniejsze rzeczy, które warto wiedzieć o RSA
- To algorytm asymetryczny: klucz publiczny można udostępniać, a prywatny trzeba chronić.
- Do szyfrowania używa się OAEP, a do podpisów PSS.
- Przy nowych wdrożeniach 2048 bitów to minimum, ale 3072 bity daje lepszy margines.
- RSA nie służy do szyfrowania dużych plików wprost, tylko zwykle do ochrony małego sekretu, na przykład klucza AES.
- Największe ryzyko robią błędny padding, słabe klucze i zła obsługa klucza prywatnego.
Jak działa RSA i co właściwie zabezpiecza
W praktyce RSA opiera się na bardzo prostym układzie ról. Klucz publiczny służy do szyfrowania lub weryfikacji podpisu, a klucz prywatny do odszyfrowania albo tworzenia podpisu. To nie są dwie kopie tego samego narzędzia, tylko para o zupełnie innym poziomie dostępności.
Matematycznie wszystko kręci się wokół dużej liczby n, zbudowanej z dwóch liczb pierwszych, oraz dwóch wykładników: publicznego e i prywatnego d. Atakujący zna n i e, ale nie powinien być w stanie praktycznie wyliczyć d, bo musiałby rozłożyć bardzo dużą liczbę na czynniki pierwsze. To właśnie ta trudność stanowi fundament bezpieczeństwa całego schematu.
Warto też pamiętać o ograniczeniu, które często zaskakuje osoby zaczynające pracę z tym algorytmem: RSA nie nadaje się do szyfrowania dużych danych jednym ruchem. Przy kluczu 2048 bitów i OAEP z SHA-256 jednorazowo zmieścisz około 190 bajtów. Z tego powodu w produkcji RSA najczęściej chroni klucz sesyjny, a samą treść przenosi już szyfr symetryczny, na przykład AES.
- Szyfrowanie działa tak, że nadawca używa klucza publicznego odbiorcy.
- Odszyfrowanie wymaga klucza prywatnego, którego nie udostępnia się nikomu.
- Podpis cyfrowy powstaje kluczem prywatnym, a weryfikacja odbywa się kluczem publicznym.
- Ten model chroni zarówno poufność, jak i integralność danych, jeśli wdrożenie jest poprawne.
To właśnie dlatego ten algorytm wciąż bywa fundamentem infrastruktury zaufania, ale nie jest uniwersalnym rozwiązaniem do wszystkiego. Dalej pokazuję, gdzie faktycznie ma sens w systemach bezpieczeństwa.
Gdzie RSA wciąż ma sens w praktyce
Gdy patrzę na rzeczywiste wdrożenia, RSA najczęściej pojawia się nie jako „szyfrowanie wszystkiego”, tylko jako narzędzie do budowania zaufania. Najmocniej widać to w podpisach cyfrowych, certyfikatach, starszych integracjach i ochronie małych sekretów, które trzeba przekazać bezpiecznie między systemami.
| Zastosowanie | Po co się go używa | Na co uważać |
|---|---|---|
| Podpisy cyfrowe | Potwierdzenie autora i integralności danych | Preferuj PSS i nowoczesny hash |
| Certyfikaty i PKI | Budowanie zaufania między usługami i użytkownikami | Dobierz długość klucza do cyklu życia certyfikatu |
| Podpisywanie kodu | Ochrona przed podmianą binarek i paczek instalacyjnych | Klucz prywatny powinien być mocno odseparowany |
| Szyfrowanie małych sekretów | Przekazanie klucza, tokena lub parametrów konfiguracji | Nie przekraczaj limitu długości wiadomości |
| Starsze integracje | Kompatybilność z istniejącą infrastrukturą | Traktuj to jako etap przejściowy, nie stan docelowy |
W nowym projekcie nie zaczynam od pytania, czy RSA „da radę” samodzielnie, tylko od tego, czy potrzebuję go jako warstwy zaufania. Bardzo często odpowiedź brzmi: tak, ale tylko w jednym, dobrze zdefiniowanym miejscu, a nie na całej ścieżce przetwarzania danych. To prowadzi wprost do pytania, co naprawdę decyduje o bezpieczeństwie tego wdrożenia.
Co decyduje o bezpieczeństwie wdrożenia
W bezpieczeństwie RSA najłatwiej popełnić błąd nie na poziomie matematyki, tylko konfiguracji. NIST SP 800-57 przypisuje kluczowi 2048-bitowemu około 112 bitów bezpieczeństwa, a 3072-bitowemu około 128 bitów. To dobry punkt odniesienia, gdy wybieram parametry dla systemu, który ma działać dłużej niż jedną generację sprzętu.
| Parametr | Praktyczna rekomendacja | Dlaczego ma znaczenie |
|---|---|---|
| 2048 bitów | Minimum kompatybilne z wieloma systemami | Wystarcza w wielu wdrożeniach, ale daje mniejszy margines na przyszłość |
| 3072 bity | Lepszy wybór dla nowych instalacji i dłuższego cyklu życia | Zapewnia wyższy poziom bezpieczeństwa przy wciąż rozsądnej kompatybilności |
| 4096 bitów | Opcja dla szczególnie długiego przechowywania klucza | Podnosi koszt operacyjny i zwykle nie daje proporcjonalnego zysku |
| OAEP | Używaj do szyfrowania | Dodaje losowość i chroni przed prostymi, deterministycznymi atakami |
| PSS | Używaj do podpisów | To nowoczesny, probabilistyczny schemat podpisu |
| Hash | SHA-256 albo mocniejszy | Zbyt słaby skrót osłabia cały mechanizm |
RFC 8017 porządkuje dziś właśnie OAEP dla szyfrowania i PSS dla podpisów, więc przy ocenie wdrożenia sprawdzam przede wszystkim te dwa elementy. Jeśli jeden z nich jest pominięty, nawet poprawny algorytm bazowy przestaje być dobrym wyborem. W praktyce większy klucz to także większy koszt obliczeniowy, więc 4096 bitów wybieram tylko wtedy, gdy naprawdę liczy się długowieczność i kompatybilność nie jest problemem.
To prowadzi do kolejnego, bardziej przyziemnego tematu, czyli do typowych błędów implementacyjnych. I tu, niestety, problemy są częstsze niż same wady matematyczne.
Najczęstsze błędy i ryzyka, które psują dobre założenia
Najbardziej niebezpieczne wdrożenia nie wyglądają na błędne. Często ktoś wybiera poprawny algorytm, ale stosuje go w złym trybie, z niewłaściwym paddingiem albo bez sensownego zarządzania kluczami. To właśnie takie detale robią największą różnicę między solidnym zabezpieczeniem a iluzją bezpieczeństwa.
- Gołe RSA bez paddingu. Taki wariant jest deterministyczny, więc nie powinien trafiać do produkcji.
- Szyfrowanie całych plików bezpośrednio RSA. To wolne, niepraktyczne i ograniczone rozmiarem wiadomości.
- Zbyt krótkie klucze. 1024 bity traktuję dziś jako przestarzały kompromis, nie bezpieczną bazę.
- Brak ochrony klucza prywatnego. Bez HSM, tokena sprzętowego albo dobrze odseparowanego magazynu sekretów cały model traci sens.
- Ignorowanie ataków bocznych. Sama matematyka nie wystarczy, jeśli implementacja zdradza informacje przez czas odpowiedzi, błędy albo sposób zużycia zasobów.
- Brak rotacji i unieważniania. Klucz, który żyje za długo, staje się ryzykiem operacyjnym nawet wtedy, gdy ma poprawną długość.
Z mojego punktu widzenia właśnie tu dzieje się najwięcej szkód: nie w samym RSA, tylko w tym, jak ktoś je opakuje. Dlatego warto od razu porównać je z nowszymi podejściami, zamiast zakładać, że starsze rozwiązanie automatycznie jest gorsze albo lepsze.
RSA kontra ECC i post-quantum
Jeśli buduję nowy system, prawie zawsze porównuję RSA z ECC, bo to nie jest tylko spór o modę. RSA daje szeroką kompatybilność, ale większe klucze i większy narzut, a ECC zwykle lepiej wypada przy podobnym poziomie bezpieczeństwa i mniejszych certyfikatach. W praktyce to oznacza mniej danych do przesyłania, mniejsze obciążenie infrastruktury i często prostsze skalowanie.
| Kryterium | RSA | ECC |
|---|---|---|
| Rozmiar klucza | Duży | Mały |
| Wydajność | Akceptowalna, ale koszt rośnie wraz z długością klucza | Często lepsza przy podobnym poziomie bezpieczeństwa |
| Kompatybilność | Bardzo dobra w starszych integracjach | Coraz lepsza, ale nie wszędzie jednakowa |
| Ślad operacyjny | Większe certyfikaty i cięższy obrót kluczy | Lżejsze wdrożenie i prostsza transmisja |
| Ryzyko kwantowe | Zagrożone w długim horyzoncie | Zagrożone w długim horyzoncie |
Nie oznacza to, że RSA znika jutro. Wciąż ma sens tam, gdzie liczy się zgodność ze starszymi systemami, certyfikatami i procedurami. Jeśli jednak projekt ma długi horyzont życia, rozsądnie jest już dziś planować migrację albo model hybrydowy, zamiast zakładać, że obecny stan kryptografii pozostanie stabilny przez dekadę.
Właśnie dlatego w nowym projekcie traktuję RSA jako element większej strategii bezpieczeństwa, a nie jako samotną odpowiedź na wszystkie problemy. To prowadzi do najpraktyczniejszej części całego tematu, czyli do tego, jak dobrać go rozsądnie od samego początku.
Jak wdrożyć to rozsądnie w nowym projekcie
Gdybym miał dziś zaprojektować bezpieczne użycie RSA od zera, trzymałbym się kilku prostych zasad. Nie są efektowne, ale właśnie one najczęściej odróżniają wdrożenie odporne od wdrożenia pozornie poprawnego.
- Do podpisów używaj PSS i hasha SHA-256 albo SHA-384.
- Do szyfrowania stosuj OAEP i model hybrydowy z AES-GCM, zamiast próbować pakować w RSA duże dane.
- W nowych wdrożeniach celuj w 3072 bity, a 2048 zostaw dla zgodności lub lżejszych środowisk.
- Klucz prywatny trzymaj w HSM, tokenie sprzętowym albo przynajmniej w osobnym, dobrze chronionym magazynie sekretów.
- Zaplaną rotację, unieważnianie i audyt użycia kluczy jeszcze przed wejściem systemu na produkcję.
Jeżeli system ma działać latami, traktuję RSA jako element infrastruktury zaufania, a nie jedyne zabezpieczenie. W praktyce wygrywa nie sam algorytm, tylko to, czy dobrze dobierzesz długość klucza, padding, przechowywanie sekretów i moment migracji na nowsze rozwiązanie.
