Alimentazione / dev / pool entropico casuale?

Thomas Pornin

2011-09-12 20:11:27 UTC

view on stackexchange narkive permalink

Dovresti usare / dev / urandom , non / dev / random . Le due differenze tra / dev / random e / dev / urandom sono (sto parlando di Linux qui):

/ dev / random potrebbe essere teoricamente migliore nel contesto di un algoritmo teoricamente sicuro delle informazioni . Questo è il tipo di algoritmo che è protetto contro la tecnologia di oggi, e anche la tecnologia di domani e la tecnologia utilizzata dagli alieni e anche dall'iPad di Dio. L'algoritmo di informazione teoricamente sicuro è protetto contro una potenza di calcolo infinita. Inutile dire che tali algoritmi sono piuttosto rari e se ne usassi uno, lo sapresti. Inoltre, questo è un " potrebbe ": internamente, / dev / random utilizza le funzioni hash convenzionali, quindi è probabile che avrebbe comunque dei punti deboli se attaccato con potenza infinita (niente di cui preoccuparsi per gli aggressori terrestri, però).
/ dev / urandom non si bloccherà, mentre / dev / random può farlo. / dev / random mantiene un contatore di "quanta entropia ha ancora" assumendo che qualsiasi bit che ha prodotto sia un bit di entropia persa. Il blocco induce problemi molto reali, ad es. un server che non riesce ad avviarsi dopo un'installazione automatizzata perché si sta bloccando nella creazione della chiave del server SSH (sì, l'ho visto). / dev / urandom utilizza un generatore di numeri pseudo-casuali crittograficamente potente, quindi non si bloccherà mai.

Quindi vuoi usare / dev / urandom e smettila di preoccuparti di questa faccenda dell'entropia.

Ora potresti preoccuparti dell'entropia se stai scrivendo l'installatore di Linux. Il trucco è che / dev / urandom non si blocca mai, mai, anche quando dovrebbe: / dev / urandom è sicuro fintanto che ha ricevuto abbastanza byte di "entropia iniziale "dall'ultimo avvio (sono sufficienti 32 byte casuali). Una normale installazione di Linux creerà un seme casuale (da / dev / random ) al momento dell'installazione e lo salverà sul disco. Ad ogni riavvio, il seme verrà letto, inserito in / dev / urandom e un nuovo seme immediatamente generato (da / dev / urandom ) per sostituirlo. Quindi, questo garantisce che / dev / urandom avrà sempre abbastanza entropia iniziale per produrre alea crittograficamente forte, perfettamente sufficiente per qualsiasi lavoro crittografico banale, inclusa la generazione di password. L'unico punto critico è durante l'installazione: l'installatore deve ottenere un po 'di entropia da / dev / random , che potrebbe bloccarsi. Questo problema si verifica anche con CD live e altre varianti senza area di archiviazione permanente di lettura / scrittura. In queste situazioni, potresti voler trovare una fonte di entropia per assicurarti che / dev / random sia ben alimentato e non si blocchi.

Il sistema operativo stesso, e più precisamente il kernel, è nel posto giusto per raccogliere l'entropia dall'evento hardware, poiché gestisce l'hardware. Quindi c'è relativamente poco che puoi usare per l'entropia che il kernel non usa già. Una di quelle fonti rimanenti sono i dati della webcam: una webcam, anche di fronte a un muro bianco, emetterà dati con rumore termico e poiché emette molti dati, è un buon raccoglitore di entropia. Quindi prendi alcuni fotogrammi dalla webcam, sottoponili a hash con una funzione hash sicura (SHA-256) e scrivili in / dev / urandom . Questo è ancora un grosso problema.

Dovrei -1 per aver avuto l'audacia di suggerire che qualsiasi divinità userebbe un iPad. Tutti sanno che Dio usa la Santa PSP.

Forse il tuo dio. Mio dio usa un iPad e inoltre mi ha detto che dovresti farlo anche tu.

dio non ha nulla a che fare con questo, qualcuno vede il problema delle persone che si avviano da macchine virtuali che sono l'immagine teorica "seme" che gira su un intervallo non così lungo

Va notato che per qualsiasi sistema che non può salvare lo stato (workstation senza disco e router che non hanno un disco scrivibile), / dev / random può essere privo di entropia al primo avvio. Questo è normale che Linux e tutti i sistemi abbiano inizialmente una bassa quantità di entropia all'avvio, ma viene risolto salvando un seme casuale dall'ultimo avvio. Quando non hai un posto dove salvare il seme, avrai una mancanza iniziale di entropia. Questo è piuttosto un caso d'angolo, ma è comunque importante che alcuni sappiano di / dev / random.

