Există vreun motiv special pentru a folosi Diffie-Hellman în locul lui RSA pentru schimbul de chei? (Securitatea informațiilor, Schimb De Chei, Rsa, Diffie Hellman)

user10211 a intrebat.

Văd adesea că RSA este recomandat ca metodă de schimb de chei. Cu toate acestea, metoda de schimb de chei Diffie-Hellman pare să fie de asemenea sigură.

Există considerente de care ar trebui să se țină cont care să conducă la utilizarea unui algoritm în detrimentul celuilalt?

Comentarii

  • În primul rând, acesta se generalizează la criptografia cu curbă eliptică. –  > Por drxzcl.
  • Ei bine, începând de astăzi (Logjam), există un motiv special uriaș. –  > Por jeremyjjjbrown.
  • Legat de: crypto.stackexchange.com/questions/2867/… – –  > Por Ciro Santilli新疆棉花TRUMP BAN BAD.
4 răspunsuri
Thomas Pornin

Situația poate fi confuză, așa că haideți să punem lucrurile la punct.

RSA este două algoritmi, unul pentru criptare asimetrică și unul pentru semnături digitale. Acestea sunt două fiare distincte; deși au în comun aceeași operație matematică de bază și același format pentru chei, ele fac lucruri diferite în moduri diferite. Diffie-Hellman este un schimb de chei care este un alt tip de algoritm. Deoarece algoritmii nu fac același lucru, ați putea să-l preferați pe unul în detrimentul celuilalt, în funcție de contextul de utilizare.

Criptarea asimetrică și schimbul de chei sunt oarecum echivalente: cu criptarea asimetrică, puteți face un schimb de chei prin generarea unei chei simetrice aleatoare (o grămadă de octeți aleatori) și criptarea acesteia cu cheia publică a destinatarului. În schimb, puteți realiza criptarea asimetrică cu schimb de chei utilizând cheia rezultată în urma schimbului de chei pentru a cripta date cu un algoritm simetric, de exemplu, un algoritm de criptare simetrică. AES. În plus, Diffie-Hellman este un algoritm de schimb de chei cu o singură rundă: destinatarul trimite jumătatea sa („cheia publică DH”), expeditorul calculează jumătatea sa, obține cheia, criptează, trimite totul destinatarului, destinatarul calculează cheia, decriptează. Acest lucru este compatibil cu un sistem de comunicare one-shot, presupunând o distribuire prealabilă a cheii publice, adică funcționează cu e-mailurile.

Așadar, pentru restul răspunsului, presupun că vorbim despre RSA. criptare.


Secretizarea directă perfectă este o caracteristică ingenioasă care poate fi rezumată astfel: criptarea propriu-zisă se face cu o cheie pe care nu o păstrăm în preajmă, fiind astfel imună la furturi ulterioare. Acest lucru funcționează doar într-o configurație în care nu dorim să păstrăm datele criptate, adică nu pentru e-mailuri (e-mailul ar trebui să rămână criptat în cutia poștală), ci pentru transferul de date, cum ar fi SSL/TLS.

În acest caz, pentru a obține PFS, trebuie să generați o pereche de chei tranzitorii (criptare asimetrică sau schimb de chei) pentru criptarea propriu-zisă; deoarece, de obicei, se de asemenea, doriți un fel de autentificare, este posibil să aveți nevoie de o altă pereche de chei netranzitorii cel puțin pe o parte. Aceasta este ceea ce se întâmplă în SSL cu suitele de cifrare „DHE”: clientul și serverul utilizează DH pentru schimbul de chei, cu chei DH nou generate (care nu sunt stocate), dar serverul are nevoie și de o pereche de chei permanente pentru semnături (de tip RSA, DSA, ECDSA…).

Nu există nimic care să interzică în mod intrinsec generarea unei perechi de chei RSA tranzitorii. Într-adevăr, această a fost acceptată în versiunile mai vechi de SSL; a se vedea TLS 1.0, secțiunea 7.4.3. În acel caz, utilizarea unei chei RSA efemere a fost impusă nu pentru PFS, ci dimpotrivă: astfel încât cheile de criptare, deși nu erau stocate, să poată fi sparte ulterior, chiar dacă cheia permanentă a serverului era prea mare pentru a fi astfel brutalizată.

