Atualmente, estou testando gpg --genkey em uma VM Linux. Infelizmente, este software parece confiar em /dev/random para reunir a entropia e educadamente pede ao usuário para digitar manualmente as telas após as telas de entrada aleatoriamente criptografada para que eventualmente acabe gerando uma chave, e eu não encontrei nenhuma linha de comando parâmetro para dizer a ele para usar outro arquivo como fonte de entropia (o cara neste video encontra o mesmo problema ...).
No entanto, o usuário deve ter a liberdade de escolher usar /dev/urandom em vez de não há nada de errado com ele . Está lá principalmente como uma reminiscência de algoritmos mais antigos de PRNG que eram mais fracos do ponto de vista criptográfico. Por exemplo, enquanto o NetBSD manpage garante que a distinção ainda pode ser útil no estágio de inicialização muito cedo, descreve tal distinção como "folclore" e uma teoria imaginária que defende apenas os modelos de ameaça de fantasia. Ninguém concorda com a quantidade de entropia requerida por este comando nem o fato de que a entropia é algo que na verdade é consumido como declarado em página de manual do GPG ( "POR FAVOR, não use este comando, a menos que você saiba o que está fazendo, pode remover a preciosa entropia do sistema!" ).
Eu li sobre pessoas instalando o daemon rngd e configurando-o para usar /dev/urandom como fonte de entropia para alimentar /dev/random , mas acho essa prática muito suja.
Eu tentei solucionar o problema no caminho do FreeBSD removendo /dev/random e vinculando-o a /dev/urandom :
rm /dev/random
ln -s /dev/urandom /dev/random
Eu vejo isso como uma configuração dizendo "Confio em /dev/urandom como fonte de entropia" .
Eu temia encontrar algum tipo de erro, mas isso parece fornecer o resultado esperado, já que o comando agora retorna com sucesso imediatamente.
A minha pergunta é: existe algum efeito colateral conhecido, prático e errado de vincular /dev/random a /dev/urandom em sistemas Linux como feito por padrão em sistemas FreeBSD? Ou alguém poderia imaginar definir isso permanentemente (em um script no final do processo de inicialização, por exemplo) em caso de problemas repetitivos devido a /dev/random bloqueando algum serviço?
Veja Mitos sobre o urandom , não há nenhum ataque conhecido em / dev / urandom que não seria também um ataque em / dev / random. O principal problema que um sistema Linux tem é quando é clonado e executado como várias VMs sem redefinir o conjunto de entropia salvo após a clonagem. Esse é um caso crucial que tangencia o que você quer.
Bem, uma coisa diferente sobre /dev/random é que ele interrompe a saída após o pool de entropia ser usado. tente isso:
$ cat /dev/random
(a few short lines of gibberish)^C
$
/dev/urandom reutilizará o mesmo pool para continuar a saída. como mostrado aqui:
$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$
(Quando você tenta catar estes dispositivos especiais, seu prompt pode estar bagunçado. Basta digitar reset e entrar, seu terminal voltará ao normal)
Use /dev/urandom quando você só precisa preencher algo com um fluxo constante de bits "aleatórios". Use /dev/random para as chaves que você precisa ser absolutamente aleatório.
No Linux, /dev/random fornece bits aleatórios de alta qualidade. Eles são derivados de fontes não previsíveis e não repetíveis, externas à máquina. Em contraste, /dev/urandom usa os mesmos dados aleatórios que /dev/random (se disponível), se não houver nenhum, usa um gerador de números pseudo-aleatórios, que é determinístico . Para a maioria dos propósitos, é imprevisível o suficiente, mas não para aplicações muito exigentes, como criptografia, e muito menos para a criação de chaves de longa duração, como para o GPG.