Existe alguma maneira de alimentar /dev/randomcom entropia suficiente? Os dados não precisam ser verdadeiramente aleatórios, ou seja, posso acrescentar a hora do dia ao pid e adicionar 27 a ele, não importa, só quero fazê-lo funcionar mais rápido.
Tentei fazer a bola rolar com dd if=/dev/zero of=/dev/null. Quero saber se há alguma maneira que eu possa usar add_keystroke_randomnesspara /linux/random.hme alimentar artificialmente /dev/randompara não receber aquelas chamadas de bloqueio imprevisíveis. ou seja, estou disposto a sacrificar alguma aleatoriedade em troca de velocidade.
PS - por favor, não sugira usar/dev/urandom
Responder1
Existem várias soluções para gerar entropia. Por exemplo haveged(com o qual estou muito feliz), timer_entropyd, audio-entropyd, etc. etc. eles geralmente geram entropia suficiente para a maioria dos aplicativos que usam /dev/random. Se você quiser fazer tudo, também existem geradores aleatórios de hardware, disponíveis como pendrives. Embora eles possam produzir menos entropia do que você imagina...
Ainda assim, /dev/urandomé sempre uma boa escolha quando você precisa que os dados estejam disponíveis sem demora.
Para grandes quantidades de dados (como a substituição de discos rígidos), nenhum dos dispositivos aleatórios é adequado em termos de velocidade, independentemente da entropia disponível; uma solução baseada em PRNG shredfaz um trabalho melhor/mais rápido.
Responder2
(Minha resposta se aplica ao Linux. Os princípios gerais se aplicam a outras variantes do Unix, mas não à distinção random/ urandom.)
Isso já está acontecendo dentro do kernel.
Nunca é demais injetar entropia adicional. Se você tiver um monte de bytes pseudo-aleatórios por aí, simplesmente escreva-os em /dev/randome eles serão misturados no pool de entropia.
Havegeé um programa popular para coletar entropia extra.
dd if=/dev/zero of=/dev/nullnão causa nenhuma E/S de hardware, portanto não adiciona nenhuma entropia. As teclas digitadas contêm uma pequena quantidade de entropia.
Observe que se você estiver lendo /dev/randomno Linux, estará fazendo errado. Os designers do Linuxentendi errado: declararam que a entropia é algo que se esgota rapidamente, o quenão é o caso. A solução para os “ /dev/randombloqueios” não é “injetar mais entropia”, mas “usar o dispositivo apropriado”. Quer você queira ouvir ou não,você deveria ler de/dev/urandom.
Responder3
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 condicionam, misturam e armazenam internamente e são usadas para alimentar drivers bloqueadores /dev/randome não bloqueadores . /dev/urandomNesse caso, o não bloqueio significa que uma chamada para /dev/urandomsempre produzirá saída, mesmo que o conjunto de entropia não contenha entropia. Por mais improvável que seja, /dev/urandomo uso pode levar à semeadura de baixa entropia e ao RNG determinístico previsível. Isso, por sua vez, pode levar à quebra da criptografia, sendo o RSA especialmente vulnerável a condições de baixa entropia. Portanto, você não deve usar /dev/urandompara criptografia. No entanto, /dev/urandoma entropia do tempo de inicialização é persistentemente problemática em sistemas headless e exigiria fontes de entropia adicionais para operar corretamente.
A solução mais fácil para a entropia de inicialização insuficiente é habilitar RdRand(ou RdSeed) via hw_rand, mas isso requer uma implementação confiável da caixa preta da Intel (e agora da AMD). Se acontecer de você usar QorlQ, existe uma funcionalidade SEC equivalente.
Como alternativa, existem geradores de números aleatórios verdadeiros (?) de software que você pode implementar. Minha recomendação éTremulação de tempo de CPUpor Stephan Muller, pois é um projeto bem documentado e fácil de integrar com o sistema existente. Tenha em mente que ele deve ser compilado sem otimizações para obter resultados máximos de entropia.