Henri

2010-11-12 18:18:29 UTC

view on stackexchange narkive permalink

Puoi alimentarlo con il rumore bianco del tuo chip audio, se presente. Vedi questo articolo: http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt

* Potresti * farlo, suppongo, ma perché preoccuparsi? Non c'è motivo per farlo. Non è necessario. Il kernel già alimenta / dev / random e / dev / urandom con sufficiente entropia per questi scopi. Risparmia tempo per qualcosa che possa effettivamente migliorare la sicurezza. O, per dirla in un altro modo, la domanda chiedeva se suggeriremmo di aggiungere entropia extra. La risposta migliore è: no, non è necessario aggiungere ulteriore entropia. Vai avanti e usa / dev / urandom così com'è.

@D.W. dalla mia esperienza con i server VPS, dove non esiste una vera fonte di entropia esterna come tastiera, mouse ecc., il pool di entropia diventa molto basso e sembra influenzare cose come SSL. Potrebbe ancora funzionare, ma sembra che le cose stiano andando più lentamente. Dopo aver installato hasged (vedi un'altra risposta sotto), le cose stavano funzionando molto più agevolmente. Forse c'era qualcos'altro che avrei potuto aggiustare, o ho fatto qualcosa di sbagliato, ma non sono sicuro che tu possa sempre fare affidamento sul tuo kernel come fonte di entropia ...

Se ricordo bene, alcune delle principali fonti di entropia sono i registri della CPU che vengono modificati molto frequentemente a valori ragionevolmente casuali. Sfortunatamente, la virtualizzazione influisce negativamente sulla casualità di quei registri a causa di una pianificazione più prevedibile dei thread. Una soluzione è avere un HRNG sul server bare metal, quindi renderlo disponibile alle VM.

@YoavAner, il motivo per cui hai problemi è probabilmente perché stai usando `/ dev / random`. Non farlo. Dovresti usare `/ dev / urandom`. Allora non avrai quei problemi e sarà sicuro. Vedere [Feeding / dev / random entropy pool?] (Http://security.stackexchange.com/q/89/971), [È un rand da / dev / urandom sicuro per una chiave di accesso?] (Http: // security.stackexchange.com/q/3936/971), [Pseudo Random Generator non è inizializzato da (entropy pool)?] (http://security.stackexchange.com/q/14292/971). Versione breve: usa / dev / urandom, non / dev / random.

Grazie @D.W. So che urandom dovrebbe risolvere questo problema, ma non sono sicuro che tutti i componenti del mio sistema lo utilizzino necessariamente. Ad esempio, deve essere un componente del server web lighttpd, o openssl o chissà cosa che stava diventando divertente.

Grazie, @YoavAner. Ho impostato una domanda separata per cercare di identificare eventuali modifiche alla configurazione necessarie per evitare questa situazione: [Cosa devo configurare, per assicurarmi che il mio software utilizzi /dev/urandom?”(http://security.stackexchange.com/ q / 14386/971).

Bella idea e un elenco impressionante di prodotti, ma ad essere sincero, preferisco ancora installare un componente (già presente) e non dovermi preoccupare. Dubito che l'entropia di haveged sia meno sicura di quella di urandom, ma non ho la conoscenza o l'esperienza per valutarla.

krempita

2010-12-11 16:10:58 UTC

view on stackexchange narkive permalink

Conosco il demone di entropia audio e hasge che viene utilizzato da demone avente, provali.

Quelli non sono necessari. Il kernel già alimenta / dev / random e / dev / urandom con sufficiente entropia per questi scopi.

@D.W. non lo fa, hanno fatto qualcosa con il kernel (Linux) quindi non funziona più come una volta (si esaurisce molto velocemente) ...

@pootzko, Non ci credo. Sospetto che tu stia interpretando male ciò che vedi. / dev / urandom non viene mai esaurito.

prima di tutto, ho testato tutto questo (monitorando l'entropia usando metodi diversi, quindi quando l'entropia scende rapidamente a valori molto bassi, significa che si è esaurita). secondo, ho letto molto a riguardo al momento della domanda: il kernel ha gestito tutto questo in modo diverso qualche tempo fa. terzo - queste sono le tue parole "/ dev / random ha alcuni problemi: blocca, esaurisce la riserva di entropia" :))

+1 per aver forgiato. Dall'esperienza personale principalmente con i server virtuali, che non hanno una tastiera o un mouse collegati, e non possono nemmeno avere un microfono facilmente collegato, haveged assicura davvero che le cose funzionino senza intoppi. Quanto sia forte il suo PRNG, è difficile per me dirlo, ma sembra ragionevolmente sicuro (in particolare rispetto al solo affidarsi a urandom)

/ dev / urandom non si esaurisce, ma l'entropia di / dev / random può. La generazione di molte chiavi crittografiche o la creazione di molte connessioni SSL possono entrambe consumare molta entropia da / dev / random. Haveged aggiunge almeno un po 'più di entropia a / dev / random, in modo da non dover fare affidamento sul PRNG in / dev / urandom.

@CoverosGene / dev / urandom e / dev / random usano lo stesso PRNG.

@ViktorDahl / dev / blocchi casuali a meno che non abbia abbastanza entropia per evitare di fare affidamento esclusivamente sul PRNG. In realtà utilizza solo il PRNG come funzione di miscelazione.

La risposta più utile qui, non lo so 4 anni fa, ma oggi è molto facile esaurire il pool di kernel sui server, soprattutto se si desidera eseguire una sorta di resistenza alla previsione. Quindi molto utile. Ho fatto alcuni test con Haveged ed è molto buono, può aumentare la mia entropia a 0 da 1300 em in meno di 1 sec. Guardando oltre per aumentarlo ancora di più

spinkham

2010-11-20 03:03:35 UTC

view on stackexchange narkive permalink

Il miglior valore che ho riscontrato in un dispositivo HW per la casualità è la chiave di entropia simtec.
Ha una serie di protezioni integrate per proteggere da guasti e attacchi. Ad esempio, esegue i test di casualità FIPS 140-2 su ogni batch di 20 KB, spegnendosi se un numero statisticamente significativo di test fallisce. Ne ho ottenuto uno durante la generazione di molte chiavi per la ricerca DNSSEC e ha velocizzato notevolmente il mio lavoro. Supera tutti i test più difficili. (nota, verifica sempre periodicamente i tuoi flussi di casualità, indipendentemente da ciò che ti dice il venditore ;-)

La casualità hardware è probabilmente eccessiva. / dev / urandom è perfettamente adeguato per questa applicazione, senza nient'altro inserito.

D.W.

2011-01-17 11:46:50 UTC

view on stackexchange narkive permalink

1) Non è necessario aggiungere altra entropia a / dev / random , per usarla per le password. Il sistema lo fa già per te.

2) Per generare una password casuale, è meglio usare / dev / urandom , non / dev / random . ( / dev / random ha alcuni problemi: si blocca, esaurisce il pool di entropia in un modo che potrebbe causare il blocco di altri utenti di / dev / random . / dev / urandom è la migliore interfaccia per scopi generali.)

