Não faz sentido fazer vários passes. Uma vez é o suficiente.
O preenchimento de uma unidade criptografada com dados aleatórios tem dois usos principais:
- elimine dados antigos e não criptografados
- torna o espaço livre indistinguível de dados criptografados
Normalmente, se você criptografar, não quer que ninguém veja seus dados. Então, as chances são de que, se você tivesse dados antigos e não criptografados nessa unidade, também quer se livrar dela. Um SSD pode cuidar disso mais fácil e rapidamente com blkdiscard . Na verdade, o Linux mkfs TRIMs todos os dados, mesmo sem pedir confirmação, o que torna impossível qualquer tipo de recuperação de dados. Há muito TRIM no Linux.
O espaço livre é um pouco de área cinza. Se você não preencher com dados aleatórios, em um disco rígido novo, os setores que nunca foram gravados serão zeros. Em um SSD, se você permitir descartar / TRIM, o espaço livre também será zero.
Embora isso não afete seus dados de qualquer forma (ele ainda está criptografado), ele revela quanto espaço livre / dados reais você tem e onde esses dados / espaço livre estão localizados. Por exemplo, um hexdump -C de um SSD aparado criptografado será semelhante a este:
# 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.._......%..|
--
...
A partir disso, você pode dizer que eu tenho segmentos de espaço livre no endereço 0xb3eac000 .. 0xb3f70000 , b3f71000 .. b3f72000 , ... e o inverso disso é, claro, segmentos de dados como 0xb3f70000 .. b3f71000 .
O que você pode fazer com isso? Bem, nada (*).
(*) é o que eu gostaria de dizer. Mas as pessoas são criativas . Padrões de espaço livre podem ser usados para derivar o tipo de sistema de arquivos usado (devido a como / onde eles armazenam metadados - se houver espaço livre em que ext4 armazenaria um de seus backups de metadados, é muito provável que não seja ext4 , etc . Às vezes, até revela qual distribuição você usa (se seu instalador Linux preenche o sistema de arquivos deterministicamente, os arquivos podem sempre acabar nos mesmos endereços físicos). Nesse ponto, alguém pode saber onde um arquivo de sistema específico está localizado e pode modificá-lo / danificá-lo de alguma forma. (Os instaladores devem randomizar o modo como eles preenchem os sistemas de arquivos para evitar isso.)
No entanto, essas considerações são muito teóricas e apresentam um risco muito baixo em comparação com a vulnerabilidade da maioria das instalações criptografadas devido a outros motivos. Na maioria das instalações prontas, é mais provável / mais simples adulterar o initramfs, instalar um keylogger ou explorar o sistema em execução do que, de alguma forma, obter acesso bruto e analisar dados criptografados e esperar conseguir algo assim. / p>
Você deve se preocupar com isso antes de se preocupar em revelar o espaço livre.
Com o SSD, é completamente normal ativar o TRIM e, assim, ter espaço livre revelado em todos os momentos. Esse também é o caso das soluções de criptografia que funcionam em uma camada de arquivo em vez de em uma camada de bloco.
Com o HDD, você faz principalmente o apagamento aleatório, mesmo em um disco novo, porque você pode, e não há razão para não envolver, sem custo (além de uma configuração inicial) e sem desvantagens.