Perché my / dev / random è così lento quando si usa dd?

Sto cercando di cancellare in modo semi-sicuro un mucchio di dischi rigidi. Di seguito funziona a 20-50 Mb / s

dd if=/dev/zero of=/dev/sda

Ma

dd if=/dev/random of=/dev/sda 

sembra non funzionare. Anche quando scrivo

dd if=/dev/random of=stdout

Mi dà solo pochi byte, indipendentemente da cosa lo passo per bs = e count =

Sto usando / dev / random sbagliato? Quali altre informazioni dovrei cercare per portare avanti questa risoluzione dei problemi? C'è un altro modo per farlo con una sceneggiatura o qualcosa del genere

makeMyLifeEasy | dd if=stdin of=/dev/sda

O qualcosa di simile...

Entrambi /dev/randome /dev/urandomusano un "pool di entropia". Quando il pool si esaurisce, /dev/randomattende che si riempia, il che richiede il monitoraggio del comportamento del sistema (input da tastiera, spostamento del mouse, ecc.), Mentre /dev/urandomcontinuerà a fornire dati pseudo-casuali. /dev/randomè teoricamente di qualità superiore, ma /dev/urandomè quasi certamente abbastanza buono per i tuoi scopi. (Ma /dev/urandomè probabile che sia anche più lento di altri metodi. Un generatore più veloce, ma di qualità inferiore è probabilmente abbastanza buono per cancellare i dischi rigidi. Non è chiaro che un attaccante trarrebbe vantaggio dalla conoscenza della sequenza che verrà generata, o che i numeri casuali sono migliori a questo scopo di una sequenza come 0, 1, 2, 3, 4, ....)

Citando la random(4)pagina man:

Se non si è sicuri dell'opportunità di utilizzare /dev/randomo /dev/urandom, probabilmente si desidera utilizzare quest'ultimo. Come regola generale, /dev/urandomdovrebbe essere usato per tutto tranne chiavi GPG / SSL / SSH di lunga durata.

