Por que meu / dev / random é tão lento ao usar dd?

Estou tentando apagar de maneira semi-segura um monte de discos rígidos. O seguinte está funcionando a 20-50Mb / s

dd if=/dev/zero of=/dev/sda

Mas

dd if=/dev/random of=/dev/sda 

parece não funcionar. Também quando digito

dd if=/dev/random of=stdout

Ele me fornece apenas alguns bytes, independentemente do que eu passo por bs = e count =

Estou usando / dev / random errado? Que outras informações devo procurar para avançar esta solução de problemas? Existe alguma outra maneira de fazer isso com um script ou algo como

makeMyLifeEasy | dd if=stdin of=/dev/sda

Ou algo assim...

Ambos /dev/randome /dev/urandomusam um "pool de entropia". Quando o pool acabar, /dev/randomaguarde o reabastecimento, o que requer o monitoramento do comportamento do sistema (entrada do teclado, movimento do mouse etc.), enquanto /dev/urandomcontinuará fornecendo dados pseudoaleatórios. /dev/randomteoricamente, é de qualidade superior, mas /dev/urandomcertamente é bom o suficiente para seus propósitos. (Mas /dev/urandomé provável que seja mais lento do que alguns outros métodos. Um gerador mais rápido, mas de menor qualidade, provavelmente é bom o suficiente para apagar discos rígidos. Não está claro que um invasor tenha alguma vantagem em saber a sequência que será gerada ou que números aleatórios são melhores para esse fim do que uma sequência como 0, 1, 2, 3, 4, ....)

Citando a random(4)página de manual:

Se você não tiver certeza se deve usar /dev/randomou /dev/urandom, provavelmente deve usar o último. Como regra geral, /dev/urandomdeve ser usado para tudo, exceto para chaves GPG / SSL / SSH de longa duração.

