I parametri di Diffie Hellman continuano a essere calcolati dopo 24 ore

48

Ho una nuova installazione di Arch Linux su un modello RaspberryPi B. Sto impostando OpenVPN e usando easy-rsa con OpenSSL 1.0.2d per generare chiavi e certificati iniziali. Tutto è andato bene finché non ho eseguito ./build-dh (script qui ). Sono trascorse 24 ore quando ho scritto questo .

Ho già configurato OpenVPN su altri dispositivi e sullo stesso RaspberryPi, ma con Raspbian. E non ricordo che questo comando abbia richiesto così tanto tempo. L'ultima volta che ho usato la chiave a 2048 bit ci sono voluti circa un'ora. Ora sto provando con una chiave a 4096 bit ed è passato più di un giorno. In effetti sono passate altre 12 ore da quando ho reiniziato tutte le mie impostazioni, abilitato il generatore di numeri casuali hardware build-it e provato di nuovo. Ma è ancora in corso.

cat /proc/sys/kernel/random/entropy_avail restituisce valori nell'intervallo di 3000-3100.

Qualcuno ha qualche precedente esperienza con questo? Come posso verificare se non si sta eseguendo in un ciclo?

    
posta kgizdov 28.07.2015 - 17:39
fonte

1 risposta

82

Se openssl utilizza un sacco di CPU, non viene bloccato in attesa di "entropia". OpenSSL è effettivamente sano in questo senso e utilizza un PRNG crittograficamente sicuro per estendere un seme iniziale in tutti i bit necessari .

Quando usi dhparam , OpenSSL non genera solo parametri DH; vuole anche affermare il suo status sociale, avendo cura di utilizzare per il modulo un cosiddetto "primo strong", che è inutile per la sicurezza ma richiede uno sforzo molto più computazionale. Un "primo strong" è un p primo tale che ( p -1) / 2 è anche primo. L'algoritmo di prima generazione ha questo aspetto:

  • Genera un intero dispari casuale p .
  • Verifica se p è primo. In caso contrario, loop.
  • Verifica se ( p -1) / 2 è primo. In caso contrario, loop.

Gli interi casuali a 4096 bit dispari sono probabilità che 1/2000 sia primo, e poiché entrambi p e ( p -1) / 2 devono essere primi, questo avrà bisogno in media di generare e testare la primalità su 4 milioni di numeri primi dispari. Ci vorrà del tempo.

Quando si passa da 2048-bit a 4096-bit, la densità dei primi potenti è divisa per 4, ei test di primalità saranno anche circa 4 volte più lenti, quindi se la generazione di un modulo DH a 2048 bit richiede 1 ora in media , la stessa macchina con lo stesso software userà in media 16 ore per un modulo DH a 4096 bit. Questa è solo medie ; ogni singola generazione può essere più veloce o più lenta, a seconda della tua fortuna.

La soluzione ragionevole sarebbe aggiungere l'opzione -dsaparam .

openssl dhparam -dsaparam -out /etc/ssl/private/dhparam.pem 4096

Questa opzione indica a OpenSSL di produrre parametri DH "simili a DSA ( p è tale che p -1 è un multiplo di un primo q , e il generatore ha ordine moltiplicativo q ). Questo è considerevolmente più veloce perché non ha bisogno di annidare i test di primalità, e quindi solo migliaia e non milioni di candidati verranno generati e testati.

Per quanto riguarda gli studiosi, i parametri simili alla DSA per la DH sono ugualmente sicuri; non vi è alcun reale vantaggio nell'usare "numeri primi forti" (la terminologia è tradizionale e in realtà non implica alcuna forza extra).

Allo stesso modo, puoi anche usare un modulo a 2048 bit, che è già molto lontano nella "non può rompere la zona". Il modulo a 4096 bit renderà i calcoli DH più lenti (che non è un problema reale per una VPN, questi si verificano solo all'inizio della connessione), ma in realtà non migliorerà la sicurezza.

In una certa misura, un modulo a 4096 bit può fregare auditor, ma è improbabile che i revisori siano molto impressionati da un Raspberry-Pi, che comunque è troppo economico.

    
risposta data 28.07.2015 - 18:09
fonte

Leggi altre domande sui tag