Perché GNU viene distrutto più velocemente di dd quando si riempie un'unità con dati casuali?

Durante la cancellazione sicura di un disco rigido prima della disattivazione, ho notato che ciò dd if=/dev/urandom of=/dev/sdarichiede quasi un'intera giornata, mentre shred -vf -n 1 /dev/sdarichiede solo un paio d'ore con lo stesso computer e lo stesso disco rigido.

Com'è possibile? Immagino che il collo di bottiglia sia l'output limitato di /dev/urandom. Shred utilizza un generatore di pseudo casualità che è meno casuale e sufficiente solo per il suo scopo (cioè più efficiente) di urandom?

Shred utilizza un generatore pseudocasuale interno

Per impostazione predefinita, questi comandi utilizzano un generatore pseudocasuale interno inizializzato da una piccola quantità di entropia, ma possono essere indirizzati a utilizzare una fonte esterna con l'opzione --random-source = file. Viene segnalato un errore se il file non contiene abbastanza byte.

Ad esempio, il file del dispositivo / dev / urandom potrebbe essere utilizzato come fonte di dati casuali. In genere, questo dispositivo raccoglie il rumore ambientale dai driver di dispositivo e altre fonti in un pool di entropia e utilizza il pool per generare bit casuali. Se il pool è a corto di dati, il dispositivo riutilizza il pool interno per produrre più bit, utilizzando un generatore di numeri pseudocasuali crittograficamente sicuro. Tuttavia, tenere presente che questo dispositivo non è progettato per la generazione di dati casuali in blocco ed è relativamente lento .

Non sono convinto che i dati casuali siano più efficaci di un singolo passaggio di zero (o di qualsiasi altro valore di byte) per oscurare i contenuti precedenti.

Per smantellare in modo sicuro un'unità, utilizzo un grosso magnete e un grosso martello.

Immagino che sarebbe causato piuttosto dddall'uso di blocchi più piccoli per scrivere i dati. Prova dd if=... of=... bs=(1<<20)a vedere se funziona meglio.