OpenVPN dhparam

16

Uno dei passaggi per la configurazione di OpenVPN sta eseguendo il comando openssl dhparam -out dh1024.pem 1024 . La pagina man mi dice che questo 1024 valore si riferisce al numero di bit.

  • Perché il valore 1024 è suggerito dagli esempi?
  • Devo usare un valore più grande come 4096 ?
    • Quale valore dovrei usare, quanti bit sono sufficienti, perché?
    • Le chiavi RSA a 1024 bit sono ora considerate deboli e spesso viene suggerito di utilizzare 2048 bit o più. Questo tipo di situazione si applica anche a questo file dhparam?
  • Il comando per generare questo file richiede circa 10 ore sull'appliance che userò come server OpenVPN. È sicuro generare questo file su una macchina più veloce e trasferirlo, o dovrei trattarlo come la maggior parte delle chiavi private e tenerlo solo su quell'host? Quanto dovrebbe essere segreto questo file?
posta Zoredache 14.09.2013 - 02:21
fonte

2 risposte

10

Gran parte di questo è stato già affrontato. Vedi la mia risposta e La risposta di Thomas a una domanda correlata per ulteriori informazioni sui parametri DH e DH.

I parametri sono solo numeri primi, non chiavi. Non hanno bisogno di essere unici o segreti, ma non devono essere creati appositamente da un aggressore. La lunghezza del bit si riferisce alla dimensione del primo non un tasto , quindi non è direttamente confrontabile con RSA. Nota che una chiave RSA di 2048 bit è composta da una coppia di numeri primi a 1024 bit, quindi sei sullo stesso livello rispetto alla fattorizzazione con un numero primo DH a 1024 bit rispetto a una chiave RSA 2048.

Come la risposta di Thomas sopra citata sottolinea, il numero non deve essere univoco o segreto, e in effetti la tua libreria crittografica può fornire un DH prime che funzionerà bene (supponendo che tu abbia fiducia nell'origine della libreria). Oppure puoi generarne uno tu stesso.

Dettagli aggiuntivi alla luce delle scoperte recenti

Prima di tutto, il consiglio sulle dimensioni prime è in gran parte ancora corretto - 512 è troppo piccolo, e 1024 è probabilmente abbastanza buono (alcuni problemi si applicano) mentre il 2048 è sicuramente sicuro.

Inoltre, è stato dimostrato un attacco di precomputazione in modo tale che se si conoscono i numeri primi in anticipo, si può fare la maggior parte del lavoro di cracking di un determinato scambio di DH in anticipo. È un mucchio di calcoli e impiega un'enorme quantità di tempo per calcolare tutti i possibili vettori per un determinato set di numeri primi, ma se un singolo set di numeri primi viene usato ovunque, allora c'è un incentivo a spendere tempo e denaro perché il risultato sarà essere così largamente utile.

Questo significa che usare gli stessi numeri primi di tutti gli altri è una sorta di responsabilità, perché è più probabile che la precomputazione sia stata eseguita dal tuo aggressore. Quindi probabilmente vorrai generare i tuoi numeri primi unici per tenerti fuori dal pool di attacchi. Inoltre, se tu stesso sei un obiettivo così attraente che un avversario è disposto a spendere milioni al mese per attaccarti (ad esempio obiettivi di dimensioni Facebook), la rotazione dei tuoi numeri primi su base regolare potrebbe essere giustificata.

Per quanto riguarda i costi e gli sforzi necessari per eseguire questa precomputazione, il lavoro per i numeri primi a 512 bit può essere fatto da un individuo dedicato, per i primi 1024 bit di uno stato nazione e primi da 2048 bit forse da un avanzato civiltà aliena.

    
risposta data 14.09.2013 - 04:38
fonte
4

La sicurezza DH si basa sulla durezza di Logaritmo discreto . Per un primo p scelto a caso, questa durezza aumenta con la dimensione di p , usando gli algoritmi più noti. Con alcune possibilità semi-sconvolgenti, accade che l'algoritmo più noto per il logaritmo discreto abbia molto in comune con l'algoritmo più noto per la fattorizzazione di interi ( GNFS ) e lo stesso costo di gestione asintotico. Pertanto, un modulo primo a 1024 bit per DH fornisce un livello di sicurezza che è grosso modo equivalente a quello di una chiave RSA a 1024 bit.

Se guardiamo i dettagli, un modulo a 1024 bit è un po 'più strong di una chiave RSA a 1024 bit, perché attraverso GNFS-per-discrete-logarithm e GNFS-for-factorization sono molto simili, il loro passo finale ( algebra lineare in un'enorme matrice) è più difficile per DL (il collo di bottiglia è la dimensione della matrice, per la fattorizzazione, gli elementi della matrice sono singoli bit, mentre per DL sono interi modulo p , cioè mille volte più grande) . A questa data, RSA-1024 è ancora ininterrotto, e 1024-bit DH ancora di più.

