Criptare / decriptare RSA

Două numere prime și o trapă. O cheie RSA pornește de la două numere prime mari, aleatoare, p și q; produsul lor n (modulul, de unde „cheie de 2048 de biți”) se publică în cheia publică împreună cu exponentul e (aproape întotdeauna 65537). Cheia privată este d, inversul modular al lui e − calculat din p și q — plus scurtături derivate din numere prime, care accelerează operațiile cu cheia privată de 4×.

Criptarea și semnarea sunt aceeași exponențiere. Criptarea unui bloc de mesaj m înseamnă calculul m^e mod n; decriptarea este c^d mod n. Semnarea unui bloc pre-formatat cu exponentul privat și verificarea cu cel public este aceeași operație, în sens invers. Tot restul de pe această pagină — OAEP, PSS, PKCS#1 — ține de formatarea în siguranță a blocului, astfel încât exponențierea brută să nu fie niciodată expusă.

De ce este lent. O operație RSA pe o cheie de 2048 de biți costă de ordinul unui milion de ori mai mult CPU decât criptarea unui bloc cu AES. De aceea TLS folosește RSA (sau ECC) doar pentru a conveni asupra unei chei AES aleatoare, apoi trece la AES. Aceeași regulă se aplică oricărui lucru construit: RSA pentru cheie, AES pentru date.

Dimensiunea cheii. Lungimea modulului este butonul de securitate: 1024 de biți este considerată spartă prin politică (factorizarea este aproape de posibilitățile statelor), 2048 de biți ≈ 112 biți de rezistență simetrică, 3072 de biți ≈ 128 de biți, iar 15360 de biți ar corespunde unei chei simetrice de 256 de biți. Notă post-cuantică: algoritmul lui Shor sparge RSA direct pe un calculator cuantic mare — un motiv în plus să se păstreze durate de viață finite pentru chei.

Problema RSA-ului brut. RSA-ul de manual (m^e mod n pe mesajul brut) este determinist și maleabil: mesaje identice se criptează identic, un atacator poate înmulți un text cifrat cu criptarea lui 2 pentru a dubla mesajul clar, iar mesajele scurte cad prin atacul meet-in-the-middle. Nu trebuie folosit niciodată direct.