3) Ecco un semplice script che uso per generare una password casuale. Puoi usarlo.

  #! / Bin / sh # Crea una password a 48 bit (8 caratteri, 6 bit per carattere) dd if = / dev / urandom count = 1 2> / dev / null | base64 | testa -1 | cut -c4-11

i tuoi 1) e 2) sono opposti l'uno all'altro -> / dev / random esaurisce ... questo è esattamente il motivo per cui ho chiesto come alimentarlo ulteriormente ..

Stai confondendo due cose. / dev / random è * abbastanza sicuro * per la generazione di password senza entropia aggiuntiva, quindi inserire materiale in / dev / random non è necessario per la sicurezza, ma potrebbe essere necessario per le prestazioni. / dev / urandom è * anche * abbastanza sicuro per le password, ma non ha il problema di prestazioni di / dev / random, quindi dovrebbe essere preferito.

DUzun

2014-09-25 03:44:49 UTC

view on stackexchange narkive permalink

Uso una combinazione di origini dati e un buon algoritmo di hashing per generare dati casuali.

Su un server web puoi combinare i dati del server (HW, SW, prestazioni), i dati del cliente (utente- agent, request-time, cookie, URL variable, qualunque cosa tu possa raccogliere), alcuni dati esterni (come random.org), mescola tutto con let say sha1 (mixed_data + time + some_secret_key) e ottieni bit abbastanza imprevedibili di dati casuali.

Potresti anche prendere in considerazione l'utilizzo di P2PEG per raccogliere facilmente l'entropia da client e server.

Nakedible

2010-12-12 02:59:27 UTC

view on stackexchange narkive permalink

