Atualmente estou testando gpg --genkeyem uma VM Linux. Infelizmente, este software parece depender de /dev/randomcoletar entropia e pede educadamente ao usuário para digitar manualmente telas após telas de entrada criptograficamente aleatória, para que possa eventualmente acabar gerando uma chave, e não encontrei nenhum parâmetro de linha de comando para informar para usar outro arquivo como fonte de entropia (o caraneste vídeoencontra o mesmo problema...).
No entanto, o usuário deve ser livre para optar por usar, /dev/urandomuma vez queNão há nada de errado com isso. Está lá principalmente como uma reminiscência de algoritmos PRNG mais antigos que eram mais fracos do ponto de vista criptográfico. Por exemplo, enquantoPágina de manual do NetBSDadmite que a distinção ainda pode ser útil em um estágio inicial de inicialização, ele descreve tal distinção como"folclore"e um"teoria imaginária que defende apenas contra modelos de ameaças fantasiosas". Ninguém concorda com nenhum dos doisa quantidade de entropia exigida por este comandonem o fato de que a entropia é algo que é realmente consumido, conforme declarado emPágina de manual do GPG("POR FAVOR, não use este comando a menos que saiba o que está fazendo, pois pode remover a preciosa entropia do sistema!").
Eu li sobrepessoas instalando o rngddaemone configurá-lo para usar /dev/urandomcomo fonte de entropia para alimentar /dev/random, mas acho essa prática muito suja.
Tentei solucionar o problema no modo FreeBSD, removendo-o /dev/randome vinculando-o a /dev/urandom:
rm /dev/random
ln -s /dev/urandom /dev/random
Eu vejo isso como um cenário que diz"Eu confio /dev/urandomcomo 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.
Minha pergunta é:existe algum efeito colateral conhecido, prático e errado da vinculação /dev/randomem /dev/urandomsistemas Linux, como feito por padrão em sistemas FreeBSD?Ou seria possível definir isso permanentemente (em um script no final do processo de inicialização, por exemplo) em caso de problemas repetitivos devido ao /dev/randombloqueio de algum serviço?
Responder1
VerMitos sobre urandom, não há nenhum ataque conhecido a /dev/urandom que não seja também um ataque a /dev/random. O principal problema que um sistema Linux tem é quando ele é clonado e executado como várias VMs sem redefinir o pool de entropia salvo após a clonagem. Esse é um caso secundário tangencial ao que você deseja.
Responder2
Bem, uma coisa diferente /dev/randomé que ele interrompe a saída depois que o pool de entropia é usado. tente isto:
$ cat /dev/random
(a few short lines of gibberish)^C
$
/dev/urandomno entanto, reutilizará o mesmo pool para continuar a produção. como mostrado aqui:
$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$
(Quando você tenta capturar esses dispositivos especiais, seu prompt pode ficar confuso. Basta digitar resete entrar, seu terminal voltará ao normal)
Use /dev/urandomquando você só precisa preencher algo com um fluxo constante de bits "aleatórios". Use /dev/randompara chaves que você precisa que sejam absolutamente aleatórias.
Responder3
No Linux, /dev/randomfornece bits aleatórios de alta qualidade. Eles são derivados de fontes que sãonãoprevisível enãorepetível, externo à máquina. Em contraste, /dev/urandomusa os mesmos dados aleatórios /dev/random(se disponíveis), se não houver nenhum, usa um gerador de números pseudo-aleatórios, que édeterminístico. Para a maioria dos propósitos, é bastante imprevisível, masnãopara aplicações muito exigentes, como criptografia, e muito menos para criar chaves de longa duração, como o GPG.