Feeding / dev / random com o disco lê, etc.

Question

Existe alguma maneira de alimentar /dev/random com entropia suficiente? Os dados não precisam ser realmente aleatórios, ou seja, posso acrescentar a hora do dia com o pid e adicionar 27 a ele, não importa que eu queira apenas fazer com que ele seja executado mais rápido.

Eu tentei fazer a bola rolar com dd if=/dev/zero of=/dev/null . Quero saber se há alguma maneira de usar add_keystroke_randomness em /linux/random.h para alimentar artificialmente /dev/random para que eu não receba essas chamadas de bloqueio imprevisíveis. ou seja, estou disposto a sacrificar alguma aleatoriedade em troca de velocidade.

P.S. - por favor, não sugira usar /dev/urandom

    

Answer 1

(Minha resposta se aplica ao Linux. Os princípios gerais se aplicam a outras variantes unix, mas não à distinção random / urandom .)

Isso já está acontecendo dentro do kernel.

Nunca é demais injetar entropia adicional. Se você tem um monte de bytes pseudo-aleatórios, simplesmente escreva-os em /dev/random e eles serão misturados no pool de entropia.

Havege é um programa popular para reunir entropia extra.

dd if=/dev/zero of=/dev/null não causa nenhuma E / S de hardware, por isso não adiciona nenhuma entropia. As teclas contêm uma pequena quantidade de entropia.

Observe que, se você estiver lendo /dev/random no Linux, está fazendo errado. Os designers de Linux isso é errado : eles declararam que a entropia é algo que é usado rapidamente, o que não é o caso . A solução para " /dev/random blocks" não é "injetar mais entropia", mas "usar o dispositivo apropriado". Se você quer ouvir ou não, você deve ler a partir de /dev/urandom .

    

Answer 2

Existem várias soluções para gerar entropia. Por exemplo, haveged (que eu estou muito feliz comigo mesmo), timer_entropyd , audio-entropyd , etc. etc. eles normalmente geram entropia suficiente para a maioria dos aplicativos que usam /dev/random . Se você quiser fazer tudo, existem também geradores aleatórios de hardware, disponíveis como pen drives USB. Embora eles possam render menos entropia do que você pensa ...

Ainda assim, /dev/urandom é sempre uma boa opção quando você precisa que os dados estejam disponíveis sem atraso.

Para grandes quantidades de dados (como sobrescrever discos rígidos), nenhum dos dispositivos aleatórios é adequado em termos de velocidade, independentemente da entropia disponível; uma solução baseada em PRNG como shred faz um trabalho melhor / mais rápido.

    

Answer 3

Dependendo da versão do kernel, o Linux implementa add_disk_randomness() , add_input_randomness() e add_interrupt_randomness() como fontes de entropia. Eles correspondem a eventos de E / S de disco, eventos de teclado e mouse e eventos de interrupção (IRQ). Veja random.c para implementação exata. Essas fontes são condicionadas, misturadas e armazenadas internamente e usadas para alimentar /dev/random de bloqueio e drivers /dev/urandom sem bloqueio. Nesse caso, sem bloqueio significa que uma chamada para /dev/urandom sempre produzirá saída mesmo se o conjunto de entropia não contiver entropia. No entanto, improvável, o uso de /dev/urandom pode levar à semeadura de baixa entropia e ao RNG determinístico previsível. Isso, por sua vez, pode levar à criptografia quebrada, com a RSA sendo especialmente vulnerável a condições de baixa entropia. Então você não deve usar /dev/urandom para criptografia. No entanto, o tempo de inicialização /dev/urandom entropy é persistentemente problemático em sistemas sem cabeçalho e exigiria fontes adicionais de entropia para operar corretamente.

A solução mais fácil para entropia de inicialização insuficiente é ativar RdRand (ou RdSeed ) via hw_rand , mas isso exige a implementação da caixa-preta da Intel (e agora da AMD). Se acontecer de você usar o QorlQ, existe uma funcionalidade SEC equivalente.

Como alternativa, há geradores de números aleatórios de software true (?) que você pode implementar. Minha recomendação é CPU Time Jitter por Stephan Muller, pois é um projeto bem documentado e fácil de integrar ao sistema existente. Tenha em mente que ele deve ser compilado sem otimizações para resultados máximos de entropia.