Come gestire un generatore SecureRandom lento?

Se si desidera un numero casuale crittograficamente forte in Java, si utilizza SecureRandom. Sfortunatamente, SecureRandompuò essere molto lento. Se lo utilizza /dev/randomsu Linux, può bloccare l'attesa per la creazione di entropia sufficiente. Come evitare la penalità per le prestazioni?

Qualcuno ha usato Uncommon Maths come soluzione a questo problema?

Qualcuno può confermare che questo problema di prestazioni è stato risolto in JDK 6?

Se vuoi veri dati casuali, sfortunatamente devi aspettarli. Ciò include il seme per un SecureRandomPRNG. La matematica non comune non può raccogliere dati casuali reali più rapidamente di SecureRandom, sebbene possa connettersi a Internet per scaricare i dati seed da un determinato sito Web. La mia ipotesi è che è improbabile che questo sia più veloce di /dev/randomdove sia disponibile.

Se vuoi un PRNG, fai qualcosa del genere:

SecureRandom.getInstance("SHA1PRNG");

Le stringhe supportate dipendono dal SecureRandomprovider SPI, ma è possibile enumerarle utilizzando Security.getProviders()e Provider.getService().

Sun ama SHA1PRNG, quindi è ampiamente disponibile. Non è particolarmente veloce come vanno i PRNG, ma i PRNG scricchiolano semplicemente i numeri, non bloccano la misurazione fisica dell'entropia.

L'eccezione è che se non si chiama setSeed()prima di ottenere i dati, il PRNG eseguirà il seeding stesso alla prima chiamata next()o nextBytes(). Di solito lo farà usando una quantità abbastanza piccola di dati casuali reali dal sistema. Questa chiamata potrebbe essere bloccata, ma renderà la tua fonte di numeri casuali molto più sicura rispetto a qualsiasi variante di "hash l'ora corrente insieme al PID, aggiungi 27 e spera per il meglio". Se tutto ciò di cui hai bisogno sono numeri casuali per un gioco, o se vuoi che lo stream sia ripetibile in futuro usando lo stesso seme a scopo di test, un seme insicuro è comunque utile.

Dovresti essere in grado di selezionare il più veloce ma leggermente meno sicuro / dev / urandom su Linux usando:

-Djava.security.egd=file:/dev/urandom

Tuttavia, questo non funziona con Java 5 e versioni successive ( Java Bug 6202721 ). La soluzione suggerita è di usare:

-Djava.security.egd=file:/dev/./urandom

(nota il extra /./)

Su Linux, l'implementazione predefinita per SecureRandomè NativePRNG(codice sorgente qui ), che tende ad essere molto lento. Su Windows, il valore predefinito è SHA1PRNG, che come altri hanno sottolineato, è possibile utilizzare anche su Linux se lo si specifica esplicitamente.

NativePRNGdifferisce da SHA1PRNGe Uncommons AESCounterRNG di Maths in quanto riceve continuamente entropia dal sistema operativo (leggendo da /dev/urandom). Gli altri PRNG non acquisiscono alcuna entropia aggiuntiva dopo la semina.

AESCounterRNG è circa 10 volte più veloce di SHA1PRNG, mentre IIRC è esso stesso due o tre volte più veloce di NativePRNG.

Se hai bisogno di un PRNG più veloce che acquisisca entropia dopo l'inizializzazione, vedi se riesci a trovare un'implementazione Java di Fortuna . Il PRNG di base di un'implementazione di Fortuna è identico a quello utilizzato da AESCounterRNG, ma esiste anche un sofisticato sistema di pooling di entropia e reseeding automatico.

Molte distro Linux (principalmente basate su Debian) configurano OpenJDK per l'uso /dev/randomper l'entropia.

/dev/random è per definizione lento (e può persino bloccare).

Da qui hai due opzioni su come sbloccarlo:

1. Migliora l'entropia, o
2. Ridurre i requisiti di casualità.

Opzione 1, migliorare l'entropia

Per ottenere più entropia /dev/random, prova il demone affamato . È un demone che raccoglie continuamente l'entropia di HAVEGE e funziona anche in un ambiente virtualizzato perché non richiede alcun hardware speciale, solo la CPU stessa e un clock.

Su Ubuntu / Debian:

apt-get install haveged
update-rc.d haveged defaults
service haveged start

Su RHEL / CentOS:

yum install haveged
systemctl enable haveged
systemctl start haveged