Tuttavia la rottura di DH a 1024 bit non è completamente irrealistica; ci vorrebbero una quantità non trascurabile di dollari (miliardi) e la costruzione di una macchina dedicata, per scopi speciali, e il tempo di esecuzione verrebbe comunque conteggiato in mesi o addirittura anni. Ma ciò è fattibile senza invocare l'aiuto di concetti di fantascienza (utili alieni "molto avanzati") o teologia (divinità utili). In questo senso, sì, dovresti sforzarti di usare un modulo più grande.

Non si desidera utilizzare un modulo di dimensioni eccessive perché il costo della CPU di utilizzo aumenta in modo significativo con tale dimensione (dovrebbe dovrebbe aumentare in modo quadratico, ma per alcune implementazioni è piuttosto cubico, vale a dire 4096 bit di costo 8 volte più di 2048 bit). 2048 bit vanno bene.

Un problema aggiuntivo e piuttosto fastidioso è che esistono implementazioni diffuse di SSL che non supportano il modulo DH superiore a 1024 bit. Se si utilizza OpenVPN, si sa che sia client che server sono OpenVPN, quindi non si dovrebbero avere problemi di interoperabilità.

Il primo p e il generatore g non sono segreti; possono anche essere condivisi. Vedi questa risposta per i dettagli. Puoi generarli perfettamente su qualche macchina e usarli su un altro. È inoltre possibile impostare tutte le appliance per utilizzare gli stessi parametri DH; questo non implica alcun ulteriore problema di sicurezza.

La generazione dei parametri DH con OpenSSL può richiedere molto tempo perché OpenSSL insiste, senza validi motivi razionali, nel generare i cosiddetti "primi sicuri", ovvero un p di prima qualità tale che < em> (p-1) / 2 è anche un numero primo. Questo è eccessivo e moltiplica il tempo di generazione di un fattore enorme (diverse centinaia). Ciò che è necessario per DH è che p è primo e p = qr + 1 per alcuni abbastanza grandi q ; un q a 256 bit sarebbe già abbastanza buono. Passare a un "sicuro primo" (cioè q di dimensione 1023 bit per un p a 1024 bit) non rende le cose più sicure, nonostante il nome (questo è un pezzo di vecchia tradizione che si è trasformata in un mito a causa della scarsa terminologia).

I "primati sicuri" hanno un piccolo vantaggio in termini di prestazioni (al momento dell'utilizzo, non alla generazione) in quanto consentono l'uso di g = 2 come generatore; ma questo vantaggio è minimo (conta solo per metà dello scambio di chiavi DH, ed è per lo più annullato dalle ottimizzazioni basate su finestre sull'esponenziazione modulare).

Se davvero volevi generare parametri DH su ogni appliance (che non è utile), potresti aggiungere il flag " -dsaparam " alla riga di comando per generare parametri DH senza insistere sull'avere "primi sicuri":

openssl dhparam -dsaparam -out dh2048.pem 2048

Questo dovrebbe essere molto più veloce. Ma generare i parametri DH su un PC e semplicemente codificarli in tutti i tuoi dispositivi è ancora più semplice, ed è sicuro.

    
risposta data 04.11.2014 - 20:59
fonte

Leggi altre domande sui tag