Fontes de Entropy para Linux

Digamos que eu queira um gigabyte ou mais de dados aleatórios de / dev / random, adequado para um bloco único (então / dev / urandom está fora.) Como eu proponho meu / dev / random com entropia suficiente para fazer isso? Estou procurando comandos e programas específicos para isso. Eu não quero comprar nada. Estou usando o Arch Linux, se isso faz diferença.

Dois programas que podem aumentar o pool de entropia sem exigir hardware extra são rng-toolse haveged. rng-toolsusa RNGs disponíveis em CPUs e chipsets havegedmodernos , usa aleatoriedade de CPU moderna (comportamento do cache etc.). Ambos estão disponíveis no Arch, e o wiki do Arch tem uma página interessante para discuti-los. Eu não tentei usá-los para gerar um gigabyte de dados, mas deve ser possível em uma quantidade razoável de tempo.

Você exclui explicitamente a compra de qualquer coisa, mas apenas por uma questão de integridade, há um artigo interessante no LWN sobre entropia com NeuG , que inclui discussões havegede várias outras abordagens. Você pode comprar uma placa STM8S capaz de executar NeuG por menos de US $ 10 ou uma FST-01 por US $ 35.

Infelizmente, o / dev / random também não é adequado para uso em um bloco único, pelo menos não o tipo de bloco único (com garantias de segurança prováveis) que a maioria das pessoas imagina quando pensa ou implementa blocos únicos. A maioria das informações abaixo é resumida no artigo (muito longo) em http://www.2uo.de/myths-about-urandom/

O problema é que / dev / random não é verdadeiramente aleatório; ele usa um CSPRNG para gerar sua saída. De fato, / dev / random usa exatamente o mesmo CSPRNG que / dev / urandom. A única diferença é que / dev / bloqueia aleatoriamente se sua estimativa interna de entropia é insuficiente.

A palavra "estimativa" na frase anterior é a chave. A maioria das pessoas pensa que essa estimativa é sempre precisa e perfeita, mas na realidade não é de todo precisa. No instante em que a estimativa está errada, você perde todas as garantias de segurança prováveis ​​do teclado único e tudo o que resta é segurança computacional - nada melhor do que se você tivesse usado / dev / urandom!

Entender a estimativa da entropia um pouquinho errado não torna seu controle único um pouco inseguro. A garantia de segurança comprovável de um bloco único é tudo ou nada.

A premissa desta pergunta é que os problemas com / dev / random podem ser "corrigidos" adicionando mais entropia. Infelizmente, essa premissa está errada. Uma fonte maliciosa de entropia é muito pior do que nenhuma entropia, porque as fontes de entropia geralmente têm acesso a dados internos e podem exportar esses dados secretamente usando a saída RNG - consulte http://blog.cr.yp.to/20140205-entropy .html para uma discussão completa (muito tempo para resumir aqui). Em particular, uma fonte de entropia de hardware (como recomendado por várias outras respostas) é uma péssima escolha do ponto de vista de segurança, uma vez que esse hardware está em uma posição privilegiada para executar ações maliciosas e é essencialmente não auditável.

Parece que um componente HW é a melhor ideia. Existem alguns ICs geradores de HW por aí, mas você precisa confiar neles quando eles vierem.

Duas soluções provavelmente boas são induzir o componente a criar ruído; duas soluções principais parecem ser o viés de temperatura e o ruído avanche criado com um diodo (consulte http://web.archive.org/web/20061117145903/http://willware.net:8080/hw-rng.html )

Como os componentes como giroscópio e acelerômetro se tornaram mais sensíveis, fazê-los funcionar com a mais alta sensibilidade e usar seu valor LSB também pode ser uma solução interessante, mas o AFAIK ninguém como auditado.

É engraçado, pois há muito papel em NOT RNG, mas não uma implementação de HW aberta e verificada

Você poderia usar pycsprng.py . Criptograficamente seguro? Não tenho muita certeza, mas gostaria de uma revisão por pares.

python pycsprng.py | pv | dd of=data.file bs=1024 count=1000

O canal para pvé opcional e ajudará você a saber quantos dados foram transferidos.

Você pode achar que tamanhos maiores de bloco (bs) aumentam o desempenho. Você precisará ajustar a contagem para não gerar um arquivo muito grande se aumentar o tamanho do bloco.

O que você obtém de um canal de microfone analógico quando não conecta um microfone geralmente é apenas estático. Canalize isso através do bzip2, por exemplo, para clareamento, misture-o com outra fonte de aleatoriedade (urandom ou outro conector de microfone), talvez canalize o resultado através do openssl para uma boa medida e o que você obtém deve ser bem aleatório.

Seria difícil provar quaisquer propriedades de segurança rígidas e rápidas sobre a aleatoriedade do resultado.

Se você estiver usando o kernel Linux 2.6.9 ou mais recente no ambiente amd64 / x86_64, virtual ou físico do processador, tente ncomputers.org/pandom um verdadeiro gerador de números aleatórios, que oferece 8 KiB / s de entropia de 64 ubits / 64 bits através de 8 KiB / s de entropia./dev/random

Para gerar 100 MB de dados aleatórios gerados por hardware, você pode:

• Grave 20 minutos de áudio (96khz 16 bits mono) com o microfone embutido no seu computador (disponível em um laptop). Você receberá um arquivo WAV de ~ 220 MB.

• Descarte os bits não úteis e embaralhe os bits dos dados binários (muitas maneiras de fazer isso) com algumas contas

• Exportar os bits embaralhados como um arquivo binário de ~ 100 MB

Aqui está um artigo sobre isso: Uma tentativa de gerar entropia verdadeira e dados aleatórios com áudio (e o microfone interno do seu computador) .