Opzione 2. Ridurre i requisiti di casualità

Se per qualche ragione la soluzione sopra non aiuta o non ti interessa la casualità crittograficamente forte, puoi /dev/urandominvece passare a , che è garantito per non bloccare.

Per farlo a livello globale, modifica il file jre/lib/security/java.securitynell'installazione Java predefinita da utilizzare /dev/urandom(a causa di un altro bug deve essere specificato come /dev/./urandom).

Come questo:

#securerandom.source=file:/dev/random
securerandom.source=file:/dev/./urandom

Quindi non dovrai mai specificarlo sulla riga di comando.

Nota: se si esegue la crittografia, è necessaria una buona entropia. Caso in questione: il problema del PRNG Android ha ridotto la sicurezza dei portafogli Bitcoin.

Ho avuto un problema simile con le chiamate al SecureRandomblocco per circa 25 secondi alla volta su un server Debian senza testa. Ho installato il havegeddemone per assicurarmi che /dev/randomsia mantenuto pieno , su server senza testa è necessario qualcosa del genere per generare l'entropia richiesta. Le mie chiamate a SecureRandomora forse impiegano millisecondi.

Se vuoi una casualità veramente "crittograficamente forte", allora hai bisogno di una forte fonte di entropia. /dev/randomè lento perché deve attendere che gli eventi di sistema raccolgano entropia (letture del disco, pacchetti di rete, spostamento del mouse, pressione dei tasti, ecc.).

Una soluzione più veloce è un generatore di numeri casuali hardware. Potresti già averne uno integrato nella scheda madre; consulta la documentazione hw_random per istruzioni su come capire se ce l'hai e su come usarla. Il pacchetto rng-tools include un demone che alimenterà l'entropia generata dall'hardware /dev/random.

Se un HRNG non è disponibile sul tuo sistema e sei disposto a sacrificare la forza dell'entropia per le prestazioni, vorrai seminare un buon PRNG con i dati /dev/randome lasciare che il PRNG faccia il grosso del lavoro. Esistono diversi PRNG approvati dal NIST elencati in SP800-90 che sono facili da implementare.

Usando Java 8, ho scoperto che sulla chiamata Linux SecureRandom.getInstanceStrong()mi avrebbe dato l' NativePRNGBlockingalgoritmo. Questo spesso si bloccherebbe per molti secondi per generare qualche byte di sale.

Sono passato invece a chiedere esplicitamente NativePRNGNonBlocking, e come previsto dal nome, non è più bloccato. Non ho idea di quali siano le implicazioni di sicurezza di questo. Presumibilmente la versione non bloccante non può garantire la quantità di entropia utilizzata.

Aggiornamento : Ok, ho trovato questa eccellente spiegazione .

In poche parole, per evitare il blocco, utilizzare new SecureRandom(). Questo utilizza /dev/urandom, che non blocca ed è sostanzialmente sicuro come /dev/random. Dal post: "L'unica volta che vorresti chiamare / dev / random è quando la macchina si avvia per la prima volta e l'entropia non si è ancora accumulata".

SecureRandom.getInstanceStrong() ti dà il RNG più forte in assoluto, ma è sicuro da usare solo in situazioni in cui un sacco di blocchi non ti influenzerà.

C'è uno strumento (almeno su Ubuntu) che alimenterà la casualità artificiale nel tuo sistema. Il comando è semplicemente:

rngd -r /dev/urandom

e potresti aver bisogno di un sudo nella parte anteriore. Se non hai il pacchetto rng-tools, dovrai installarlo. Ci ho provato e sicuramente mi ha aiutato!

Fonte: matt vs world

Ho affrontato lo stesso problema . Dopo aver cercato su Google con i giusti termini di ricerca, mi sono imbattuto in questo simpatico articolo su DigitalOcean .

hasged è una potenziale soluzione senza compromettere la sicurezza.

Sto semplicemente citando la parte pertinente dall'articolo qui.

Basato sul principio HAVEGE e precedentemente basato sulla libreria associata, hasged consente di generare casualità in base alle variazioni del tempo di esecuzione del codice su un processore. Poiché è quasi impossibile che un pezzo di codice impieghi lo stesso tempo esatto per essere eseguito, anche nello stesso ambiente sullo stesso hardware, i tempi di esecuzione di un singolo o più programmi dovrebbero essere adatti per eseguire il seeding di una fonte casuale. L'implementazione congedo semina l'origine casuale del tuo sistema (di solito / dev / random) usando le differenze nel contatore di timestamp (TSC) del tuo processore dopo aver eseguito ripetutamente un ciclo

