Devo usar /dev/randomou /dev/urandom?
Em quais situações eu preferiria um ao outro?
Respostas:
Use /dev/urandompara fins mais práticos.
A resposta mais longa depende do sabor do Unix que você está executando.
Historicamente, /dev/randome /dev/urandomforam ambos introduzidos ao mesmo tempo.
Como o @DavidSchwartz apontou em um comentário , o uso /dev/urandomé preferido na grande maioria dos casos. Ele e outros também forneceram um link para os excelentes mitos sobre o/dev/urandom artigo, que eu recomendo para outras leituras.
Em suma:
/dev/random bloqueia quando fica sem entropia/dev/urandomnunca bloqueará, a leitura de /dev/randompode interromper a execução dos processos./dev/urandompode não produzir aleatoriedade de alta qualidade./dev/urandomnão empobrece o conjunto de entropia (usado por /dev/random), mas usa a saída CSPRNG do upstream./dev/urandom.Exceções à regra
No Cryptography Stack Exchange, quando usar /dev/randommais /dev/urandomno Linux
@otus, fornece dois casos de uso :
Logo após a inicialização em um dispositivo de baixa entropia, se ainda não foi gerada entropia suficiente para propagar adequadamente /dev/urandom.
Se você está preocupado com (1), pode verificar a entropia disponível em/dev/random .
Se você estiver fazendo (2), você já saberá :)
Nota: Você pode verificar se a leitura de / dev / random irá bloquear , mas cuidado com as possíveis condições de corrida.
Alternativa: use nenhum!
O @otus também apontou que o getrandom()sistema lerá /dev/urandome bloqueará apenas se a entropia inicial da semente não estiver disponível.
Há problemas com a alteração /dev/urandomno usogetrandom() , mas é concebível que um novo /dev/xrandomdispositivo seja criado com base getrandom().
Não importa, como a Wikipedia diz :
O macOS usa o Yarrow de 160 bits com base no SHA1. Não há diferença entre / dev / random e / dev / urandom; ambos se comportam de forma idêntica. O iOS da Apple também usa o Yarrow.
Não importa, como diz a Wikipedia :
/dev/urandomé apenas um link/dev/randome bloqueia até propagar corretamente.
Isto significa que, após a inicialização, o FreeBSD é esperto o suficiente para esperar até que a entropia de sementes seja reunida antes de fornecer um fluxo interminável de bens aleatórios.
Use /dev/urandom, supondo que seu sistema tenha lido pelo menos uma vez /dev/randompara garantir a propagação inicial adequada.
A página de manual rnd (4) diz :
/dev/urandomNunca bloqueia.
/dev/randomÀs vezes bloqueia. Bloqueará cedo na inicialização se o estado do sistema for previsível.Os aplicativos devem ler de / dev / urandom quando precisarem de dados gerados aleatoriamente, por exemplo, chaves criptográficas ou sementes para simulações.
Os sistemas devem ser projetados para ler criteriosamente pelo menos uma vez em / dev / random na inicialização antes de executar qualquer serviço que fale com a Internet ou que exija criptografia, a fim de evitar a geração de chaves previsivelmente.
/dev/urandom - Exceto que não existe /dev/urandomno OpenBSD. O OpenBSD possui /dev/arandom, mas você não deve usá-lo, você deve usar a arc4random(3)função. Talvez o aconselhamento sobre dispositivos e funções aleatórios deva ser deixado para as pessoas que realmente entendem do que se trata?
/dev/randombloqueia quando fica sem entropia" - no Linux, depende de como você abre o dispositivo. Se os opensinalizadores incluírem O_NONBLOCK, ele não será bloqueado. Se não houver entropia, a chamada retornará imediatamente e indicará 0 bytes lidos.
/dev/randomfor apenas (ex :) 60 bytes, ddvocê fornecerá um arquivo de 60 bytes. Usar headno mesmo cenário provavelmente parecerá estar suspenso para sempre. Nem está fazendo o que você quer, mas, pelo menos para mim, é mais óbvio que headnão está fazendo o que era esperado.
Tradicionalmente, a única diferença entre /dev/urandome /dev/randomé o que acontece quando o kernel pensa que não há entropia no sistema - /dev/randomfalha fechada, /dev/urandomfalha aberta. Ambos os pilotos foram terceirização de entropia de add_disk_randomness(), add_interrupt_randomness()e add_input_randomness(). Veja /drivers/char/random.cpara detalhes.
Editado para adicionar: A partir do Linux 4.8 /dev/urandomfoi reformulado para usar o CSPRNG.
Então, quando você deve falhar fechado? Para qualquer tipo de uso criptográfico, semeando especificamente DRBG. Há um artigo muito bom explicando as consequências do uso /dev/urandomao gerar chaves RSA e não ter entropia suficiente. Leia Minerando seus Ps e Qs .
Essa é uma resposta "eu também", mas reforça a recomendação de Tom Hale. Aplica-se diretamente ao Linux.
/dev/urandom/dev/randomDe acordo com Theodore Ts'o na lista de discussão Linux Kernel Crypto, /dev/randomestá obsoleto por uma década. De Re: [RFC PATCH v12 3/4] Linux Gerador de números aleatórios :
Praticamente ninguém usa / dev / random. É essencialmente uma interface obsoleta; as interfaces primárias recomendadas há mais de uma década são / dev / urandom e, agora, getrandom (2).
Testamos regularmente /dev/randome ele sofre falhas frequentes. O teste executa as três etapas: (1) drene /dev/randomsolicitando 10K bytes no modo sem bloqueio; (2) solicita 16 bytes no modo de bloqueio (3) tenta compactar o bloco para ver se é aleatório (teste do homem pobre). O teste leva alguns minutos para ser concluído.
O problema é tão grave nos sistemas Debain (i686, x86_64, ARM e MIPS) que pedimos ao GCC Compile Farm para instalar o rng-toolspacote em suas máquinas de teste. Em Instalar rng-tools no gcc67 e gcc68 :
Gostaria de solicitar que o rng-tools seja instalado no gcc67 e gcc68. Eles são sistemas Debian e / dev / random sofre esgotamento de entropia sem ferramentas de rng ao torturar bibliotecas de teste que utilizam o dispositivo.
Os BSDs e o OS X parecem OK. O problema é definitivamente o Linux.
Também vale a pena mencionar que o Linux não registra falhas no gerador. Eles não queriam que as entradas preenchessem o log do sistema. Até o momento, a maioria das falhas é silenciosa e passa despercebida pela maioria dos usuários.
A situação deve mudar em breve, pois o kernel imprimirá pelo menos uma mensagem de falha. Do [PATCH] aleatório: silencie os avisos do compilador e corrija a corrida na lista de discussão de criptografia do kernel:
Especificamente, eu adicionei
depends on DEBUG_KERNEL. Isso significa que esses avisos úteis apenas cutucarão outros desenvolvedores de kernel. Provavelmente é exatamente isso que queremos. Se os vários desenvolvedores associados virem um aviso vindo de seu subsistema específico, ficarão mais motivados para corrigi-lo. Usuários comuns em kernels de distribuição não devem ver os avisos ou o spam, pois normalmente os usuários não estão usando DEBUG_KERNEL.Eu acho que é uma má idéia suprimir todas as mensagens do ponto de vista da engenharia de segurança.
Muitas pessoas não executam kernels de depuração. A maioria dos usuários que desejam ou precisam conhecer os problemas não percebem o que está acontecendo. Considere, a razão pela qual descobrimos os problemas do systemd foi devido ao dmesg.
Suprimir todas as mensagens para todas as configurações gera uma rede maior do que o necessário. As configurações que poderiam ser detectadas e corrigidas provavelmente passarão despercebidas. Se o problema não for trazido à tona, ele não será corrigido.
Eu sinto que o kernel está tomando decisões políticas para algumas organizações. Para aqueles que possuem hardware que é efetivamente impossível de corrigir, a organização precisa decidir o que fazer com base em suas adversidades de risco. Eles podem decidir viver com o risco ou podem atualizar o hardware. No entanto, sem informações sobre o problema, eles podem nem perceber que possuem um item acionável.
O compromisso alcançado posteriormente no encadeamento foi de pelo menos um dmesg por módulo de chamada.