Feeding / dev / random entropy pool?

Puoi alimentarlo con rumore bianco dal tuo chip audio, se presente. Vedi questo articolo: link

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 di informazione teoricamente sicuro . Questo è il tipo di algoritmo che è sicuro contro la tecnologia di oggi, e anche la tecnologia di domani, e la tecnologia utilizzata dagli alieni, e anche l'iPad di Dio stesso. Algoritmo teoricamente sicuro di informazioni sono sicuri contro la potenza di calcolo infinita. Inutile dire che tali algoritmi sono piuttosto rari e se ne stai usando uno, lo sapresti. Inoltre, questo è un " potrebbe ": internamente, /dev/random usa le convenzionali funzioni di hash, quindi è probabile che avrebbe comunque delle debolezze se attaccato con potenza infinita (nulla di cui preoccuparsi per gli attaccanti terrestri , però).

• /dev/urandom non bloccherà, mentre /dev/random potrebbe farlo. /dev/random mantiene un contatore di "quanto entropia ha ancora" supponendo che ogni bit che ha prodotto sia un bit di entropia perso. Il blocco induce problemi molto reali, ad es. un server che non riesce ad avviarsi dopo un'installazione automatica perché si sta bloccando sulla sua creazione della chiave del server SSH (sì, l'ho visto). /dev/urandom usa un generatore di numeri pseudo-casuali crittograficamente strong, quindi non bloccherà mai.

Quindi vuoi usare /dev/urandom e fermati a preoccuparti di questa attività di entropia.

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

Il sistema operativo stesso, e più precisamente il kernel, è nel posto giusto per raccogliere entropia dall'evento hardware, poiché gestisce l'hardware. Quindi c'è relativamente poco che puoi usare per 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 lotti di dati, è un buon raccoglitore di entropia. Quindi, prendi alcuni fotogrammi dalla webcam, inseriscili con una funzione hash sicura (SHA-256) e scrivili in /dev/urandom . Questo è ancora un grande overkill.

Conosco demone di entropia audio e havege utilizzato dal demone haveged , provalo.

Il miglior valore che ho visto in un dispositivo di casualità HW è la chiave di entropia simtec
Ha una serie di salvaguardie integrate per la protezione da guasti e attacchi. Ad esempio, esegue i test di casualità FIPS 140-2 su ciascun batch di 20 KB, spegnendosi se un numero statisticamente significativo di test fallisce. Ne ho preso uno quando stavo facendo un sacco di generazione di chiavi per la ricerca DNSSEC, e ha accelerato notevolmente il mio lavoro. Supera tutti i test del dieharder. (nota, verifica sempre periodicamente i tuoi stream di casualità, indipendentemente da ciò che ti dice il venditore; -)

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: blocca, impoverisce il pool di entropia in un modo che potrebbe causare il blocco di altri utenti di / dev / random. / dev / urandom è la migliore interfaccia general-purpose.)

3) Ecco un semplice script che uso per generare una password casuale. Sei libero di usarlo.

#!/bin/sh
# Make a 48-bit password (8 characters, 6 bits per char)
dd if=/dev/urandom count=1 2>/dev/null | base64 | head -1 | cut -c4-11 

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

Su un server Web è possibile combinare i dati del server (HW, SW, prestazioni), i dati client (user-agent, tempo di richiesta, cookie, variabili URL, qualunque cosa sia possibile raccogliere), alcuni dati esterni (come casuali. org), mescola tutto con let sha1 (mixed_data + time + some_secret_key) e ottieni bit di dati casuali abbastanza imprevedibili.

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

Le password, se sono brevi, sono sempre decifrabili dalla forza bruta se la velocità o il numero di tentativi non è limitato. Se, d'altra parte, i tentativi sono limitati (ad esempio login interattivo), anche una piccola quantità di entropia è praticamente noncrissibile - la quantità di tentativi richiesti diventa proibitiva molto presto.

Quindi, non ci dovrebbero essere casi in cui ottenere entropia veramente buona per le password sarebbe importante.

Quindi basta usare / dev / urandom, è più che buono.

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

GUChaos.c recupera numeri casuali da a caso. org e li cambia al volo attraverso una cifratura sostitutiva prima di nutrire /dev/random .

È strano vedere una serie di consigli per usare / dev / urandom invece di usare / dev / random causa quando / dev / random depletes quindi / dev / urandom usa l'ultima entropia ripetutamente ciò che è strongmente non sicuro per il critico a lungo termine i parametri.