Ao apagar com segurança um disco rígido antes de descomissioná-lo, percebi que isso dd if=/dev/urandom of=/dev/sdaleva quase um dia inteiro, enquanto shred -vf -n 1 /dev/sdaleva apenas algumas horas com o mesmo computador e a mesma unidade.
Como isso é possível? Eu acho que o gargalo é a produção limitada de /dev/urandom. O Shred usa algum gerador de pseudo-aleatoriedade que é menos aleatório e suficiente apenas para seu único propósito (ou seja, mais eficiente) do que urandom?
Responder1
Destruirusa um gerador pseudoaleatório interno
Por padrão, esses comandos usam um gerador pseudoaleatório interno inicializado por uma pequena quantidade de entropia, mas podem ser direcionados para usar uma fonte externa com a opção --random-source=file. Um erro será relatado se o arquivo não contiver bytes suficientes.
Por exemplo, o arquivo do dispositivo/dev/urandompoderia ser usado como fonte de dados aleatórios. Normalmente, esse dispositivo reúne ruído ambiental de drivers de dispositivo e outras fontes em um pool de entropia e usa o pool para gerar bits aleatórios. Se o pool estiver com falta de dados, o dispositivo reutiliza o pool interno para produzir mais bits, usando um gerador de números pseudoaleatórios criptograficamente seguro. Mas esteja ciente de que este dispositivo não foi projetado para geração aleatória de dados em massa e é relativamente lento.
Não estou convencido de que dados aleatórios sejam mais eficazes do queuma única passagemdezeros(ou qualquer outro valor de byte) para ocultar o conteúdo anterior.
Para desativar uma unidade com segurança, uso um ímã grande e um martelo grande.
Responder2
Eu acho que isso seria causado pelo dduso de pedaços menores para gravar os dados. Tente dd if=... of=... bs=(1<<20)ver se funciona melhor.