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.