Modo rapido per randomizzare l'HD?

Ho letto su come rendere sicuri i dischi rigidi per la crittografia e uno dei passaggi è scrivere bit casuali sull'unità, al fine di rendere i dati crittografati indistinguibili dal resto dei dati sul disco rigido.

Tuttavia, quando ho provato a utilizzare dd if=/dev/urandom of=/dev/sdain passato, l'ETA stava cercando di essere all'ordine dei giorni. Ho visto qualcosa sull'uso badblocksal posto di urandom, ma questo non sembrava aiutare molto. Vorrei solo sapere se ci sono modi che potrebbero aiutarmi ad accelerare questo, come opzioni per ddo qualcos'altro che potrei mancare, o se la velocità è solo una limitazione dell'HD.

dd if=/dev/urandom of=/dev/sdao, semplicemente cat /dev/urandom >/dev/sda , non è il modo più veloce per riempire un disco con dati casuali. Linux /dev/urandomnon è l'RNG crittografico più veloce in circolazione. Esiste un'alternativa a / dev / urandom? ha alcuni suggerimenti. In particolare, OpenSSL contiene un PRNG crittografico più veloce:

openssl rand $(</proc/partitions awk '$4=="sda" {print $3*1024}') >/dev/sda

Si noti che alla fine, se c'è un miglioramento o meno dipende da quale parte è il collo di bottiglia: la CPU o il disco.

La buona notizia è che riempire il disco con dati casuali è per lo più inutile. In primo luogo, per dissipare un mito comune, pulire con zero è altrettanto buono sull'hardware di oggi . Con la tecnologia del disco rigido degli anni '80, la sovrascrittura di un disco rigido con zero lasciava una piccola carica residua che poteva essere recuperata con hardware piuttosto costoso; sono stati necessari più passaggi di sovrascrittura con dati casuali (il "Gutmann wipe"). Oggi anche un singolo passaggio di sovrascrittura con zero lascia dati che non possono realisticamente essere recuperati anche in condizioni di laboratorio.