ATUALIZAÇÃO : A página do manual `random (4) foi atualizada desde que escrevi isso. Agora diz:

A /dev/randominterface é considerada uma interface herdada e /dev/urandomé preferível e suficiente em todos os casos de uso, com exceção dos aplicativos que exigem aleatoriedade durante o início da inicialização; para esses aplicativos, getrandom(2)deve ser usado em vez disso, porque ele bloqueará até que o pool de entropia seja inicializado.

Veja também " Mitos sobre / dev / urandom ", de Thomas Hühn.

Mas /dev/urandom, mesmo que não bloqueie, é provável que seja muito lento se você deseja gerar grandes quantidades de dados. Faça algumas medições no seu sistema antes de tentar.

EDIT: O seguinte é uma digressão em números aleatórios "verdadeiros" vs. números pseudo-aleatórios. Se tudo o que lhe interessa é uma resposta prática à pergunta, você pode parar de ler agora.

Eu pareço reivindicações (incluindo em outras respostas aqui) que /dev/randomimplementam um gerador de números aleatórios "verdadeiro", em oposição a um gerador de números pseudo-aleatórios (PRNG). Por exemplo, o artigo da Wikipedia faz tal afirmação. Eu não acredito que isso esteja correto. Há alguma discussão sobre isso aqui, que se refere a geradores de números aleatórios de hardware, mas não vejo evidências de que /dev/randomnormalmente use esse dispositivo ou que computadores típicos tenham esse dispositivo. Eles diferem dos PRNGs como a rand()função C , pois não são determinísticos, pois coletam entropia de fontes que são praticamente imprevisíveis.

Eu diria que existem três classes de geradores de números "aleatórios":

1. PRNGs determinísticos, como a rand()função de C , que usam um algoritmo para gerar sequências repetíveis que possuem (mais ou menos) as propriedades estatísticas de uma sequência verdadeiramente aleatória. Eles podem ser bons o suficiente para jogos (dada uma boa maneira de propagá-los) e são necessários para aplicativos que exigem repetibilidade, mas não são adequados para criptografia.

2. Os geradores gostam /dev/randome /dev/urandomcoletam entropia de alguma fonte praticamente imprevisível, como a atividade de E / S (é por isso que pressionar o teclado ou mover o mouse pode /dev/randomproduzir mais dados). Não está claro (para mim) se eles satisfazem a definição de um PRNG (vi definições que dizem que um PRNG é determinístico), mas também não são verdadeiros geradores de números aleatórios.

3. Geradores de números aleatórios de hardware que são fisicamente imprevisíveis, mesmo com conhecimento completo de seu estado inicial, e que usam adicionalmente técnicas matemáticas para garantir as propriedades estatísticas corretas.

/dev/randomé uma fonte de verdadeira entropia, bytes verdadeiramente aleatórios. Como tal, precisa de uma fonte de aleatoriedade. Você pode 'esgotar' a aleatoriedade lendo a mesma. Isso lhe dará toda a aleatoriedade que possui e depois bloqueia até obter mais. Você provavelmente está apenas esperando, esperando, e a máquina recebe muito pouca aleatoriedade e espera.

/dev/randompara criptografia verdadeiramente aleatória, aleatoriedade de alta qualidade. Como tal, é um exagero para uma substituição de unidade de disco. Escrever /dev/zeroalgumas vezes é bom. Ou você pode escrever a partir de /dev/urandom, que não bloqueia e fornece números pseudo-aleatórios quando a aleatoriedade se esgota.

No Linux / dev / random, existe um arquivo especial que serve números pseudo-aleatórios de alta qualidade. Essa implementação coleta entropia de eventos originados nas interrupções do teclado, mouse, disco e sistema. (consulte este documento) Portanto, quando não há tais eventos, o pool de entropia está vazio, as leituras de / dev / random serão bloqueadas até que o ruído ambiental adicional seja coletado. Isso explica o seu problema. Para preencher o conjunto de entropia, você pode pressionar as teclas do teclado.

Por outro lado, um gerador de números verdadeiramente aleatórios usa um gerador de números aleatórios de hardware que gera números aleatórios a partir de processos físicos. Esses processos incluem fenômenos microscópicos que geram um sinal de "ruído" estatisticamente aleatório de baixo nível, como ruído térmico ou efeito fotoelétrico ou outros fenômenos físicos. Esses processos são, em teoria, completamente imprevisíveis, e as afirmações de imprevisibilidade da teoria estão sujeitas a testes experimentais.

Um gerador de números aleatórios de hardware normalmente consiste em um transdutor para converter algum aspecto dos fenômenos físicos em um sinal elétrico, um amplificador e outros circuitos eletrônicos para aumentar a amplitude das flutuações aleatórias em um nível macroscópico e algum tipo de conversor analógico para digital para converter a saída em um número digital, geralmente um dígito binário simples 0 ou 1. Ao amostrar repetidamente o sinal de variação aleatória, é obtida uma série de números aleatórios.

O gerador de números aleatórios de hardware reúne ruído ambiental de drivers de dispositivo e outras fontes em um pool de entropia. A partir desse conjunto de entropia, são criados números aleatórios. Quando lido, o dispositivo / dev / random retornará apenas bytes aleatórios dentro do número estimado de bits de ruído no pool de entropia. Isso explica o seu problema.

Algumas implementações do Hardware RNG são explicadas no documento e na informação do kernel em um dispositivo .

Uma contraparte de / dev / random é / dev / urandom (fonte aleatória "desbloqueada" / sem bloqueio) que reutiliza o pool interno para produzir mais bits pseudo-aleatórios. Isso significa que a chamada não será bloqueada, mas a saída pode conter menos entropia do que a leitura correspondente de / dev / random.

Portanto, se sua intenção não é gerar CSPRNG (gerador de número pseudo-aleatório criptograficamente seguro), você deve usar / dev / urandom.

Sem responder à sua pergunta - já existem respostas completas aqui - você também pode conferir o Darik's Boot and Nuke, também conhecido como DBAN, que é um limpador de unidade de CD ao vivo.

Basta usar o shredcomando que acompanha o coreutils. Ele usa dados aleatórios de maneira eficiente. O dd é uma ferramenta de baixo nível e provavelmente é um nível muito baixo para esta tarefa. shredpula eficientemente partes não graváveis ​​do dispositivo, por exemplo.