Esiste un'alternativa a / dev / urandom?

C'è un modo più veloce di / dev / [u] random? A volte, devo fare cose del genere

cat / dev / urandom> / dev / sdb

I dispositivi casuali sono "troppo" sicuri e sfortunatamente troppo lenti per quello. So che ci sono wipee strumenti simili per la cancellazione sicura, ma suppongo che ci siano anche dei mezzi integrati a quello in Linux.

Se stai cercando di fare una cancellazione "sicura" di un disco rigido (o file), dovresti guardare l'utilità shred.

Come sottolineato dai precedenti poster, i dispositivi casuali / dev / * sono pensati per essere utilizzati come fonte di piccoli blocchi di dati casuali.

Sfortunatamente Linux ha una cattiva implementazione di urandom. È possibile utilizzare aes256-ctr con una chiave casuale e ottenere diverse centinaia di megabyte di pseudo-casualità al secondo, se la CPU supporta AES-NI (accelerazione hardware). Non vedo l'ora di passare anche ad un approccio moderno.

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

Questo cucciolo fa 1,0 GB / s sulla mia scatola (rispetto ai 14 MB / s di / dev / urandom). Usa solo urandom per creare una password casuale e quindi esegue una crittografia molto veloce di / dev / zero usando quella chiave. Questo dovrebbe essere un PRNG crittograficamente sicuro ma non farò garanzie.

In un rapido test sotto Ubuntu 8.04 su un Thinkpad T60p con CPU T2500, 1 GB di dati casuali da openssl randera 3-4 volte più veloce di /dev/urandom. Questo è,

time cat /dev/urandom | head -c 1000000000 > /dev/null

... erano circa 4 minuti mentre ...

time openssl rand 1000000000 | head -c 1000000000 > /dev/null

... era poco più di 1 minuto.

Non sono sicuro che ci sia una differenza nella qualità casuale, ma probabilmente entrambi vanno bene per la pulizia HD.

Vedo molte risposte che dicono che l'uso di dati casuali non è importante. È praticamente vero se tutto ciò che stai cercando di fare è pulire l'unità, ma non tanto se lo stai cancellando in preparazione per la crittografia del disco.

Se si riempie un dispositivo con dati non casuali, si inserisce una partizione crittografata su di esso, si potrebbe verificare un problema. La parte dell'unità che memorizza i dati crittografati si distinguerà dal resto dell'unità, poiché i dati crittografati appariranno casuali e il resto no. Questo può essere usato per determinare informazioni sul disco crittografico che potrebbero essere utilizzate per craccarlo. Il link seguente spiega la teoria alla base di come funzionano alcuni degli attacchi più comuni e come difendersi da loro (su Linux, comunque).

Impostazioni di crittografia del disco rigido Linux

Se hai bisogno di cancellare in sicurezza un disco rigido, esiste uno strumento molto potente: DBAN

Se vuoi cancellare un enorme dispositivo a blocchi, allora l'ho trovato più robusto da usare dde il mappatore del dispositivo invece del reindirizzamento dell'output di dati casuali. Di seguito vi mappa /dev/sdbper /dev/mapper/deviceToBeEraseden- e decrittografare transparantly in mezzo. Per riempire il dispositivo sull'estremità crittografata, gli zeri vengono copiati sul lato del testo normale del mapper ( /dev/mapper/deviceToBeErased).

cryptsetup --cipher aes-xts-plain64 --key-file /dev/random --keyfile-size 32 create deviceToBeErased /dev/sdb
dd if=/dev/zero of=/dev/mapper/deviceToBeErased bs=1M

I dati crittografati su /dev/sdbsono garantiti indistinguibili da dati casuali se non vi è una grave debolezza in AES. La chiave utilizzata viene catturata da /dev/random(non preoccuparti: utilizza solo 32 byte).

controllare casualmente

http://billauer.co.il/frandom.html

secondo il mio test è più veloce

Più veloce è il tuo strumento, meno sicuro sarà il risultato. Generare una buona casualità richiede tempo.

Ad ogni modo, potresti usare qualcosa come dd if = / dev / zero di = / dev / sdb , ma ovviamente non sarà casuale, ma cancellerà molto più velocemente.

Un'altra opzione potrebbe essere quella di usare questo metodo / sbin / badblocks -c 10240 -s -w -t random -v / dev / sdb è più veloce di urandom, ma i badblock PRNG sono meno casuali.

/dev/random utilizza molta entropia di sistema e quindi produce solo un flusso di dati lento.

/dev/urandom è meno sicuro e più veloce, ma è ancora orientato verso blocchi di dati più piccoli - non è pensato per fornire un flusso continuo di numeri casuali ad alta velocità.