AGGIORNAMENTO : La pagina man `random (4) è stata aggiornata da quando l'ho scritta. Ora dice:

L' /dev/randominterfaccia è considerata un'interfaccia legacy ed /dev/urandomè preferita e sufficiente in tutti i casi d'uso, ad eccezione delle applicazioni che richiedono casualità durante l'avvio iniziale; per queste applicazioni, è getrandom(2)necessario utilizzare invece, poiché si bloccherà fino all'inizializzazione del pool di entropia.

Vedi anche " Miti su / dev / urandom " di Thomas Hühn.

Ma /dev/urandom, anche se non si bloccherà, è probabile che sia troppo lento se si desidera generare enormi quantità di dati. Prendi alcune misure sul tuo sistema prima di provarlo.

EDIT: Di seguito è riportata una digressione su numeri casuali "veri" vs. numeri pseudo-casuali. Se tutto ciò che ti interessa è una risposta pratica alla domanda, puoi smettere di leggere ora.

Mi sembra di affermare (anche in altre risposte qui) che /dev/randomimplementa un generatore di numeri casuali "vero", al contrario di un generatore di numeri pseudo-casuali (PRNG). Ad esempio, l' articolo di Wikipedia afferma tale affermazione. Non credo sia corretto. C'è qualche discussione qui che si riferisce ai generatori di numeri casuali di hardware, ma non vedo alcuna prova che in /dev/randomgenere utilizza un tale dispositivo o che i computer tipici abbiano persino un tale dispositivo. Differiscono dai PRNG come la rand()funzione C in quanto non sono deterministici, poiché raccolgono entropia da fonti praticamente imprevedibili.

Direi che ci sono tre classi di generatori di numeri "casuali":

1. PRNG deterministici, come la rand()funzione di C , che usano un algoritmo per generare sequenze ripetibili che hanno (più o meno) le proprietà statistiche di una sequenza veramente casuale. Questi possono essere abbastanza buoni per i giochi (dato un buon modo di seminarli) e sono necessari per applicazioni che richiedono ripetibilità, ma non sono adatti per la crittografia.

2. Ai generatori piace /dev/randome /dev/urandomche raccolgono entropia da una fonte praticamente imprevedibile come l'attività di I / O (questo è il motivo per cui martellare la tastiera o muovere il mouse può causare la /dev/randomproduzione di più dati). Non è chiaro (per me) se questi soddisfano la definizione di un PRNG (ho visto definizioni che dicono che un PRNG è deterministico), ma nemmeno i veri generatori di numeri casuali.

3. Generatori di numeri casuali hardware che sono fisicamente imprevedibili anche con una conoscenza completa del loro stato iniziale e che utilizzano inoltre tecniche matematiche per garantire le giuste proprietà statistiche.

/dev/randomè una fonte di vera entropia, byte veramente casuali. Come tale, ha bisogno di una fonte di casualità. Puoi "esaurire" la casualità leggendola. Ti darà tutta la casualità che ha, quindi bloccherà fino a quando non ne otterrà di più. Probabilmente stai solo seduto lì ad aspettare, e la macchina ottiene pochissima nuova casualità, e aspetta solo.

/dev/randomper crittografia veramente casuale, casualità di alta qualità. Come tale, è un overkill per la sovrascrittura di un'unità disco. Scrivere da /dev/zeropoche volte va bene. Oppure puoi scrivere da /dev/urandom, che non bloccherà e darà numeri pseudo-casuali quando si esaurisce la casualità vera.

In Linux / dev / random è un file speciale che serve numeri pseudo casuali di alta qualità. Questa implementazione raccoglie entropia da eventi originati da interruzioni di tastiera, mouse, disco e sistema. (fare riferimento a questo documento) Quindi quando non ci sono tali eventi, il pool di entropia è vuoto, le letture da / dev / random si bloccano fino a quando non viene raccolto ulteriore rumore ambientale. Questo spiega il tuo problema. Per riempire il pool di entropia è possibile premere i tasti sulla tastiera.

D'altra parte, un generatore di numeri casuali utilizza un generatore di numeri casuali hardware che genera numeri casuali da processi fisici, tra cui fenomeni microscopici che generano un segnale di "rumore" statisticamente casuale di basso livello, come il rumore termico o l'effetto fotoelettrico o altri fenomeni fisici. Questi processi sono, in teoria, completamente imprevedibili e le asserzioni di imprevedibilità della teoria sono soggette a test sperimentali.

Un generatore di numeri casuali hardware in genere è costituito da un trasduttore per convertire alcuni aspetti dei fenomeni fisici in un segnale elettrico, un amplificatore e altri circuiti elettronici per aumentare l'ampiezza delle fluttuazioni casuali a un livello macroscopico e un qualche tipo di convertitore da analogico a digitale per convertire l'output in un numero digitale, spesso una semplice cifra binaria 0 o 1. Campionando ripetutamente il segnale che varia casualmente, si ottiene una serie di numeri casuali.

Il generatore di numeri casuali hardware raccoglie il rumore ambientale proveniente dai driver di dispositivo e da altre fonti in un pool di entropia. Da questo pool di entropia vengono creati numeri casuali. Quando viene letto, il dispositivo / dev / random restituirà solo byte casuali entro il numero stimato di bit di rumore nel pool di entropia. Questo spiega il tuo problema.

Alcune implementazioni di Hardware RNG sono spiegate nel documento del kernel e nelle informazioni su un dispositivo .

Una controparte di / dev / random è / dev / urandom (sorgente casuale "sbloccata" / non bloccante) che riutilizza il pool interno per produrre più bit pseudo-casuali. Ciò significa che la chiamata non si bloccherà, ma l'output potrebbe contenere meno entropia della lettura corrispondente da / dev / random.

Quindi se il tuo intento non è generare CSPRNG (generatore di numeri pseudocasuali crittograficamente sicuro), dovresti usare / dev / urandom.

Senza rispondere alla tua domanda - ci sono già risposte complete qui - puoi anche dare un'occhiata a Darik's Boot e Nuke aka DBAN che è un tergicristallo per unità CD live.

Basta usare il shredcomando fornito con coreutils. Utilizza i dati casuali in modo efficiente. dd è uno strumento di basso livello e probabilmente è un livello un po 'troppo basso per questo compito. shredsalterà in modo efficiente parti non scrivibili del dispositivo, ad esempio.