Come installare hagedato

Seguire i passaggi in questo articolo. https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged

L'ho pubblicato qui

Il problema a cui hai fatto riferimento /dev/randomnon è con l' SecureRandomalgoritmo, ma con la fonte di casualità che utilizza. I due sono ortogonali. Dovresti capire quale dei due ti sta rallentando.

La pagina Matematica non comune che hai collegato menziona esplicitamente che non stanno affrontando la fonte di casualità.

Puoi provare diversi provider JCE, come BouncyCastle, per vedere se la loro implementazione SecureRandomè più veloce.

Una breve ricerca rivela anche patch Linux che sostituiscono l'implementazione predefinita con Fortuna. Non ne so molto di più, ma siete invitati a indagare.

Dovrei anche menzionare che mentre è molto pericoloso usare un SecureRandomalgoritmo mal implementato e / o una fonte di casualità, è possibile distribuire il proprio provider JCE con un'implementazione personalizzata di SecureRandomSpi. Per ottenere la firma del tuo provider dovrai eseguire un processo con Sun, ma in realtà è piuttosto semplice; hanno solo bisogno che tu gli invii un modulo via fax in cui dichiari di essere a conoscenza delle restrizioni all'esportazione degli Stati Uniti sulle librerie crittografiche.

Usa il random sicuro come fonte di inizializzazione per un algoritmo ricorrente; potresti usare un twister di Mersenne per il lavoro in serie invece di quello in UncommonMath, che è in circolazione da un po 'e si è dimostrato migliore di altri prng

http://en.wikipedia.org/wiki/Mersenne_twister

Assicurati di aggiornare di tanto in tanto il casuale sicuro utilizzato per l'inizializzazione, ad esempio potresti avere un casuale casuale generato per client, utilizzando un generatore pseudo casuale di mersenne twister per client, ottenendo un grado di randomizzazione abbastanza elevato

Secondo la documentazione , i diversi algoritmi utilizzati da SecureRandom sono, in ordine di preferenza:

• Sulla maggior parte dei sistemi * NIX
  1. NativePRNG
  2. SHA1PRNG
  3. NativePRNGBlocking
  4. NativePRNGNonBlocking
• Su sistemi Windows
  1. SHA1PRNG
  2. Windows PRNG

Da quando hai chiesto di Linux, sto ignorando l'implementazione di Windows, e anche SunPKCS11 che è davvero disponibile solo su Solaris, a meno che tu non l'abbia installato tu stesso - e quindi non te lo chiederesti.

Secondo la stessa documentazione, sono utilizzati questi algoritmi

SHA1PRNG
Il seeding iniziale viene attualmente eseguito tramite una combinazione di attributi di sistema e il dispositivo di raccolta entropia java.security.

NativePRNG
nextBytes() utilizza gli /dev/urandom
generateSeed()usi/dev/random

NativePRNGBlocking
nextBytes() e generateSeed()use/dev/random

NativePRNGNonBlocking
nextBytes() e generateSeed()utilizzo/dev/urandom

Ciò significa che se lo usi SecureRandom random = new SecureRandom(), scende in tale elenco fino a quando non ne trova uno che funziona, che in genere sarà NativePRNG. Ciò significa che si semina da /dev/random(o lo utilizza se si genera esplicitamente un seme), quindi lo utilizza /dev/urandomper ottenere i byte, gli ints, il double, i booleani successivi, il what-have-yous.

Poiché /dev/randomsta bloccando (blocca fino a quando non ha abbastanza entropia nel pool di entropia), ciò può impedire le prestazioni.

Una soluzione a ciò sta usando qualcosa di simile all'haged per generare abbastanza entropia, un'altra /dev/urandominvece sta usando . Mentre potresti impostarlo per l'intero jvm, una soluzione migliore è farlo per questa specifica istanza di SecureRandom, usando SecureRandom random = SecureRandom.getInstance("NativePRNGNonBlocking"). Si noti che quel metodo può generare NoSuchAlgorithmException se NativePRNGNonBlocking, quindi prepararsi al fallback al valore predefinito.

SecureRandom random;
try {
    random = SecureRandom.getInstance("NativePRNGNonBlocking");
} catch (NoSuchAlgorithmException nsae) {
    random = new SecureRandom();
}