Quando si crittografa una partizione, non è necessario riempire il disco con dati casuali per la riservatezza dei dati crittografati. È utile solo se è necessario rendere lo spazio utilizzato dai dati crittografati indistinguibile dallo spazio inutilizzato. La creazione di un volume crittografato sopra un contenitore non randomizzato rivela quali blocchi del disco sono mai stati utilizzati dal volume crittografato. Questo dà un buon suggerimento per quanto riguarda la dimensione massima del filesystem (anche se col passare del tempo diventerà un'approssimazione sempre peggiore) e poco altro.

L'apssl non sembra funzionare per me. Ho ottenuto "opzioni sconosciute" e altri problemi con le soluzioni fornite. Così ho finito con il programma fio.

fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0

Il che sembra richiedere 3 ore per eseguire 19 TB su 24 HDD. Quindi circa 1.800 MB / s

smp-016:~ # fdisk -l /dev/md0
Disk /dev/md0: 18890.1 GB, 18890060464128 bytes

smp-016:~ # fio -name="fill" -ioengine=libaio -direct=1 -bs=512m -rw=write -iodepth=4 -size=100% -filename=/dev/md0
fill: (g=0): rw=write, bs=512M-512M/512M-512M/512M-512M, ioengine=libaio, iodepth=4
fio-2.2.10
Starting 1 process
Jobs: 1 (f=1): [W(1)] [2.7% done] [0KB/1536MB/0KB /s] [0/3/0 iops] [eta 03h:01m:11s]

Spero che si tratti effettivamente di dati casuali. La pagina man dice fio "Default: riempie i buffer con dati casuali."http://linux.die.net/man/1/fio

Non lo sto facendo per scopi di sicurezza / crittografia, sto solo cercando di essere sicuro che i miei test di lettura successivi siano dati effettivi e non solo 0. Lo stesso comando fio potrebbe essere utilizzato per il precondizionamento SSD / NVMe. Siccome il solo utilizzo di / dev / zero può portare alla compressione a livello di disco "barare" la quantità effettivamente scritta. Anche se aggiungerei a-loops=2 flag, se si tratta di un nuovo SSD per il benchmarking.

Se si desidera che sia sicuro, è possibile utilizzare il -randrepeat=bool opzione, in quanto ciò commuterà "Semina il generatore di numeri casuali in modo prevedibile in modo che i risultati siano ripetibili su tutte le esecuzioni. Predefinito: vero.", Ma non lo sono ancora certo quanto sarebbe sicuro.

Inoltre, alcuni HDD di classe enterprise sono SED (Self Encrypting Drives) e ti permetteranno di girare la chiave di crittografia per cancellare istantaneamente e in modo sicuro tutti i dati scritti.

Infine, in passato ho usato DBAN (aka Darik's Boot e Nuke), che ha opzioni di avvio per CD e USB e "è un progetto open source ospitato su SourceForge. Il programma è progettato per cancellare in modo sicuro un disco rigido fino a quando i suoi dati non sono permanentemente rimosso e non più recuperabile "

Puoi far crittografare OpenSSL /dev/zerocon una password casuale, fornendo dati pseudocasuali decenti molto velocemente (se la tua CPU supporta l'accelerazione).

openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | dd of=/dev/sda

È possibile reprimerlo pvper ottenere progressi / ETA. I comandi che sto eseguendo in questo momento (in una shell di root) sono:

DISK="sda"
DISKSIZE=$(</proc/partitions awk '$4=="'"$DISK"'" {print sprintf("%.0f",$3*1024)}')
apt-get install pv
openssl enc -aes-256-ctr -nosalt \
  -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" \
  < /dev/zero |
  pv --progress --eta --rate --bytes --size "$DISKSIZE" |
  dd of=/dev/"$DISK" bs=2M

Ho avuto questa idea da questa risposta , dopo aver avuto lo stesso problema dell'irrazionale John , che ha commentato la risposta di Gilles sopra. Ciò ha aumentato la mia velocità di cancellazione sul mio nuovo array RAID da 11 MB / sa circa 300 MB / s, portando ciò che avrebbe richiesto una settimana a 10 ore.

Aggiungerò che dovresti essere in grado di usare piuttosto che la dichiarazione più complicata sopra, ma c'è un bug che ti permetterà di produrre solo 16 MB di output. (Questo errore è stato archiviato, gennaio 2016.)openssl rand #of_bytesopenssl enc ...ssl

E, secondo la risposta a questa domanda , e continuando a supporre che la CPU sia il collo di bottiglia, potrebbe essere possibile aumentare ulteriormente la velocità eseguendo più opensslprocessi paralleli su core separati, combinandoli utilizzando un FIFO.

Completando la risposta di Marco, ciò di cui hai bisogno è un generatore di numeri casuali più veloce.

Usi un semplice programma che riecheggia numeri casuali da una buona libreria come boost::randome usi quello in dd.

Se si sceglie boost, è possibile utilizzare questo esempio, modificando la experimentfunzione in base alle proprie esigenze.

Il collo di bottiglia non è né la dimensione del blocco né il disco rigido, ma la generazione lenta di numeri pseudo-casuali. /dev/urandomè di gran lunga più veloce rispetto a /dev/randompoiché non si blocca su un pool a bassa entropia.

Puoi confermarlo misurando l'output grezzo dei tuoi numeri pseudo-casuali:

pv /dev/urandom >/dev/null

Questa velocità sarà molto più lenta della velocità di scrittura del tuo disco rigido. Una soluzione corretta dipende totalmente dal livello di sicurezza richiesto. Se hai bisogno di alta sicurezza, usa un generatore casuale hardware veloce o accetta la bassa velocità. Se le tue esigenze di sicurezza non sono così elevate, puoi acquisire alcune decine di MiB di dati e scrivere quella stringa ripetutamente sull'unità. O forse anche scrivere zeri da/dev/zero è un'opzione.

Sommario

/dev/random - sicuro, molto lento
/dev/urandom- meno sicuro¹,
hardware lento RNG - sicuro, veloce, molto costoso
(/dev/zero - per nulla casuale, molto veloce)

¹ _{Secondo Un rand di / dev / urandom è sicuro per una chiave di accesso? /dev/urandomè sicuro come /dev/random. Grazie a Gilles per averlo segnalato.}

Stavo cercando di riempire un HDD USB esterno da 4 TB dd if=/dev/urandom of=/dev/sdX status=progressche era troppo lento (indipendentemente dalle bs=impostazioni), e sembra che opensslabbia un limite a quanti dati casuali produrrà (almeno per la versione 1.0.2p). L'opzione migliore che ho trovato è stata il commento di frostschutz da usare shred, come in:

shred -v -n 1 /dev/sdX

Assicurati di usare -n 1altrimenti, per impostazione predefinita scriverà il dispositivo 3 volte (oltre a quello -vche mostra i progressi). Non credo che la qualità dei numeri pseudo casuali sia così alta, ma mi basta preparare un HDD portatile di grande capacità per la crittografia.