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

Question

Eu estou tentando apagar semissionamente um monte de discos rígidos. O seguinte está trabalhando em 20-50Mb / s

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

Mas

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

parece não funcionar. Além disso, quando digito

dd if=/dev/random of=stdout

Ele só me dá alguns bytes, independentemente do que eu passar para 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 parecido com

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

Ou algo parecido ...

    

Answer 1

Tanto /dev/random quanto /dev/urandom usam um "pool de entropia". Quando o pool se esgotar, /dev/random aguardará o reabastecimento, o que requer monitoramento do comportamento do sistema (entrada do teclado, movimentação do mouse, etc.), enquanto /dev/urandom continuará fornecendo dados pseudo-aleatórios. /dev/random é teoricamente maior qualidade, mas /dev/urandom é quase certamente bom o suficiente para seus propósitos. (Mas mesmo /dev/urandom é provavelmente mais lento do que alguns outros métodos. Um gerador mais rápido, mas de qualidade inferior, provavelmente é bom o suficiente para apagar discos rígidos. Não está claro se um atacante ganharia alguma vantagem ao saber a sequência que será gerado, ou que números aleatórios são melhores para este propósito do que uma sequência como 0, 1, 2, 3, 4, ....)

Citando a página random(4) man:

If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys.

UPDATE : A página man 'random (4) foi atualizada desde que escrevi isso. Agora diz:

The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized.

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

Mas /dev/urandom , mesmo que não seja bloqueado, provavelmente será muito lento se você quiser gerar grandes quantidades de dados. Faça algumas medições no seu sistema antes de tentar.

EDITAR: O que se segue é uma digressão sobre números aleatórios "verdadeiros" vs. números pseudo-aleatórios. Se tudo o que você tem interesse é uma resposta prática para a pergunta, pare de ler agora.

Parece que existem afirmações (inclusive em outras respostas aqui) que /dev/random implementa 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 essa afirmação. Eu não acredito que 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 nenhuma evidência de que /dev/random normalmente use um dispositivo desse tipo ou que computadores comuns tenham esse dispositivo. Eles diferem dos PRNGs como a função C rand() , pois não são determinísticos, pois capturam a entropia de fontes praticamente imprevisíveis.

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

1. PRNGs determinísticos, como a função rand() do C, que usa 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 (com 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. Geradores como /dev/random e /dev/urandom que coletam entropia de alguma fonte praticamente imprevisível como atividade de E / S (é por isso que bater no teclado ou mover o mouse pode fazer com que /dev/random produza mais dados) . Não está claro (para mim) se estes satisfazem a definição de um PRNG (eu vi definições que dizem que um PRNG é determinístico), mas também não são verdade geradores de números aleatórios.

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

Answer 2

/dev/random é uma fonte de entropia verdadeira, bytes realmente aleatórios. Como tal, precisa de uma fonte de aleatoriedade. Você pode 'usar' a aleatoriedade lendo a partir dela. Ele lhe dará toda a aleatoriedade que tiver, depois bloqueará até que fique mais. Você provavelmente está sentado lá esperando, e a máquina recebe pouca aleatoriedade e aguarda.

/dev/random para criptografia verdadeiramente aleatória, aleatoriedade de alta qualidade. Como tal, é um exagero para uma substituição da unidade de disco. Escrever de /dev/zero algumas vezes é bom. Ou você pode escrever a partir de /dev/urandom , que não bloqueará e fornecerá números pseudo-aleatórios quando ficar sem aleatoriedade real.

    

Answer 3

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

Por outro lado, um gerador de números verdadeiramente aleatório usa o gerador de números aleatórios de hardware que gera números aleatórios a partir de processos físicos.Estes Os processos incluem fenômenos microscópicos que geram um sinal de "ruído" estatisticamente aleatório de baixo nível, como o ruído térmico ou o 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 consiste tipicamente 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 a um nível macroscópico e algum tipo de analógico para conversor digital para converter a saída em um número digital, muitas vezes um simples dígito binário 0 ou 1. Por amostragem repetida o sinal variando aleatoriamente, uma série de números aleatórios é obtida.

O gerador de números aleatórios de hardware reúne ruído ambiental dos drivers de dispositivo e outras fontes em um pool de entropia. A partir deste conjunto de entropia, números aleatórios são criados. Quando lido, o dispositivo / dev / random retornará somente 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 doc do kernel e informações em um dispositivo .

Uma contrapartida para / dev / random é / dev / urandom (fonte aleatória "desbloqueada" / não-bloqueadora) que reutiliza o conjunto 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úmeros pseudo-aleatórios criptograficamente seguros), você deve usar / dev / urandom.

    

Answer 4

Sem responder à sua pergunta - já existem respostas completas aqui - você também pode conferir Darik's Boot e Nuke aka DBAN que é um limpador de drive de CD ao vivo.

    

Answer 5

Use apenas o comando shred que vem com o coreutils. Utiliza dados aleatórios de maneira eficiente. O dd é uma ferramenta de baixo nível e provavelmente é um nível muito baixo para essa tarefa. shred pulará eficientemente porções não regraváveis do dispositivo, por exemplo.