Le password, se sono brevi, possono sempre essere violate con la forza bruta se la velocità o il numero di tentativi non è limitato. Se, d'altra parte, i tentativi sono limitati (es. Login interattivo), anche una piccola quantità di entropia fondamentalmente non crackabile - la quantità di tentativi richiesti diventa molto presto proibitiva.

Quindi, non dovrebbero esserci casi dove sarebbe importante ottenere un'entropia veramente buona per le password.

Quindi usa / dev / urandom, è più che sufficiente.

Le altre risposte fornite qui sono buoni commenti su come conservare il tuo / dev / random ha fornito abbastanza entropia, però, se ne hai bisogno.

Questa risposta non è accurata nella pratica o è formulata in modo confuso. In pratica, si possono scegliere password con sufficiente entropia da non poter essere violate con la forza bruta. O, per dirla in altro modo, in pratica gli aggressori sono sempre limitati nel numero di tentativi che possono fare, semplicemente dal tempo limitato a loro disposizione. Sono d'accordo con il consiglio di usare / dev / urandom invece di / dev / random, ma la giustificazione non è corretta.

justin

2012-04-30 14:02:31 UTC

view on stackexchange narkive permalink

GUChaos.c recupera numeri casuali da random.org e li modifica al volo tramite un codice di sostituzione prima di alimentare / dev / random .

[Non ** ** semplicemente fidati (chiamiamoli semplicemente) "servizi" come random.org per scopi crittografici.] (Http://crypto.stackexchange.com/q/1619/12164)

Buktop

2013-08-14 01:35:15 UTC

view on stackexchange narkive permalink

È strano vedere un sacco di raccomandazioni sull'uso di / dev / urandom invece di usare / dev / random perché quando / dev / random si esaurisce e / dev / urandom usa ripetutamente l'ultima entropia ciò che è fortemente insicuro per criticità a lungo termine parametri.

Dovresti leggere questi consigli! Soprattutto [di Thomas Pornin] (http://security.stackexchange.com/questions/89/feeding-dev-random-entropy-pool/7074#7074). Stai fraintendendo l'entropia. Leggere da `/ dev / random` o` / dev / urandom` non esaurisce l'entropia (almeno non su una scala che sarebbe importante: leggere 2 ^ n bit esaurisce al massimo n bit di entropia).

Credi davvero che l'entropia che un sistema operativo può ottenere sia inesauribile?

"Generare una vera entropia in un computer è abbastanza difficile perché nulla, al di fuori della fisica quantistica, è casuale. Il kernel Linux utilizza le attività di tastiera, mouse, rete e disco, con un algoritmo crittografico (SHA1), per generare i dati per / dev / dispositivo casuale. Uno dei problemi con questo è che l'input non è costante, quindi il pool di entropia del kernel può facilmente diventare vuoto. Il dispositivo / dev / random è chiamato "dispositivo di blocco". Ciò significa che se il pool di entropia è applicazioni vuote provare a usare / dev / random dovrà aspettare, indefinitamente, fino a quando qualcosa riempirà il pool. "

"Quando viene letto, il dispositivo / dev / random restituirà solo byte casuali entro il numero stimato di bit di rumore nel pool di entropia. / Dev / random dovrebbe essere adatto per usi che richiedono una casualità di qualità molto elevata come il pad monouso o generazione di chiavi. Quando il pool di entropia è vuoto, le letture da / dev / random si bloccheranno fino a quando non verrà raccolto ulteriore rumore ambientale. "

"Una lettura dal dispositivo / dev / urandom non bloccherà l'attesa di più entropia. Di conseguenza, se non c'è sufficiente entropia nel pool di entropia, i valori restituiti sono teoricamente vulnerabili a un attacco crittografico sugli algoritmi utilizzati dal driver . "

In pratica sì. Una volta riempito il pool di entropia una volta, ci vorrebbe più della durata dell'hardware per esaurirlo.

Tieni presente che / dev / random e / dev / urandom forniscono solo 160 bit di entropia per una richiesta.

Ora calcola quanto tempo ci vuole per esaurire 160 bit di entropia.

Possiamo mescolare questi bit con l'hashing (come esempio) e produrre in modo relativamente sicuro 2 ^ 48 blocchi di 512 bit di lunghezza. Tuttavia, vorrei raccomandare di utilizzare 128 bit di entropia per produrre solo una chiave RSA (3072 bit) e aggiornare l'entropia per generare la chiave successiva. Ovviamente costa e ha senso implementare se nascondi qualcosa che costa almeno lo stesso.