Si noti inoltre che su altri sistemi * nix, /dev/urandompotrebbe comportarsi diversamente .

È /dev/urandomabbastanza casuale?

La saggezza convenzionale vuole che /dev/randomsia abbastanza casuale. Tuttavia, alcune voci differiscono. In "Il modo giusto di utilizzare SecureRandom" e "Miti su / dev / urandom" , si sostiene che /dev/urandom/sia altrettanto buono.

Gli utenti dello stack Sicurezza delle informazioni concordano con questo . Fondamentalmente, se devi chiedere, /dev/urandomva bene per il tuo scopo.

Non ho affrontato questo problema da solo, ma ho generato un thread all'avvio del programma che tenta immediatamente di generare un seme, quindi muore. Il metodo chiamato per i random si unirà a quel thread se è attivo, quindi la prima chiamata si blocca solo se si verifica molto presto nell'esecuzione del programma.

La mia esperienza è stata solo con l'inizializzazione lenta del PRNG, non con la generazione di dati casuali successivamente. Prova una strategia di inizializzazione più entusiasta. Dal momento che sono costosi da creare, trattalo come un singleton e riutilizzi la stessa istanza. Se c'è troppa contesa di thread per un'istanza, raggruppali o rendili thread-local.

Non scendere a compromessi sulla generazione di numeri casuali. Una debolezza compromette tutta la tua sicurezza.

Non vedo molti generatori COTS basati sul decadimento atomico, ma ci sono diversi piani là fuori per loro, se hai davvero bisogno di molti dati casuali. Un sito che ha sempre cose interessanti da guardare, tra cui HotBits, è il Fourmilab di John Walker.

Sembra che dovresti essere più chiaro sui tuoi requisiti RNG. Il requisito di RNG crittografico più forte (a quanto ho capito) sarebbe che anche se si conosce l'algoritmo utilizzato per generarli e si conoscono tutti i numeri casuali generati in precedenza, non è possibile ottenere alcuna informazione utile su nessuno dei numeri casuali generati nel futuro, senza spendere una quantità impraticabile di potenza di calcolo.

Se non hai bisogno di questa piena garanzia di casualità, probabilmente ci sono compromessi prestazionali appropriati. Tenderei ad essere d'accordo con la risposta di Dan Dyer su AESCounterRNG di Uncommons-Maths o Fortuna (uno dei suoi autori è Bruce Schneier, un esperto di crittografia). Nemmeno io l'ho mai usato, ma le idee sembrano affidabili a prima vista.

Vorrei pensare che se si potesse generare periodicamente un seme casuale iniziale (ad esempio una volta al giorno o ora o qualsiasi altra cosa), è possibile utilizzare un cifrario a flusso veloce per generare numeri casuali da pezzi successive del flusso (se il cifrario a flusso utilizza XOR poi basta passare un flusso di valori null o afferrare direttamente i bit XOR). Di ECRYPT eStreamil progetto ha molte buone informazioni tra cui parametri di riferimento delle prestazioni. Ciò non manterrebbe l'entropia tra i punti nel tempo in cui lo si riempie, quindi se qualcuno conoscesse uno dei numeri casuali e l'algoritmo che hai usato, tecnicamente potrebbe essere possibile, con molta potenza di calcolo, rompere il codice di flusso e indovina il suo stato interno per essere in grado di prevedere i numeri casuali futuri. Ma dovresti decidere se quel rischio e le sue conseguenze sono sufficienti per giustificare il costo di mantenimento dell'entropia.

Modifica: ecco alcune note di corso crittografiche su RNG che ho trovato in rete che sembrano molto rilevanti per questo argomento.

Se il tuo hardware lo supporta, prova a utilizzare Java RdRand Utility di cui sono l'autore.

Si basa sulle RDRANDistruzioni di Intel ed è circa 10 volte più veloce di SecureRandome nessun problema di larghezza di banda per l'implementazione di grandi volumi.

Si noti che questa implementazione funziona solo su quelle CPU che forniscono le istruzioni (cioè quando rdrandè impostato il flag del processore). È necessario creare un'istanza esplicita tramite il RdRandRandom()costruttore; nessuno specifico Providerè stato implementato.

Qualcos'altro da guardare è la proprietà securerandom.source nel file lib / security / java.security

Potrebbe esserci un vantaggio prestazionale nell'usare / dev / urandom piuttosto che / dev / random. Ricorda che se la qualità dei numeri casuali è importante, non scendere a compromessi che rompono la sicurezza.