it-swarm.dev

C'è qualche motivo particolare per usare Diffie-Hellman su RSA per lo scambio di chiavi?

Vedo spesso che RSA viene raccomandato come metodo di scambio di chiavi. Tuttavia, anche il metodo di scambio delle chiavi Diffie-Hellman sembra essere sicuro.

C'è qualche considerazione che uno dovrebbe prendere in considerazione che porterebbe all'uso di un algoritmo rispetto all'altro?

121
user10211

La situazione può essere confusa, quindi sistemiamo le cose.

RSA è due algoritmi, uno per la crittografia asimmetrica e uno per firme digitali . Queste sono due bestie distinte; sebbene condividano la stessa operazione matematica principale e il formato per le chiavi, fanno cose diverse in modi diversi. Diffie-Hellman è un algoritmo scambio di chiavi , che è ancora un altro tipo di algoritmo. Dato che gli algoritmi non fanno la stessa cosa, potresti preferire l'uno all'altro a seconda del contesto di utilizzo.

La crittografia asimmetrica e lo scambio di chiavi sono in qualche modo equivalenti: con la crittografia asimmetrica, è possibile effettuare uno scambio di chiavi in ​​virtù della generazione di una chiave simmetrica casuale (un gruppo di byte casuali) e della crittografia con la chiave pubblica del destinatario. Al contrario, è possibile eseguire la crittografia asimmetrica con lo scambio di chiavi utilizzando la chiave risultante dallo scambio di chiavi per crittografare i dati con un algoritmo simmetrico, ad es. [~ ~ #] AES [~ ~ #] . Inoltre, Diffie-Hellman è un algoritmo di scambio di chiavi di andata e ritorno: il destinatario invia la sua metà ("chiave pubblica DH"), il mittente calcola la sua metà, ottiene la chiave, crittografa, invia l'intero lotto al destinatario, il destinatario calcola la chiave , decripta. Questo è compatibile con un sistema di comunicazione one-shot, presupponendo una pre-distribuzione della chiave pubblica, ovvero funziona con le e-mail.

Quindi per il resto di questa risposta, suppongo che stiamo parlando di RSA crittografia.


Perfect Forward Secrecy è una caratteristica elegante che può essere sintetizzata come: la crittografia effettiva viene eseguita con una chiave che non manteniamo intorno, quindi immune al furto ulteriore. Funziona solo in una configurazione in cui non vogliamo mantenere i dati crittografati, ovvero non per le e-mail (l'e-mail deve rimanere crittografata nella cassetta postale), ma per il trasferimento di dati come SSL/TLS .

In tal caso, per ottenere PFS, è necessario generare una coppia di chiavi temporanea (crittografia asimmetrica o scambio di chiavi) per la crittografia effettiva; poiché di solito anche desideri una sorta di autenticazione, potresti aver bisogno di un'altra coppia di chiavi non transitoria almeno da un lato. Questo è ciò che accade in SSL con le suite di crittografia "DHE": client e server utilizzano DH per lo scambio di chiavi, con chiavi DH appena generate (non memorizzate), ma il server necessita anche di una coppia di chiavi permanente per le firme (di tipo RSA, DSA, ECDSA ...).

Non c'è nulla che vieti intrinsecamente di generare una coppia di chiavi RSA transitoria. In effetti, questo era supportato nelle versioni precedenti di SSL; vedere TLS 1. , sezione 7.4.3. In quel caso, l'uso di una chiave RSA effimera era obbligatorio non per PFS, ma piuttosto il contrario: in modo che le chiavi di crittografia, sebbene non memorizzate, potessero essere successivamente interrotte, anche se la chiave permanente del server era troppo grande per essere così brutalizzata.

Vi è, tuttavia, un vantaggio di DH rispetto a RSA per la generazione di chiavi temporanee: la produzione di una nuova coppia di chiavi DH è estremamente veloce (purché vengano riutilizzati alcuni "parametri DH", ovvero il gruppo in cui viene calcolato DH, il che non comporta rischi aggiuntivi, per quanto ne sappiamo). Questo non è un grosso problema per i grandi server, perché un server SSL molto impegnato potrebbe generare una nuova coppia di chiavi RSA "effimera" ogni dieci secondi per una frazione molto piccola della sua potenza di calcolo, e mantenerlo in RAM, e solo per dieci secondi, che sarebbe abbastanza PFSish.

Tuttavia, l'effimera RSA è passata di moda e, soprattutto, fuori standardizzazione. Nel contesto di SSL, se si desidera PFS, è necessario utilizzare il DH effimero (noto anche come "DHE"), perché è quello che viene definito e supportato dalle implementazioni esistenti.


Se fai no vuoi PFS, in particolare se vuoi essere in grado di intercettare le tue connessioni o le connessioni dei tuoi reparti (nel contesto di un amministratore di sistema che protegge i suoi utenti attraverso alcuni filtri, o per alcune attività di debug), sono necessarie chiavi non effimere. Anche in questo caso, è possibile utilizzare RSA e DH. Tuttavia, sempre nel contesto di SSL, DH non effimero richiede che la chiave del server, nel suo certificato X.509, contenga una chiave pubblica DH.

Le chiavi pubbliche DH nei certificati sono state rimandate dal governo federale degli Stati Uniti ai tempi in cui RSA era stato brevettato. Ma in questi giorni sono lontani. Inoltre, il supporto DH non è mai stato ampio come il supporto RSA. Questo è davvero un esempio interessante: DH è stato approvato dal governo e standardizzato da un organo istituzionale (come ANSI X9.42 ); d'altra parte, RSA è stata standardizzata da una società privata che non aveva il diritto ufficiale di produrre standard. Ma lo standard RSA ( PKCS # 1 ) era gratuito per chiunque da leggere, e sebbene esistesse un brevetto, era valido solo negli Stati Uniti, non nel resto del mondo; e negli Stati Uniti, RSA (la società) ha distribuito gratuitamente l'implementazione dell'algoritmo (gratuito purché fosse per usi non commerciali). Gli sviluppatori amatoriali, tra cui Phil Zimmerman per PGP, hanno quindi utilizzato RSA, non DH. Il prezzo dello standard non è niente per un'azienda, ma può significare molto per un individuo. Ciò dimostra l'impulso che può provenire, nel settore del software, dai dilettanti.

Quindi questo è uno vantaggio di RSA su DH : lo standard è liberamente disponibile.


Per la sicurezza , RSA si affida (più o meno) alla difficoltà di fattorizzazione in numeri interi , mentre DH fa affidamento (più o meno) sulla difficoltà di logaritmo discreto . Sono problemi distinti. Accade così che gli algoritmi di rottura più noti per la rottura siano varianti del General Number Field Sieve , quindi entrambi hanno la stessa complessità asintotica. Da un punto di vista di alto livello, una chiave DH a 1024 bit è robusta rispetto alla crittoanalisi come una chiave RSA a 1024 bit.

Se si osservano i dettagli, tuttavia, è possibile notare che l'ultima parte di GNFS, la parte "algebra lineare", che rappresenta il collo di bottiglia nel caso di chiavi di grandi dimensioni, è più semplice nel caso di RSA. Quella parte riguarda la riduzione di una matrice terribilmente grande. Nel caso di RSA, gli elementi della matrice sono solo bit (lavoriamo in GF (2)), mentre per DH gli elementi della matrice sono numeri interi nel grande primo p. Ciò significa che la matrice è mille volte più grande per DH che per RSA. Poiché la dimensione della matrice è il collo di bottiglia, potremmo affermare che DH-1024 è più forte di RSA-1024.

Quindi questo è un ulteriore vantaggio di DH: si può affermare che offre una certa robustezza in più rispetto alle chiavi RSA della stessa dimensione.

Sempre per sicurezza, DH si generalizza su altri gruppi, come curve ellittiche . Il logaritmo discreto sulle curve ellittiche non è lo stesso problema del logaritmo discreto modulo un grande numero primo; GNFS non si applica. Quindi non esistono algoritmi one Diffie-Hellman, ma many. "Cryptodiversity" è una buona cosa perché ci consente di cambiare algoritmo nel caso in cui un ricercatore trovi un modo per rompere facilmente alcuni algoritmi.


Per quanto riguarda rendimento :

  • RSA crittografia (con la chiave pubblica) è sostanzialmente più economico (quindi più veloce) di qualsiasi operazione DH (anche con curve ellittiche).
  • RSA decryption (con la chiave privata) comporta più o meno la stessa quantità di lavoro dello scambio di chiavi DH con resistenza simile. DH è un po 'più economico se utilizza una coppia di chiavi permanente, ma un po' più costoso se si include il costo per la costruzione di una coppia di chiavi temporanea.
  • Nel caso di SSL e DHE_RSA, il server deve generare una coppia di chiavi DH e firmarlo e la firma include i valori casuali del client e del server, quindi questo deve essere fatto per ogni connessione. Quindi, scegliendo "DHE_RSA" anziché "RSA" si raddoppia la bolletta della CPU sul server per SSL - non importa che in pratica sia molto importante. Ci vuole un server molto occupato per notare la differenza.
  • Una chiave pubblica DH è più grande da codificare rispetto a una chiave pubblica RSA, if la chiave DH include i parametri DH; altrimenti è più piccolo. Nel caso di SSL, usare DHE_RSA invece di RSA significa scambiare uno o due kilobyte di dati in più - di nuovo lì, solo una volta per client (a causa del riutilizzo della sessione SSL), quindi non è certo un punto cruciale. In alcuni protocolli specializzati, ECDH (con curve ellittiche) ottiene un vantaggio importante perché gli elementi pubblici sono molto più piccoli.

Se si sta progettando un protocollo in una situazione limitata (ad es. Coinvolgendo smart card e I/O su infrarossi o qualcosa di simile a bassa potenza), ECDH probabilmente sarà più attraente di RSA.


Riepilogo: di solito preferirai RSA su DH o DH su RSA, in base ai vincoli di interoperabilità: uno sarà più supportato dell'altro, a seconda del contesto. Le prestazioni raramente contano (almeno non tanto quanto si presume spesso). Per SSL, ti consigliamo DH perché in realtà è DHE, e la "E" (come effimera) è piacevole da avere, a causa di PFS.

140
Thomas Pornin

Lo scambio di chiavi effimero DH fornisce perfetto segreto in avanti , che RSA da solo non lo fa. Ciò significa che anche se la chiave a lungo termine viene trapelata in un secondo momento, le chiavi di sessione per le singole connessioni non vengono compromesse, anche se viene acquisito l'intero flusso di dati.

19
Polynomial

Nel contesto di SSL Polynomial ha ragione: le suite (EC) DHE usano lo scambio di chiavi effimero usando Diffie-Hellman. Poiché il server dimentica la chiave privata utilizzata per lo scambio subito dopo averla utilizzata, un compromesso della chiave a lungo termine del server non consente a un utente malintenzionato di decrittografare tutte le comunicazioni passate, ovvero fornisce Perfect forward secrecy .

Consiglio di utilizzare le suite ECDHE_RSA in SSL. Offrono un perfetto segreto diretto, un elevato livello di sicurezza per la riservatezza (128 bit se si utilizza P256) e consentono di utilizzare lo stesso certificato sia per le connessioni RSA legacy che per le connessioni ECDHE_RSA forti.


Il motivo per cui i progettisti di protocollo utilizzano DH per lo scambio di chiavi temporaneo è la prestazione.

  • La generazione di una chiave DH è relativamente economica: è semplicemente una moltiplicazione scalare con una base fissa (o esponenziale se si utilizza la notazione moltiplicativa).

    Il costo totale di uno scambio di chiavi temporaneo tramite ECDH è una moltiplicazione scalare con base fissa (key-gen) e una moltiplicazione scalare con variabile (lo scambio di chiavi effettivo) più un'operazione di chiave privata RSA che utilizza la chiave a lungo termine che firma il chiave pubblica effimera.

  • La generazione di una chiave RSA è molto più costosa, poiché è necessario trovare due numeri primi di grandi dimensioni. È molto costoso generare una nuova coppia di chiavi RSA per ogni connessione.

    L'operazione di chiave privata RSA è anche un po 'più costosa di uno scambio di chiavi DH con lo stesso livello di sicurezza, ma ciò non ci ha impedito di utilizzare RSA con chiavi a lungo termine.

Con ECC il divario di prestazioni diventa ancora più ampio, specialmente a livelli di sicurezza più elevati. L'ECC a 256 bit è piuttosto comune (sicurezza a 128 bit), per una sicurezza equivalente utilizzando RSA sarebbe necessaria una chiave a 3000 bit.

9
CodesInChaos

Al contrario, lo scambio di chiavi RSA coinvolge la chiave RSA segreta del server, cosa che (EC) DH no.

Ciò significa che anche se l'attaccante ottiene i mezzi per decifrare la chiave RSA, dovrà spendere lo sforzo di cracking per ciascun server/chiave. Con (EC) DH, usando un attacco simile al logjam, la maggior parte dello sforzo di cracking va a rompere l'intero gruppo, algebrico/ellittico. Successivamente, interrompere le singole connessioni è economico.

Quindi, mentre lo scambio di chiavi RSA motiva l'attaccante a decifrare solo le chiavi di server interessanti, lo scambio di chiavi DH (EC) lo motiva ad attaccare quante più connessioni possibili per ottenere il miglior rapporto costo/attacco.

Se ti chiedi, perché questa proprietà di (Im) perfectForwardSecrecy è poco nota, è probabilmente perché non è attualmente noto alcun attacco simile a un logjam contro lo scambio di chiavi Diffie-Hellman della curva ellittica.

Questo dovrebbe essere un follow-up/commento da pubblicare https://security.stackexchange.com/a/35472/18595

0
user185953