Dovresti creare un PRNG secondo il tuo disegno e seminarlo con qualcosa da /dev/randomo /dev/urandom. Se ne hai bisogno un po 'più casuale, semina periodicamente - ogni pochi MB (o qualunque sia la lunghezza del tuo prng). Ottenere 4 byte (valore a 32 bit) da casuale o casuale è abbastanza veloce che puoi farlo ogni 1k di dati (ridimensionato il tuo prng ogni 1k) e ottenere risultati molto casuali, andando molto, molto, rapidamente.

-Adamo

Se si desidera cancellare rapidamente un disco rigido, scrivere dati non casuali su di esso. Questo non è meno sicuro dell'uso di dati casuali. In ogni caso, quando collegato a un computer non è possibile leggere i dati originali. Sovrascrivere i dati del disco rigido: la grande controversia sulla pulizia mostra che neanche i dati originali possono essere letti al microscopio.

Formatta con LUKS e dd sul volume crittografato. Quindi usa / dev / urandom per cancellare l'intestazione LUKS.

Se si dispone del supporto hardware AES, questa è una soluzione molto veloce.

Brevemente:

cryptsetup luksFormat /dev/sdX
cryptsetup luksOpen /dev/sdX cryptodev
dd if=/dev/zero bs=1M of=/dev/mapper/cryptodev
cryptsetup luksClose cryptodev
# wipe the luks header.  Yes, it uses /dev/urandom but only for 2MB of data:
dd if=/dev/urandom bs=1M count=2 of=/dev/sdX

fatto!

Vedi il mio blog: riempire rapidamente un disco con bit casuali (senza / dev / urandom)

Se si desidera cancellare un disco rigido, dd non elimina il contenuto dei settori riallocati ed è molto lento se il disco rigido sta morendo. Invece è possibile utilizzare la funzione di cancellazione build delle unità, che è stata standardizzata da molto tempo.

In questo esempio, sto cancellando un hard disk meccanico da 500 GB in soli 102 minuti. Anche quando è pieno di settori riallocati:

root@ubuntu:~# hdparm --security-set-pass Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
root@ubuntu:~# time hdparm --security-erase-enhanced Eins /dev/sdaj
security_password="Eins"

/dev/sdaj:
 Issuing SECURITY_ERASE command, password="Eins", user=user

real    102m22.395s
user    0m0.001s
sys     0m0.010s

root@ubuntu:~# smartctl --all /dev/sdaj | grep Reallocated
  5 Reallocated_Sector_Ct   0x0033   036   036   036    Pre-fail Always   FAILING_NOW 1327 

Puoi vedere maggiori dettagli su ata.wiki.kernel.org , tuttavia il loro esempio non usa --security-erase-Enhanced, che è necessario per eliminare i settori riallocati prima menzionati.

In pratica, probabilmente non è necessario eseguire il seeding dell'intero disco da un flusso continuamente casuale.

È possibile creare una porzione di dati casuali di dimensioni modeste, quindi ripeterla ripetutamente sul disco.

Assicurati solo che quel blocco di dati non sia un multiplo della normale dimensione del blocco del disco, per assicurarti di non finire per sovrascrivere blocchi di dati correlati con lo stesso bit casuale di dati. Una dimensione di blocco che è un numero primo nell'intervallo ~ 1 MB dovrebbe fare bene.

Per ulteriore sicurezza, basta farlo un paio di volte di più, usando ogni volta una dimensione del pezzo diversa.

L'utilità 'shred' è semplice e veloce. Se gli attributi SMART dell'unità indicano zero settori riassegnati, è probabile che "shred" sia sufficientemente sicuro.

Tuttavia, se l'unità ha riassegnato settori, i dati sui settori danneggiati non verranno sovrascritti. Se le posizioni danneggiate contenevano dati sensibili prima che fossero riassegnati, 'shred' potrebbe non essere abbastanza buono. I settori "danneggiati" possono essere letti ripristinando la mappa di allocazione dell'unità e (ripetutamente) leggendoli.

La possibilità di ripristinare la mappa di allocazione del settore errata varia in base al produttore e al modello di unità.

Se tutto ciò che vuoi fare è sovrascrivere il disco, allora non importa cosa usi perché qualsiasi cosa batterà qualsiasi cosa al di fuori di un laboratorio forense e non mi fiderei di nulla a parte trascinare l'unità per fermare quel livello di risorse .

Usa solo una fonte non casuale come tutti gli zeri o quelli o uno schema ripetuto come (penso che funzionerà)

(head -c 4096 /dev/urandom; cat /dev/sdb/) > /dev/sdb