Parę tygodni temu ktoś mnie zapytał: „Ej, a tak normalnie, po ludzku – jak działa RSA?”.
\nNo i pomyślałem: OK, spróbuję to wytłumaczyć, bo temat jest ważny, a często tłumaczony strasznie akademicko.
\nWyobraźcie sobie, że chcecie wysłać komuś tajną wiadomość przez Internet. Wszyscy patrzą, wszyscy podsłuchują.
\nJak to zrobić, żeby tylko odbiorca mógł ją przeczytać? No właśnie tu wchodzi cały algorytm RSA, cały na biało ;)
\nRSA1 to algorytm kryptografii asymetrycznej. Brzmi groźnie, ale idea jest prosta:
\nMożna powiedzieć, że to taka kłódka, do której każdy ma klucz do zamykania, ale tylko ty masz klucz do otwierania ;)
\nNo dobra, tu zaczyna się matematyka, ale spokojnie – bez paniki.
\nflowchart TD\n Start([🚀 START<br/>Generowanie kluczy RSA])\n\n Start --> P1[Wybierz dwie duże liczby pierwsze<br/>p = 61, q = 53]\n\n P1 --> P2[Oblicz n = p × q<br/>n = 61 × 53 = 3233]\n\n P2 --> P3[Oblicz funkcję Eulera<br/>φ'n' = 'p-1' × 'q-1'<br/>φ'n' = 60 × 52 = 3120]\n\n P3 --> P4[Wybierz wykładnik publiczny e<br/>względnie pierwszy z φ'n'<br/>e = 17]\n\n P4 --> P5[Oblicz wykładnik prywatny d<br/>odwrotność modularna e mod φ'n'<br/>d = 2753]\n\n P5 --> Check{Sprawdzenie:<br/>'e × d' mod φ'n' = 1?}\n\n Check -->|✅ TAK<br/>17 × 2753 mod 3120 = 1| Success[✅ GOTOWE!<br/><br/>🔓 Klucz publiczny: 'e, n' = '17, 3233'<br/>🔐 Klucz prywatny: 'd, n' = '2753, 3233']\n\n Check -->|❌ NIE| P4\n\n Success --> End([🎉 Klucze wygenerowane])\n\n style Start fill:#e1f5ff,stroke:#0066cc,stroke-width:3px\n style Success fill:#d4edda,stroke:#28a745,stroke-width:3px\n style End fill:#d4edda,stroke:#28a745,stroke-width:3px\n style Check fill:#fff3cd,stroke:#ffc107,stroke-width:2px\n style P5 fill:#ffe6e6,stroke:#dc3545,stroke-width:2px\nAle czekaj – co to w ogóle jest liczba pierwsza?
\nTo liczba, która dzieli się tylko przez 1 i przez samą siebie.
\nPrzykłady:
\nLiczby pierwsze to takie "atomy matematyki" – nie da się ich rozłożyć na mniejsze kawałki.
\nDlaczego liczby pierwsze?
\nTa właściwość jest fundamentem bezpieczeństwa RSA! Liczby pierwsze są łatwe do pomnożenia, ale ich iloczyn jest praktycznie niemożliwy do rozłożenia z powrotem (dla dużych liczb).
\nOK, do rzeczy:
\nNa start wybierasz dwie duże liczby pierwsze:
\np = 61\nq = 53\n(W praktyce to są liczby mające setki cyfr, ale na bloga wystarczy coś mniejszego).
\nn = p * q = 3233\nTa liczba n będzie częścią klucza publicznego. I tak – każdy może ją znać.
Teraz liczymy tzw. funkcję Eulera:
\nφ(n) = (p - 1) * (q - 1)\nφ(n) = 60 * 52 = 3120\nφ(n) (czytaj: "fi od en") mówi nam, ile liczb jest względnie pierwszych z n.
\nAle czekaj – co to znaczy "względnie pierwsze"?
\nDwie liczby są względnie pierwsze, gdy nie mają wspólnych dzielników (oprócz 1).\nCzyli ich największy wspólny dzielnik (NWD) = 1.
\nPrzykłady:
\nMały przykład dla intuicji:
\nDla n=10 sprawdźmy każdą liczbę:
\nWynik: liczby względnie pierwsze z 10 to {1,3,7,9}, czyli φ(10) = 4
\nTo właśnie piękno liczb pierwszych!
\nGdy n = p × q (gdzie p i q to liczby pierwsze), istnieje elegancki wzór:
\nDla liczby pierwszej p, wszystkie liczby od 1 do p-1 są z nią względnie pierwsze.\nWięc φ(p) = p-1.
\nDzięki właściwościom mnożenia:
\nφ(p × q) = φ(p) × φ(q) = (p-1) × (q-1)\nW naszym przykładzie:
\nFunkcja φ(n) jest kluczem do klucza prywatnego!
\nTo właśnie ta „sekretna wiedza" o φ(n) pozwala nam stworzyć klucz prywatny, którego nikt inny nie może obliczyć!
\nWybieramy liczbę e, która:
φ(n) (czyli NWD(e, φ(n)) = 1)W praktyce najczęściej używane wartości to:
\nCzemu akurat 65537?
\nTo liczba Fermata: F₄ = 2^16 + 1 = 65537
\nW zapisie binarnym:
\n65537 = 10000000000000001 (tylko dwie jedynki!)\nTo oznacza, że operacja m^65537 to tylko:
Dlaczego 65537 to standard?
\nBardzo szybko się liczy (tylko dwie jedynki w zapisie binarnym), a jednocześnie jest wystarczająco duże żeby być bezpieczne. To idealny kompromis między wydajnością a bezpieczeństwem!
\ne = 17\nI teraz mamy:
\n(e, n) → (17, 3233)Uwaga: nie każde e będzie działać! Musi być względnie pierwsze z φ(n).\nJeśli spróbujesz użyć e, które ma wspólny dzielnik z φ(n), nie da się obliczyć klucza prywatnego d.
\nTeraz najważniejsze: liczymy d, czyli odwrotność modularną:
d ≡ e⁻¹ (mod φ(n))\nCzyli szukamy takiego d, żeby:
(d * e) % φ(n) = 1\nMówimy, że d jest odwrotnością modularną e względem φ(n), gdy ich iloczyn daje resztę 1 po podzieleniu przez φ(n).
Przykład prostszy: dla φ(n) = 10 i e = 3
\nDla małych liczb możemy próbować po kolei, ale dla liczb 1024-bitowych?\nUżylibyśmy rozszerzonego algorytmu Euklidesa (Extended Euclidean Algorithm).
\nAlgorytm znajduje odwrotność modularną w czasie O(log n):
\nKrok po kroku:
\ne·x + φ(n)·y = NWD(e, φ(n))d = x mod φ(n)Przykład dla e=17, φ(n)=3120:
\n3120 = 17 × 183 + 9\n17 = 9 × 1 + 8\n9 = 8 × 1 + 1 <- NWD = 1 ✓\n8 = 1 × 8 + 0\n\nWsteczna substytucja:\n1 = 9 - 8\n1 = 9 - (17 - 9) = 2×9 - 17\n1 = 2×(3120 - 183×17) - 17\n1 = 2×3120 - 367×17\n\nWięc: 17 × (-367) ≡ 1 (mod 3120)\nd = -367 mod 3120 = 2753 ✓\nTo skomplikowane, ale na szczęście biblioteki robią to za nas!
\nNa szczęście w Pythonie to proste:
\nd = pow (e , - 1 , phi ) # od Pythona 3.8 W naszym przypadku:
\ne = 17\nφ(n) = 3120\nd = 2753\n\nSprawdzenie: (17 * 2753) % 3120 = 46801 % 3120 = 1 ✓\nI voilà:
\n(d, n) → (2753, 3233)Bezpieczeństwo klucza prywatnego
\nKlucz prywatny d trzymasz TYLKO dla siebie.\nJeśli ktoś go zdobędzie = game over, może odczytać wszystkie twoje wiadomości!
flowchart TB\n subgraph PUBLIC["🌍 PUBLICZNE"]\n E[e = 17<br/>wykładnik publiczny]\n N[n = 3233<br/>moduł]\n end\n\n subgraph SECRET["🔒 TAJNE"]\n D[d = 2753<br/>wykładnik prywatny]\n end\n\n subgraph TOPSECRET["🔥 SUPER TAJNE"]\n P[p = 61<br/>pierwsza liczba pierwsza]\n Q[q = 53<br/>druga liczba pierwsza]\n PHI[φ'n' = 3120<br/>funkcja Eulera]\n end\n\n TOPSECRET -.->|generuje| SECRET\n TOPSECRET -.->|generuje| PUBLIC\n\n Note1["🌍 Wszyscy mogą znać<br/>Publikowane w certyfikatach"]\n Note2["🔒 Tylko właściciel<br/>Nigdy nie ujawniaj!"]\n Note3["🔥 Zniszczyć po generowaniu kluczy!<br/>⚠️ Jeśli ktoś zna p, q lub φ(n)<br/>może obliczyć d i złamać szyfrowanie"]\n\n PUBLIC -.-> Note1\n SECRET -.-> Note2\n TOPSECRET -.-> Note3\n\n style PUBLIC fill:#e7f3ff,stroke:#0066cc,stroke-width:2px\n style SECRET fill:#fff4e6,stroke:#ff9800,stroke-width:3px\n style TOPSECRET fill:#ffe6e6,stroke:#dc3545,stroke-width:4px,padding:20px,min-width:400px\n style Note1 fill:#e7f3ff,stroke:#0066cc,stroke-width:2px\n style Note2 fill:#fff4e6,stroke:#ff9800,stroke-width:2px\n style Note3 fill:#ffe6e6,stroke:#dc3545,stroke-width:2px\n\n style E fill:#cce5ff,stroke:#0066cc\n style N fill:#cce5ff,stroke:#0066cc\n style D fill:#ffe4cc,stroke:#ff9800\n style P fill:#ffcccc,stroke:#dc3545\n style Q fill:#ffcccc,stroke:#dc3545\n style PHI fill:#ffcccc,stroke:#dc3545\nRSA szyfruje liczby, więc najpierw konwertujemy tekst na liczby.
\nNajprościej: używamy kodów ASCII!
\n'H' → 72\n'E' → 69\n'L' → 76\n'L' → 76\n'O' → 79\nPotem każdą liczbę szyfrujemy osobno wzorem:
\nc = m^e mod n\nsequenceDiagram\n autonumber\n participant A as Alice\n participant B as Bob\n participant S as 🌍 Świat<br/>(podsłuchujący)\n\n Note over B: Generowanie kluczy RSA\n B->>B: Wybierz p=61, q=53\n B->>B: Oblicz n = 61×53 = 3233\n B->>B: Oblicz φ(n) = 60×52 = 3120\n B->>B: Wybierz e = 17\n B->>B: Oblicz d = 2753\n\n Note over B: Klucz publiczny: (e=17, n=3233)<br/>Klucz prywatny: (d=2753, n=3233)\n\n B->>A: Publikuje klucz publiczny (17, 3233)\n B->>S: Publikuje klucz publiczny (17, 3233)\n\n Note over A: Alice ma wiadomość "HI"\n A->>A: Konwersja ASCII: H=72, I=73\n\n Note over A: Szyfrowanie każdej litery\n A->>A: c₁ = 72^17 mod 3233 = 3000\n A->>A: c₂ = 73^17 mod 3233 = 1486\n\n A->>B: Wysyła [3000, 1486]\n A->>S: 👀 Świat widzi [3000, 1486]\n\n Note over S: ❌ Bez klucza prywatnego d<br/>NIE może odszyfrować!\n\n Note over B: Deszyfrowanie kluczem prywatnym\n B->>B: m₁ = 3000^2753 mod 3233 = 72\n B->>B: m₂ = 1486^2753 mod 3233 = 73\n B->>B: Konwersja ASCII: 72='H', 73='I'\n\n Note over B: ✅ Bob odczytał "HI"\nPrzykład krok po kroku:
\nChcę zaszyfrować słowo "HI":
\n1. 'H' → ASCII: 72\n c₁ = 72^17 mod 3233 = 3000\n\n2. 'I' → ASCII: 73\n c₂ = 73^17 mod 3233 = 1486\nZaszyfrowana wiadomość: [3000, 1486]
\nWysyłasz te liczby do odbiorcy. Każdy może je zobaczyć, ale bez klucza prywatnego nie odszyfrują ;-)
\nm = 123\nc = 123^17 mod 3233 = 855\nProste? Proste! Ale tylko z kluczem prywatnym możesz to odwrócić.
\nOdbiorca bierze swój klucz prywatny i liczy:
\nm = c^d mod n\nDla naszego przykładu z "HI":
\n1. c₁ = 3000\n m₁ = 3000^2753 mod 3233 = 72 → 'H'\n\n2. c₂ = 1486\n m₂ = 1486^2753 mod 3233 = 73 → 'I'\nOdzyskaliśmy tekst: "HI"
\nMagia? Nie. Matematyka :-)
\nOK, mamy zaszyfrowaną wiadomość: [3000, 1486]
\nAle jak to wysłać mailem, przez API, w JSON-ie? Te liczby mogą być OGROMNE (setki cyfr dla prawdziwego RSA).
\nZaszyfrowana wiadomość dla 2048-bit RSA:\n[18446744073709551615, 98765432109876543210987654321...]\nTo niewygodne i może sprawiać problemy przy transmisji.
\nBase64 to sposób kodowania danych binarnych jako tekst (używając tylko 64 znaków: A-Z, a-z, 0-9, +, /).
\nflowchart TD\n Start([📝 START: Tekst 'HI'])\n\n Start --> ASCII[Konwersja ASCII<br/>'H' → 72<br/>'I' → 73]\n\n ASCII --> RSA[Szyfrowanie RSA<br/>c₁ = 72^17 mod 3233 = 3000<br/>c₂ = 73^17 mod 3233 = 1486]\n\n RSA --> HEX[Konwersja do hexadecimal<br/>3000₁₀ = 0x0BB8<br/>1486₁₀ = 0x05CE]\n\n HEX --> BYTES[Bajty: 0B B8 05 CE<br/>'4 bajty razem']\n\n BYTES --> BIN[Binary:<br/>00001011 10111000 00000101 11001110]\n\n BIN --> GROUP[Grupowanie po 6 bitów<br/>000010 111011 100000 000101 110011 10----]\n\n GROUP --> PAD[Dopełnienie zerami ostatniej grupy<br/>000010 111011 100000 000101 110011 100000]\n\n PAD --> CONV[Konwersja do znaków base64<br/>000010→C, 111011→7, 100000→g<br/>000101→F, 110011→z, 100000→g]\n\n CONV --> PADDING{Padding?<br/>4 bajty = niepełny blok}\n\n PADDING -->|Dodaj '==' dla wyrównania| RESULT[✅ Wynik: 'C7gFzg==']\n\n RESULT --> End([🌐 Gotowe do wysłania!])\n\n Info[💡 Base64 używa tylko 64 znaków:<br/>A-Z, a-z, 0-9, +, /<br/>Bezpieczne dla każdego protokołu!]\n\n RESULT -.-> Info\n\n style Start fill:#e1f5ff,stroke:#0066cc,stroke-width:3px\n style RESULT fill:#d4edda,stroke:#28a745,stroke-width:3px\n style End fill:#d4edda,stroke:#28a745,stroke-width:3px\n style PADDING fill:#fff3cd,stroke:#ffc107,stroke-width:2px\n style Info fill:#f0f0f0,stroke:#6c757d,stroke-width:2px\n style RSA fill:#ffe6e6,stroke:#dc3545,stroke-width:2px\nProces krok po kroku:
\nMamy zaszyfrowaną wiadomość: [3000, 1486]
\nKrok 1: Konwertuj każdą liczbę na bajty (hexadecimal)\n 3000 (decimal) = 0x0BB8 = [0B B8] (2 bajty)\n 1486 (decimal) = 0x05CE = [05 CE] (2 bajty)\n\nKrok 2: Połącz wszystkie bajty w jeden ciąg\n [0B B8 05 CE] (4 bajty razem)\n\nKrok 3: Bajty → base64\n Bajty: 0B B8 05 CE\n Binary: 00001011 10111000 00000101 11001110\n\n Grupujemy po 6 bitów (base64 używa 6-bitowych grup):\n 000010 111011 100000 000101 110011 10\n\n Dopełniamy ostatnią grupę zerami:\n 000010 111011 100000 000101 110011 100000\n\n Konwertujemy każdą 6-bitową grupę na znak base64:\n 000010 → C\n 111011 → 7\n 100000 → g\n 000101 → F\n 110011 → z\n 100000 → g\n\n Dodajemy padding (==) bo base64 pracuje w 3-bajtowych blokach:\n - 4 bajty = 3 bajty (pełny blok) + 1 bajt (niepełny)\n - 1 bajt → 2 znaki + '==' (padding do pełnego bloku)\n "C7gFzg=="\nPodsumowanie dla "HI":
\nOryginał: "HI"\nASCII: [72, 73]\nZaszyfrowane: [3000, 1486]\nBajty (hex): [0B B8 05 CE]\nBase64: "C7gFzg=="\nTeraz możesz wysłać "C7gFzg==" przez e-mail, JSON, gdziekolwiek!
\nOdbiorca robi proces odwrotny:
\n"C7gFzg==" → [0B B8 05 CE] → [3000, 1486] → deszyfruj → [72, 73] → "HI"\nW praktyce: większość bibliotek kryptograficznych automatycznie używa base64 do przesyłania zaszyfrowanych danych.
\nPierwsze pytanie dla ciebie:\nco byś musiał zrobić, żeby złamać RSA?
\nAno… rozłożyć n na czynniki pierwsze (p i q).\nDla małych liczb – luz.\nDla liczb 2048-bitowych? Powodzenia, serio ;-)
Całe bezpieczeństwo RSA opiera się na tym, że:
\n\n\nmnożyć jest łatwo, rozkładać – piekielnie trudno
\n
To dobre pytanie! Nie możemy przecież wypisać wszystkich liczb pierwszych i wybrać dwie – dla 1024 bitów byłoby ich astronomicznie dużo.
\nRozwiązanie: losowanie + test pierwszości
\nAlgorytm generowania liczby pierwszej:
\nIle to trwa?
\nWedług twierdzenia o liczbach pierwszych, prawdopodobieństwo że losowa liczba ~n jest pierwsza to ≈ 1 / ln(n).\nDla liczb 1024-bitowych: średnio trzeba sprawdzić ~355 liczb żeby trafić na pierwszą.
\nNa współczesnym komputerze? Kilka sekund do minuty.
\nTo najpopularniejszy test pierwszości w kryptografii:
\nW praktyce działa tak:
\ndla każdej rundy:\n wylosuj liczbę 'a'\n sprawdź matematyczne własności n\n jeśli test nie przejdzie → n NIE jest pierwsza\n\njeśli wszystkie testy przeszły → n jest prawdopodobnie pierwsza\nTest wykorzystuje małe twierdzenie Fermata i własności pierwiastków pierwotnych:
\nDla liczby pierwszej n:
\nn - 1 = 2^r × d (gdzie d nieparzyste)a z zakresu [2, n-2]x = a^d mod nx = 1 lub x = n-1 → możliwe, że pierwszar-1 razy: x = x² mod nx = n-1 → możliwe, że pierwszaPrzykład dla n=221:
\n221 - 1 = 220 = 4 × 55 = 2² × 55\nr=2, d=55\n\nLosujemy a=174:\nx = 174^55 mod 221 = 47\n47 ≠ 1 i 47 ≠ 220\n\nx = 47² mod 221 = 168\n168 ≠ 220\n\nTest nie przeszedł → 221 jest złożone! ✓\n(Faktycznie: 221 = 13 × 17)\nKluczowa własność: liczba złożona ma maksymalnie 25% szans oszukania testu w jednej rundzie. Po 40 rundach szansa: (0.25)^40 ≈ 10⁻²⁴ – praktycznie niemożliwe!
\nSą dwa podejścia do generowania liczb losowych:
\nPseudolosowe generatory (np. Mersenne Twister):
\nKryptograficznie bezpieczne generatory:
\n/dev/urandom, sprzętowe RNG)Słaba losowość = katastrofa bezpieczeństwa
\nW 2012 roku grupa badaczy znalazła 12 tysięcy publicznych kluczy RSA w internecie, które dzieliły wspólne czynniki pierwsze. Dlaczego? Słaba losowość przy generowaniu!\nZawsze używaj kryptograficznie bezpiecznych generatorów losowych!
\nPodstawowy RSA (o którym piszę) to tzw. "textbook RSA" – działa, ale ma problemy:
\nProblem deterministyczny:
\nencrypt("TAK") zawsze daje ten sam wynik\nencrypt("NIE") zawsze daje ten sam wynik\nAtakujący może zgadywać wiadomości i porównywać wyniki!
\nRozwiązanie: OAEP (Optimal Asymmetric Encryption Padding)
\nNigdy nie używaj "textbook RSA" w produkcji!
\nPodstawowy RSA bez paddingu jest podatny na ataki. Zawsze używaj OAEP lub innego sprawdzonego schematu paddingu. To nie jest opcjonalne – to wymóg bezpieczeństwa!
\nOperacja m = c^d mod n trwa różnie długo w zależności od bitów w d.
Atakujący mierząc czas deszyfrowania tysięcy wiadomości może odtworzyć klucz prywatny!
\nObrona:
\nNie implementuj kryptografii sam!
\nTiming attacks to tylko jeden z wielu zagrożeń. Używaj sprawdzonych bibliotek kryptograficznych (OpenSSL, libsodium, itd.) zamiast pisać własne implementacje. Eksperci spędzili lata chroniąc te biblioteki przed atakami!
\nW naszym przykładzie używałem małych liczb (p=61, q=53), ale w rzeczywistości...
\n| Rozmiar klucza | \nStatus | \nSzacowany czas złamania | \n
|---|---|---|
| 512 bitów | \n❌ Niezabezpieczone | \nZłamane w 1999 (RSA-155) | \n
| 768 bitów | \n❌ Niezabezpieczone | \nZłamane w 2009 (RSA-768, 2000 CPU-lat)2 | \n
| 1024 bity | \n⚠️ Przestarzałe | \nMożliwe dla dużych organizacji | \n
| 2048 bitów | \n✅ Minimum dzisiaj | \nBezpieczne do ~2030 | \n
| 3072 bity | \n✅ Zalecane | \nDługoterminowe bezpieczeństwo | \n
| 4096 bitów | \n✅ Bardzo bezpieczne | \nParanoja level ;-) | \n
Konkretnie: dla 2048-bitowego klucza każda liczba pierwsza (p i q) ma ~1024 bity = ~309 cyfr dziesiętnych.
\nPrzykładowa taka liczba:
\n179769313486231590772930519078902473361797697894230657273430081157732675805\n500963132708477322407536021120113879871393357658789768814416622492847430639\n474124377767893424865485276302219601246094119453082952085005768838150682342\n462881473913110540827237163350510684586298239947245938479716304835356329624\n224137217\nRozłożenie takiej liczby na czynniki? Z obecną technologią: niemożliwe w rozsądnym czasie.
\nTutaj sprawa się robi ciekawa...
\nAlgorytm Shora (kwantowy) teoretycznie może złamać RSA w czasie wielomianowym.
\nDzisiaj:
\nZa 10-20 lat?
\nZagrożenie kwantowe
\nKomputery kwantowe mogą złamać RSA w czasie wielomianowym (algorytm Shora). Choć dziś są za słabe, za 10-20 lat mogą stać się realnym zagrożeniem.\nPrzygotuj się: NIST standaryzuje już algorytmy post-kwantowe3. Dla długoterminowego bezpieczeństwa rozważ algorytmy odporne na komputery kwantowe (CRYSTALS-Kyber, Dilithium).
\nKlucze RSA możesz zapisać na różne sposoby:
\nTo najpopularniejszy format, wyglądający tak:
\n-----BEGIN RSA PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1SU1LfVLPHCozMxH2Mo\n4lgOEePzNm0tRgeLezV6ffAt0gunVTLw7onLRnrq0/IzW7yWR7QkrmBL7jTKEn5u\n...\n-----END RSA PUBLIC KEY-----\nFormat base64 + nagłówki. Uniwersalny, działa wszędzie.
\nBinarna wersja PEM – mniejsza, szybsza do parsowania, ale nieczytelna dla człowieka.
\nDla aplikacji webowych:
\n{\n "kty" : "RSA" ,\n "n" : "u1SU1LfVLPHCozMxH2Mo..." ,\n "e" : "AQAB" \n}Łatwo używać w API, JavaScript, itd.
\nJeśli korzystasz z:
\nssh-keygen domyślnie generuje klucze RSA…to tak, RSA tam siedzi i robi robotę.
\nRSA działa też w drugą stronę!
\nSzyfrowanie: klucz publiczny → szyfruj, klucz prywatny → deszyfruj\nPodpis cyfrowy: klucz prywatny → podpisz, klucz publiczny → zweryfikuj
\npodpis = hash(wiadomość)^d mod n\nweryfikacja = podpis^e mod n == hash(wiadomość)\nDzięki temu możesz udowodnić, że TO TY napisałeś daną wiadomość (bo tylko ty masz klucz prywatny).
\nRSA pochodzi od nazwisk trzech twórców: Ron Rivest, Adi Shamir i Leonard Adleman, którzy opublikowali algorytm w 1977 roku. Ciekawostka: brytyjski matematyk Clifford Cocks wynalazł podobny system kilka lat wcześniej (1973), ale jego praca była tajna! ↩
\nRSA-768 (232 cyfry dziesiętne) zostało złamane w 2009 roku przez międzynarodowy zespół badaczy. Projekt wymagał około 2000 lat czasu CPU na komputerach z tamtego okresu. To pokazuje, że rozmiar klucza ma kluczowe znaczenie dla bezpieczeństwa. ↩
\nW 2024 roku NIST (National Institute of Standards and Technology) opublikował pierwsze standardy kryptografii post-kwantowej: FIPS 203 (ML-KEM, wcześniej CRYSTALS-Kyber), FIPS 204 (ML-DSA, wcześniej CRYSTALS-Dilithium) i FIPS 205 (SLH-DSA, wcześniej SPHINCS+). To algorytmy odporne na ataki komputerów kwantowych. ↩
\nMonitorowanie systemów rozproszonych, mikroserwisów czy aplikacji webowych może wydawać się trudne. W praktyce jednak nie zawsze potrzebujemy zaawansowanych, skomplikowanych narzędzi – czasami wystarczy prosty model, który pomoże nam ocenić, czy wszystko działa jak należy.
\nJednym z takich modeli są metryki RED:
\nBrzmi prosto? Bo takie właśnie ma być 🙂
\nPierwsza metryka mówi nam, jak bardzo "obciążony" jest system. To po prostu tempo obsługi żądań.
\nMożesz na przykład sprawdzić:
\nrequests_per_second = total_requests / observation_timeDlaczego to ważne?
\nNie wystarczy wiedzieć, ile żądań trafia do aplikacji – trzeba też wiedzieć, ile z nich kończy się niepowodzeniem.
\nerror_rate = failed_requests / total_requestsMonitorując błędy, zwróć uwagę na:
\nDzięki tej metryce bardzo szybko dowiesz się, czy system działa poprawnie – nawet jeśli nadal odpowiada na żądania.
\nTrzecia metryka dotyczy czasu reakcji. Użytkownik może nie zauważyć, że serwer obsłużył milion żądań – ale na pewno zauważy, jeśli każda strona ładuje się 5 sekund.
\nDlatego mierzymy:
\navg_duration = total_time / total_requestsMożesz też śledzić percentyle (np. P95, P99), żeby zobaczyć, jak wygląda doświadczenie większości użytkowników, a nie tylko średnia.
\nBo te trzy proste metryki wystarczą, żeby odpowiedzieć na kluczowe pytania:
\nNie potrzebujesz od razu setek wskaźników ani skomplikowanych dashboardów – wystarczy RED jako podstawa monitoringu.
\nJak widzisz, metryki RED są proste i jednocześnie skuteczne 🙂\nJeśli wprowadzisz je do swojego systemu, będziesz miał zawsze jasny obraz tego, co się dzieje – niezależnie od tego, jak skomplikowana jest twoja architektura.
\n", "summary": "", "date_published": "2025-09-19T00:00:00-00:00", "image": "", "authors": [ { "name": "Błażej Gruszka", "url": "https://www.linkedin.com/in/blazejgruszka/", "avatar": "https://github.com/bgruszka.png" } ], "tags": [ "metrics", "devops", "observability" ], "language": "pl" } ] }