Non ha senso fare più passaggi. Una volta è abbastanza.
Riempire un'unità da crittografare con dati casuali ha principalmente due usi:
- sbarazzarsi di dati vecchi e non crittografati
- rendere lo spazio libero indistinguibile dai dati crittografati
Di solito se crittografate non volete che nessuno veda i vostri dati. Quindi è probabile che, se avessi dati vecchi e non crittografati su questa unità, anche tu vuoi sbarazzartene. Un SSD potrebbe occuparsene più facilmente e più velocemente blkdiscard
. In effetti, Linux mkfs
TRIMs tutti i dati senza nemmeno chiederti conferma, il che rende impossibile qualsiasi tipo di recupero dei dati. C'è troppo TRIM in Linux.
Lo spazio libero è un po 'di un'area grigia. Se non si effettua il pre-riempimento con dati casuali, su un nuovissimo HDD, i settori in cui non è mai stato scritto saranno zero. Su un SSD, se si consente di eliminare / TRIM, anche lo spazio libero sarà zero.
Sebbene ciò non influisca in alcun modo sui tuoi dati (è ancora crittografato), rivela la quantità di spazio libero / dati effettivi che hai e dove si trova questo spazio libero / dati. Ad esempio, un hexdump -C
SSD crittografato e tagliato apparirà in qualche modo simile a questo:
# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0 dc c9 c7 89 16 ca d3 4f a3 27 d6 df a0 10 c3 4f |.......O.'.....O|
b3eac000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
b3f70000 5a 99 44 b5 9c 6b 1e 9c 81 cf 9a 43 b6 23 e9 0f |Z.D..k.....C.#..|
b3f70010 2c e6 9a 5d 59 9b 46 5f 21 3f 4d 5f 44 5b 0a 6b |,..]Y.F_!?M_D[.k|
--
b3f70ff0 5f 63 8d e8 c4 10 fd b1 a6 17 b5 7d 4a 57 09 68 |_c.........}JW.h|
b3f71000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
b3f72000 5d 1c 09 dd c9 6b 57 18 db 67 e1 35 81 57 45 8e |]....kW..g.5.WE.|
b3f72010 0f a8 be 39 ae e5 5f cf cf e3 8b a7 c1 25 1a a3 |...9.._......%..|
--
...
Da questo si può dire che ho segmenti di spazio libero all'indirizzo 0xb3eac000 .. 0xb3f70000
, b3f71000 .. b3f72000
, ... e l'inverso di ciò è di segmenti di dati ovviamente come 0xb3f70000 .. b3f71000
.
Cosa puoi farci? Bene, niente (*).
(*) è quello che vorrei dire. Ma le persone diventano creative . I modelli di spazio libero possono essere usati per derivare il tipo di filesystem che usi (a causa di come / dove archiviano i metadati - se c'è spazio libero in cui ext4
archiviare uno dei suoi backup di metadati, molto probabilmente no ext4
, ecc.). A volte rivela persino quale distribuzione usi (se il tuo installer Linux riempie il file system in modo deterministico, i file potrebbero sempre finire con gli stessi indirizzi fisici). A quel punto qualcuno potrebbe sapere dove si trova un file di sistema specifico e potrebbe modificarlo / danneggiarlo in qualche modo. (Gli installatori dovrebbero randomizzare il modo in cui popolano i filesystem per impedirlo.)
Tuttavia, tali considerazioni sono molto teoriche e presentano un rischio molto basso rispetto alla vulnerabilità della maggior parte delle installazioni crittografate dovuta ad altri motivi. Nella maggior parte delle installazioni out-of-the-box, è più probabile / semplice manomettere gli initramfs, installare un keylogger o sfruttare il sistema in esecuzione, che in qualche modo ottenere un accesso non elaborato e analizzare i dati crittografati e sperare di ottenere qualcosa in questo modo.
Dovresti preoccuparti di questi prima di preoccuparti di rivelare lo spazio libero.
Con SSD, è del tutto normale abilitare TRIM e quindi avere spazio libero rivelato in ogni momento. Questo vale anche per le soluzioni di crittografia che funzionano su un livello file anziché su un livello blocco.
Con l'HDD, esegui principalmente la pulizia casuale anche su un nuovo disco perché puoi, e non c'è motivo di non farlo poiché non comporta alcun costo (a parte una prima configurazione) e nessun aspetto negativo.
badblocks
che controlla i settori danneggiati, scrivi e controlla 0, 1, 01, 10. Per la crittografia dell'intero disco, è comune a raccomandare un crittografato riempimento di zeri (per scrivere i dati crittografati ovunque) per i motivi in risposta di frostschultz (+1), ma facendo tutto questo prima di crittografia è insolito, dopo la crittografia poi correrebadblocks
o mkfs di-cc
sarebbe realizzare lo stesso, oltre a identificare blocchi danneggiati. Forse qualcuno di Kali è un po 'paranoico sulla memoria flash (USB, SSD) non sempre scrivendo lo stesso settore nello stesso posto e scambiando i settori da / verso i backup