Esiste un'alternativa a / dev / urandom?


21

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.


Equivalente su StackOverflow: stackoverflow.com/questions/841356/…
David Z


1
Non è forse un modo migliore per farlo ... Forse un concorrente per il premio UUoC?
Tom O'Connor,

Risposte:


12

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.


1
Secondo la pagina man, 'shred' usa / dev / urandom. Quindi, sebbene sia una buona risposta per cancellare il disco, non offrirà una velocità rispetto a qualsiasi altra tecnica di lettura da / dev / urandom. (Un altro suggerimento se si utilizza 'shred': la maggior parte delle persone probabilmente sarà più felice con 1-2 passaggi, piuttosto che il conteggio predefinito predefinito, in modo che una cancellazione non richieda giorni.)
gojomo

4
In realtà lo shred è molto più veloce di / dev / urandom. La mia ipotesi è che fornisca i propri dati pseudocasuali usando / dev / urandom o / dev / random come seme.
thomasrutter,

24

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.


Grazie per questa fantastica risposta, sono stato in grado di passare da 9,5 MB / s con / dev / urandom a oltre 120 MB / s con openssl.
RDT

Ad eccezione della prima affermazione che Linux ha una cattiva implementazione di urandom , approvo questa risposta. Abbastanza buono per cancellare (o riempire?) Un disco rigido prima della crittografia.
Vikrant Chaudhary,

5
Passa attraverso pvper un bel indicatore di progresso. openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero | pv -pterb > /dev/sdb.
Vikrant Chaudhary,

@VikrantChaudhary urandom produce numeri pseudo casuali di alta qualità, certo, ma non è una scusa per essere lenti. La modalità contatore AES è molto più veloce ed è difficile discutere su come sarebbe meno sicuro di / dev / urandom.
Perseidi,

1
Giusto per aggiungere alla pvraccomandazione, è possibile tubo per pv -pterb -s $(blockdev --getsize64 /dev/sdb) >/sdbavere pvvoi mostrare i progressi verso finendo la scrittura.
asciiphil,

7

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.


5

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


1
Veramente giusto. Con dischi relativamente moderni (> 20 GB) qualsiasi sovrascrittura a singolo passaggio è abbastanza pulita. Anche l'NSA e simili sarebbero difficili da ottenere per ottenere una quantità significativa di dati dall'unità. Ed è molto costoso. Pensa a $ 100.000 per megabyte. L'osservazione sulla crittografia è molto vera. Le parti inutilizzate del disco sembrano "casuali" come quelle utilizzate.
Tonny,

Il software di crittografia del tuo dispositivo non randomizza l'intero disco?
Nathan Garabedian,

5

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


5

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).



2

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.


1
e onestamente - questo è MOLTO di sicurezza per l'unità
warren

Sovrascritture multiple, come fa shred, richiede tempo e offre una sicurezza migliore rispetto a una sovrascrittura di dati casuali "perfettamente".
In pausa fino a nuovo avviso.

"Più veloce è il tuo strumento, meno sicuro sarà il risultato. Generare una buona casualità richiede tempo." - Non è vero. Un generatore di numeri casuali (pseudo) in modalità contatore AES è molto meglio analizzato e gli ordini di grandezza sono più veloci di / dev / urandom. (Vedi la risposta di Tronic.)
Perseidi,

2

/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


7
È molto raro che qualcuno possa scrivere il proprio generatore di numeri casuali che è migliore di quelli che sono già prontamente disponibili. Più spesso, il risultato è un modello prevedibile e un falso senso di sicurezza. Consiglierei di utilizzare lo shred su un disco tramite la sua voce / dev o una distruzione fisica molto accurata.
In pausa fino a nuovo avviso.

Sono d'accordo. Userei shred, che di default usa urandom (che sinceramente non trovo lento). Come nota, è possibile usare / dev / random con shred (specificando --random-source = / dev / random) se si è molto pazienti.
Matthew Flaschen,


2

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)


Perché ti preoccupi di LUKS se tutto ciò che vuoi fare è sovrascrivere il dispositivo? Il semplice dm-crypt ("modalità semplice" di cryptsetup) è molto più facile da usare per questo.
Perseidi,

2

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.


1

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.


1

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à.


0

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

Questo può essere il caso, ma a volte non è possibile convincere il management che la sicurezza impartita da una scrittura casuale non è in realtà maggiore rispetto all'utilizzo di tutti gli zeri dato che il livello di tecnologia richiesto per recuperare i dati è lo stesso per entrambi gli scenari. In questo caso è spesso meglio soddisfare i requisiti creando il tuo generatore di numeri casuali veloce.
Adam Davis,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.