Cu toate acestea, există o avantaj al DH față de RSA pentru generarea de chei efemere: producerea unei noi perechi de chei DH este extrem de rapidă (cu condiția ca unii „parametri DH”, adică grupul în care se calculează DH, să fie reutilizați, ceea ce nu implică riscuri suplimentare, din câte știm). Aceasta nu este o problemă cu adevărat puternică pentru serverele mari, deoarece un server SSL foarte ocupat ar putea genera o nouă pereche de chei RSA „efemere” la fiecare zece secunde pentru o fracțiune foarte mică din puterea sa de calcul și ar putea să o păstreze doar în memoria RAM, și doar pentru zece secunde, ceea ce ar fi suficient de PFSish.

Cu toate acestea, RSA efemer nu mai este la modă și, mai ales, nu mai este standardizat. În contextul SSL, dacă doriți PFS, trebuie să folosiți DH efemer (aka „DHE”), pentru că asta este ceea ce este definit și susținut de implementările existente.


În cazul în care doriți nu doriți PFS, în special dacă doriți să puteți trage cu urechea la propriile conexiuni sau la conexiunile pupilelor dumneavoastră (în contextul în care un administrator de sistem își protejează utilizatorii prin intermediul unor filtre sau pentru anumite activități de depanare), aveți nevoie de chei neperemire. Și în acest caz, se pot utiliza RSA și DH. Cu toate acestea, tot în contextul SSL, DH nepereche necesită cheia serverului, din certificatul X.509 al acestuia, conține o cheie publică DH.