Ce face OAEP. OAEP (PKCS#1 v2, RFC 8017) amestecă mesajul cu o sămânță aleatoare printr-o rețea Feistel bazată pe hash, înainte de exponențiere. Rezultatul: criptarea este randomizată (același text clar dă un text cifrat diferit de fiecare dată — se rulează eșantionul OAEP de două ori și se compară rezultatele), modificarea se detectează la decriptare, iar mesajul trebuie să încapă în modul, cu spațiu pentru hash — limita k−2·hashLen−2 tabelată mai sus.

Eticheta. Un șir public opțional, legat în umplutură. Ambele părți trebuie să furnizeze aceeași etichetă, altfel decriptarea eșuează — ca AAD din AES-GCM, permite legarea textului cifrat de context (un nume de fișier, un identificator de algoritm). Gol este normal.

Criptarea PKCS#1 v1.5 lipsește intenționat. Umplutura din anii 1993 nu are integritate și scurge informații prin comportamentul erorilor de decriptare (atacul lui Bleichenbacher din 1998 transformă un padding oracle în decriptare completă, cu câteva milioane de texte cifrate construite; a spart încă sisteme reale, ca ROBOT, în 2017). WebCrypto refuză să o implementeze; la fel face și această pagină.

Semnarea = hash, apoi umplutură, apoi exponențiere. Ambele scheme fac hash la mesaj (SHA-256/384/512 aici), formatează digestul într-un bloc și aplică exponentul privat. Verificarea reformatează blocul cu cheia publică și compară. Diferența este formatarea:

Care se alege. Proiectele noi: PSS. Interoperabilitate cu certificate existente, JWT (RS256) sau colegi vechi: v1.5. Ambele sunt sigure ca scheme de semnătură — povestea dezastrului v1.5 se referă la umplutura de criptare, o construcție diferită, deși are un nume asemănător.

PEM este doar DER învelit în base64. Un fișier PEM este o etichetă plus base64 al unei structuri DER (ASN.1 binar). Eticheta spune ce structură este — și aceasta este întreaga diferență dintre cele patru formate pe care le generează pagina:

Aceeași cheie, învelișuri diferite. Toate cele patru casete de mai sus, după Generează, conțin aceeași pereche de chei — SPKI și PKCS#1 public conțin aceleași n, e; PKCS#8 și PKCS#1 privat conțin aceleași valori private. Pagina convertește între ele fără pierderi, în browser (autotestul ei verifică conversiile dus-întors). Confuzia formatelor este cea mai frecventă cauză a erorilor „cheie invalidă” la lipirea cheilor între unelte.

PEM-urile criptate (-----BEGIN ENCRYPTED PRIVATE KEY-----) sunt PKCS#8 cu un strat de criptare bazat pe parolă. Pagina nu le acceptă — se decriptează offline mai întâi (openssl pkcs8 -in enc.pem -out plain.pem).

• Criptarea datelor în volum mare cu RSA. Dincolo de limita strictă de dimensiune a OAEP, este absurd de lent. Modelul este: se generează o cheie AES aleatoare, se criptează cheia AES cu RSA-OAEP, se criptează datele cu AES-GCM, apoi se trimit ambele părți.
• Trimiterea cheii private pentru că „este un test”. Cheile de exemplu încorporate în vectorii acestei pagini sunt publicate intenționat — ele pot semna doar date de test. Cheile reale nu sunt așa.
• Verificarea cu cheia privată. De obicei „funcționează” matematic și unele unelte o permit, dar distribuirea unei chei private verificatorilor anulează tot modelul. Verificarea se face cu cheia publică (pagina o impune).
• Compararea semnăturilor octet cu octet pentru a verifica un cod. PSS (și OAEP) sunt randomizate: două rulări corecte dau rezultate diferite. Comparația se face prin verificare, nu prin egalitate — doar semnăturile v1.5 sunt deterministe.
• Chei de 1024 de biți „pentru că sunt mai rapide”. Sunt și ele în raza de acțiune a factorizării cu resurse mari. Argumentul vitezei a murit odată cu criptarea hibridă: RSA rulează o dată pe sesiune, nu pe octet.
• Fixarea unei lungimi de sare, diferită de lungimea hash-ului, pentru PSS. Verificatorul trebuie să fie de acord; lungimea hash-ului (alegerea acestei pagini și -sigopt rsa_pss_saltlen:32 din OpenSSL) este valoarea implicită interoperabilă.

De ce a eșuat decriptarea cu „cheie greșită, hash greșit sau text cifrat corupt”? Decriptarea OAEP eșuează dacă: nu este cheia privată potrivită, hash-ul diferă de cel din criptare, eticheta diferă sau s-a schimbat un octet al textului cifrat. Eroarea este intenționat identică în toate cazurile — dezvăluirea care verificare a eșuat ar fi în sine o scurgere de tip padding oracle.

Pot obține cheia publică din cheia privată? Da — formatele private conțin și n și e. Pagina afișează ambele după Generează; OpenSSL face asta cu openssl pkey -in priv.pem -pubout.

De ce 65537 ca exponent? Este număr prim, are doar doi biți de 1 (exponențiere rapidă) și este suficient de mare pentru a evita atacurile cu exponent mic, care lovesc e=3. Este alegerea standard din anii 1990; un exponent „ciudat” indică de obicei o cheie slabă sau nestandard.

Este RSA mort din cauza calculatoarelor cuantice? Încă nu — nu există un calculator care să poată rula algoritmul lui Shor pe un modul de 2048 de biți. Dar datele care trebuie să rămână secrete până în anii 2030+ se migrează deja; schemele hibride post-cuantice sunt răspunsul de inginerie.

Și openssl rsautl? Este strămoșul depreciat al lui pkeyutl. Folosește implicit umplutura de criptare v1.5 — un motiv în plus pentru care a fost retras.