Por que o GNU shred é mais rápido que o dd ao preencher uma unidade com dados aleatórios?

Ao apagar com segurança um disco rígido antes da desativação, notei que isso dd if=/dev/urandom of=/dev/sdaleva quase um dia inteiro, enquanto shred -vf -n 1 /dev/sdaleva apenas algumas horas no mesmo computador e na 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 objetivo (ou seja, mais eficiente) do que urandom?

O Shred usa um gerador pseudo-aleatório interno

Por padrão, esses comandos usam um gerador pseudo-aleató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 / urandom pode 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 tiver poucos dados, o dispositivo reutiliza o pool interno para produzir mais bits, usando um gerador de números pseudo-aleatórios criptograficamente seguros. Mas lembre-se de que este dispositivo não foi projetado para geração de dados aleatórios em massa e é relativamente lento .

Não estou convencido de que os dados aleatórios sejam mais eficazes do que uma única passagem de zeros (ou qualquer outro valor de byte) para ocultar o conteúdo anterior.

Para desativar com segurança uma unidade, eu uso um grande ímã e um grande martelo.

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.