Cheile publice DH din certificate au fost promovate de guvernul federal al SUA în perioada în care RSA era brevetat. Dar aceste zile au trecut de mult. În plus, suportul DH nu a fost niciodată la fel de larg ca suportul RSA. Acesta este într-adevăr un exemplu interesant: DH a fost aprobat de guvern și standardizat de un organism instituțional (ca ANSI X9.42); pe de altă parte, RSA a fost standardizat de o companie privată care nu era în niciun fel autorizată oficial să producă standarde. Dar standardul RSA (PKCS#1) era liber pentru oricine și, deși exista un brevet, acesta era valabil numai în SUA, nu și în restul lumii; iar în SUA, RSA (compania) a distribuit o implementare gratuită a algoritmului (gratuită atâta timp cât era destinată unor utilizări necomerciale). Dezvoltatorii amatori, inclusiv Phil Zimmerman pentru PGP, au folosit astfel RSA, nu DH. Prețul standardului nu reprezintă nimic pentru o companie, dar poate însemna foarte mult pentru un individ. Acest lucru demonstrează impulsul care poate proveni, în industria software, de la amatori.

Așadar, acesta este un avantaj al RSA față de DH: standardul este disponibil în mod gratuit.


Pentru securitate, RSA se bazează (mai mult sau mai puțin) pe dificultatea de factorizării numerelor întregi, în timp ce DH se bazează (mai mult sau mai puțin) pe dificultatea de logaritmului discret. Acestea sunt probleme distincte. Se întâmplă ca cei mai cunoscuți algoritmi de spargere pentru spargerea oricăreia dintre ele să fie variante ale lui Sita generală a câmpurilor numerice, astfel încât ambele au aceeași complexitate asimptotică. La nivel înalt, o cheie DH de 1024 de biți este la fel de robustă împotriva criptanalizei ca o cheie RSA de 1024 de biți.

Totuși, dacă vă uitați la detalii, puteți observa că ultima parte a GNFS, partea de „algebră liniară”, care reprezintă gâtul de gâtul în cazul cheilor mari, este mai simplă în cazul RSA. Partea respectivă se referă la reducerea unei matrice teribil de mari. În cazul RSA, elementele matricei sunt doar biți (lucrăm în GF(2)), în timp ce în cazul DH elementele matricei sunt numere întregi modulo marele prim p. Aceasta înseamnă că matricea este de o mie de ori mai mare în cazul DH decât în cazul RSA. Deoarece dimensiunea matricei este cea mai mare problemă, putem afirma că DH-1024 este mai puternică decât RSA-1024.

Așadar, acesta este încă un avantaj al DH: se poate afirma că oferă o anumită robustețe suplimentară față de cheile RSA. de aceeași dimensiune.

Tot în ceea ce privește securitatea, DH se generalizează asupra altor grupuri, cum ar fi curbe eliptice. Logaritmul discret pe curbe eliptice nu este aceeași problemă ca logaritmul discret modulo un prim mare; GNFS nu se aplică. Prin urmare, nu există un singur Diffie-Hellman, ci mai multe algoritmi. „Criptodiversitatea” este un lucru bun pentru că ne permite să schimbăm algoritmii în cazul în care un cercetător găsește o modalitate de a sparge cu ușurință unii algoritmi.


În ceea ce privește performanță:

  • RSA criptare (cu cheia publică) este substanțial mai ieftină (deci mai rapidă) decât orice operațiune DH (chiar și cu curbe eliptice).
  • RSA decriptare (cu cheia privată) presupune cam aceeași cantitate de muncă ca și schimbul de chei DH, cu o rezistență similară. DH este puțin mai ieftin dacă utilizează o pereche de chei permanente, dar puțin mai scump dacă se include costul pentru construirea unei perechi de chei efemere.
  • În cazul SSL și DHE_RSA, serverul trebuie să genereze o pereche de chei DH și să o semneze, iar semnătura include valorile aleatorii ale clientului și serverului, deci acest lucru trebuie făcut pentru fiecare conexiune. Astfel, alegerea „DHE_RSA” în loc de „RSA” dublează oarecum factura CPU a serverului pentru SSL – nu că ar conta prea mult în practică, totuși. Este nevoie de un server foarte ocupat pentru a observa diferența.
  • O cheie publică DH este mai greu de codificat decât o cheie publică RSA, dacă cheia DH include parametrii DH; în caz contrar, este mai mică. În cazul SSL, utilizarea DHE_RSA în loc de RSA înseamnă schimbul a unu sau doi kilobiți de date în plus – și aici, din nou, doar o singură dată pentru fiecare client (din cauza reutilizării sesiunii SSL), deci nu este un aspect crucial. În unele protocoale specializate, ECDH (cu curbe eliptice) obține un avantaj important, deoarece elementele publice sunt mult mai mici.

Dacă proiectați un protocol într-o situație constrânsă (de exemplu, care implică carduri inteligente și I/O prin infraroșu sau ceva similar de mică putere), ECDH va fi probabil mai atractivă decât RSA.


Rezumat: veți prefera, de obicei, RSA față de DH sau DH față de RSA, pe baza constrângerilor de interoperabilitate: unul va fi mai bine susținut decât celălalt, în funcție de context. Performanța contează rareori (cel puțin nu atât de mult pe cât se presupune adesea). Pentru SSL, veți dori DH, deoarece este de fapt DHE, iar „E” (ca efemer) este binevenit, din cauza PFS.

Comentarii

  • Există o diferență semnificativă între DH și criptarea RSA: DH autentifică implicit atât expeditorul, cât și destinatarul, în timp ce RSA autentifică doar destinatarul. Dacă doriți să autentificați expeditorul într-o schemă neinteractivă, RSA nu poate înlocui cu ușurință DH. –  > Por CodesInChaos.
  • În acest caz, adaugă un alt avantaj: în DH complet static (clientul și serverul au amândoi un certificat cu o cheie publică DH în el, iar ambele chei folosesc aceiași parametri), atunci pot scăpa de generarea slabă sau inexistentă a numerelor aleatoare, înlocuind-o cu un simplu contor. Acesta este un caz limită. –  > Por Thomas Pornin.
  • Cum anume ai putea folosi un protocol de schimb de chei pentru criptarea asimetrică? Folosind RSA, oricine poate folosi cheia publică pentru a cripta ceva ce numai cheia privată poate decripta. Folosind DH, oricine dorește să trimită un mesaj privat către cheia privată ar trebui să creeze o nouă pereche de chei publice/private și să trimită cheia sa publică împreună cu mesajul, nu-i așa? –  > Por JSG.
  • @JSG Cam asta este exact ceea ce faceți. ElGamal funcționează în același mod – un lucru criptat are două componente, dintre care una este, în esență, o cheie publică (mai puțin parametrii grupului) și cealaltă este textul cifrat efectiv. –  > Por cpast.
  • @dasf Într-adevăr, DH este un schimb de chei de chei. Pentru a transforma acest lucru într-un criptare mecanism de criptare, îl cuplați cu o criptare simetrică: Alice și Bob se pun de acord asupra unei chei comune prin DH, apoi o folosesc cu ceva de genul AES pentru a cripta și decripta datele. Acesta este modul în care se procedează, de exemplu, în SSL/TLS. –  > Por Thomas Pornin.
Polinomial

Schimbul de chei efemere DH asigură un secret de transmitere perfectperfectă, ceea ce RSA singur nu oferă. Aceasta înseamnă că, chiar dacă cheia pe termen lung este divulgată la o dată ulterioară, cheile de sesiune pentru conexiunile individuale nu sunt compromise, chiar dacă întregul flux de date este capturat.

Comentarii

  • Adăugați pur și simplu „efemer” la RSA și veți obține, de asemenea, secretul perfect de transmitere. –  > Por JSG.
CodesInChaos

În contextul SSL, Polynomial are dreptate: Suitele (EC)DHE utilizează schimbul de chei efemere folosind Diffie-Hellman. Deoarece serverul uită cheia privată utilizată pentru schimb la scurt timp după ce a folosit-o, o compromitere a cheii pe termen lung a serverului nu permite unui atacator să decripteze toate comunicațiile anterioare, adică oferă un secret de transmitere perfect.

Recomand utilizarea suitelor ECDHE_RSA în SSL. Acestea oferă secretul perfect al transmiterii, un nivel de securitate ridicat pentru confidențialitate (128 de biți dacă se utilizează P256) și vă permit să utilizați același certificat atât pentru conexiunile RSA tradiționale, cât și pentru conexiunile ECDHE_RSA puternice.


Motivul pentru care proiectanții de protocoale folosesc DH pentru schimbul de chei efemere este performanța.

  • Generarea unei chei DH este relativ ieftină: este vorba pur și simplu de o înmulțire scalară cu o bază fixă (sau de o exponențializare dacă se folosește notația multiplicativă).

    Costul total al unui schimb de chei efemere folosind ECDH este o înmulțire scalară cu bază fixă (key-gen) și o înmulțire scalară cu variabilă (schimbul efectiv de chei) plus o operațiune cu cheie privată RSA folosind cheia pe termen lung care semnează cheia publică efemeră.

  • Generarea unei chei RSA este mult mai costisitoare, deoarece trebuie să găsiți două numere prime mari. Este foarte costisitor să generezi o nouă pereche de chei RSA pentru fiecare conexiune.

    Operațiunea cu cheie privată RSA este, de asemenea, puțin mai costisitoare decât un schimb de chei DH cu același nivel de securitate, dar acest lucru nu ne-a împiedicat să folosim RSA cu chei pe termen lung.

Cu ECC, diferența de performanță devine și mai mare, în special la niveluri de securitate mai ridicate. ECC de 256 de biți este destul de comun (securitate pe 128 de biți), pentru o securitate echivalentă folosind RSA ar fi nevoie de o cheie de 3000 de biți.

utilizator185953

Pe de altă parte, schimbul de chei RSA implică cheia secretă RSA a serverului, ceea ce nu se întâmplă în cazul (EC)DH.

Acest lucru înseamnă că, chiar dacă atacatorul obține mijloace de spargere a cheii RSA, va trebui să depună efortul de spargere pentru fiecare server/cheie.Cu (EC)DH, folosind un atac de tip logjam, cea mai mare parte a efortului de spargere se duce la spargerea întregului grup, așa-zis, algebric/eliptic. După aceea, spargerea conexiunilor individuale este ieftină.

Astfel, în timp ce schimbul de chei RSA îl motivează pe atacator să spargă doar cheile serverelor interesante, schimbul de chei (EC)DH îl motivează să atace cât mai multe conexiuni pentru a obține cel mai bun raport cost/atac.

Dacă vă întrebați de ce această proprietate a (Im)perfectForwardSecrecy este puțin cunoscută, probabil pentru că în prezent nu se cunoaște niciun atac de tip logjam împotriva schimbului de chei Diffie-Hellman cu curbă eliptică.

Aceasta ar trebui să fie o continuare/comentariu la postul https://security.stackexchange.com/a/35472/185953