Quando usar / dev / random vs / dev / urandom

Question

Devo usar /dev/random ou /dev/urandom ?

Em quais situações eu preferiria uma sobre a outra?

    

Answer 1

TL; DR

Use /dev/urandom para fins mais práticos.

A resposta mais longa depende do sabor do Unix que você está executando.

Linux

Historicamente, /dev/random e /dev/urandom foram introduzidos ao mesmo tempo.

Como @DavidSchwartz apontou em um comentário , usar /dev/urandom é o preferido na grande maioria dos casos . Ele e outros também forneceram um link para o excelente artigo Mitos sobre o /dev/urandom que eu recomendo para leitura adicional.

Em resumo:

• A página de manual é enganosa
• Ambos são alimentados pelo mesmo CSPRNG para gerar aleatoriedade (diagrams 2 e 3 )
• /dev/random bloqueia quando fica sem entropia
• A quantidade de entropia é estimada de forma conservadora, mas não é contada
• /dev/urandom nunca será bloqueado, a leitura de /dev/random pode interromper a execução de processos.
• Em casos raros, logo após a inicialização, o CSPRNG pode não ter tido entropia suficiente para ser propagado corretamente e /dev/urandom pode não produzir aleatoriedade de alta qualidade.
• Entropia baixa não é um problema se o CSPRNG foi inicialmente propagado corretamente
• O CSPRNG está sendo constantemente re-propagado
• No Linux 4.8 e superior, /dev/urandom não esvazia o pool de entropia (usado por /dev/random ), mas usa a saída CSPRNG do upstream.
• Use /dev/urandom .

Exceções à regra

Em Quando usar /dev/random over /dev/urandom no Linux do Cryptography Stack Exchange @otus fornece dois casos de uso :

1. Logo após a inicialização em um dispositivo de baixa entropia, se a entropia suficiente ainda não tiver sido gerada para semear adequadamente /dev/urandom .

2. Gerando um bloco único com segurança teórica de informações

Se estiver preocupado com (1), você pode verificar a entropia disponível em /dev/random .

Se você está fazendo (2) você já saberá:)

Observação: você pode verificar se a leitura de / dev / random bloqueará , mas tenha cuidado com possíveis condições de corrida .

Alternativa: não use nenhum dos dois!

@otus também apontou que o sistema getrandom() irá ler a partir de /dev/urandom e só bloqueia se a entropia inicial da semente não estiver disponível.

Existem problemas com a alteração de /dev/urandom para usar getrandom() , mas é concebível que um novo dispositivo /dev/xrandom é criado com base em getrandom() .

macOS

Não importa, como A Wikipédia diz :

macOS uses 160-bit Yarrow based on SHA1. There is no difference between /dev/random and /dev/urandom; both behave identically. Apple's iOS also uses Yarrow.

FreeBSD

Não importa, pois a Wikipédia diz :

/dev/urandom is just a link to /dev/random and only blocks until properly seeded.

Isso significa que, após a inicialização, o FreeBSD é inteligente o suficiente para esperar até que a entropia de sementes seja reunida antes de entregar um fluxo interminável de bondade aleatória.

NetBSD

Use /dev/urandom , supondo que seu sistema tenha lido pelo menos uma vez a partir de /dev/random para garantir uma semeadura inicial adequada.

A rnd (4) manpage diz :

/dev/urandom Never blocks.

/dev/random Sometimes blocks. Will block early at boot if the system's state is known to be predictable.

Applications should read from /dev/urandom when they need randomly generated data, e.g. cryptographic keys or seeds for simulations.

Systems should be engineered to judiciously read at least once from /dev/random at boot before running any services that talk to the internet or otherwise require cryptography, in order to avoid generating keys predictably.

    

Answer 2

Tradicionalmente, a única diferença entre /dev/urandom e /dev/random é o que acontece quando o kernel pensa que não há entropia no sistema - /dev/random falha fechado, /dev/urandom falha aberto. Ambos os drivers estavam obturando a entropia de add_disk_randomness() , add_interrupt_randomness() e add_input_randomness() . Veja /drivers/char/random.c para detalhes.

Editado para adicionar: A partir do Linux, 4.8 /dev/urandom foi retrabalhado para usar o CSPRNG.

Então, quando você deve falhar fechado? Para qualquer tipo de uso criptográfico, especificamente semeando o DRBG. Há um ótimo artigo explicando as conseqüências de usar /dev/urandom ao gerar chaves RSA e não ter entropia suficiente. Leia Mineração do seu Ps e Qs .

    

Answer 3

Esta é uma resposta "eu também", mas reforça a recomendação de Tom Hale. Aplica-se diretamente ao Linux.

• Use /dev/urandom
• Não use /dev/random

De acordo com Theodore Ts'o na lista de discussão do Kernel do Linux, /dev/random foi preterido por uma década. De Re: [RFC PATCH v12 3/4] Gerador de Números Aleatórios Linux :

Practically no one uses /dev/random. It's essentially a deprecated interface; the primary interfaces that have been recommended for well over a decade is /dev/urandom, and now, getrandom(2).

Testamos regularmente o /dev/random e ele sofre falhas frequentes. O teste executa as três etapas: (1) drenar /dev/random solicitando 10K bytes no modo sem bloqueio; (2) solicitar 16 bytes no modo de bloqueio (3) tentar comprimir o bloco para ver se é aleatório (teste do pobre). O teste leva alguns minutos para ser concluído.

O problema é tão ruim nos sistemas Debain (i686, x86_64, ARM e MIPS) que pedimos ao GCC Compile Farm para instalar o pacote rng-tools em suas máquinas de teste. De Instale as ferramentas da rng no gcc67 e no gcc68 :

I would like to request that rng-tools be installed on gcc67 and gcc68. They are Debian systems, and /dev/random suffers entropy depletion without rng-tools when torture testing libraries which utilize the device.

Os BSDs e OS X parecem OK. O problema é definitivamente o Linux.

Também pode valer 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é hoje, a maioria das falhas é silenciosa e não é detectada pela maioria dos usuários.

A situação deve estar mudando em breve, já que o kernel vai imprimir pelo menos uma mensagem de falha. De [PATCH] aleatório: silencie os avisos do compilador e corrija a corrida na lista de discussão de criptografia do kernel:

Specifically, I added depends on DEBUG_KERNEL. This means that these useful warnings will only poke other kernel developers. This is probably exactly what we want. If the various associated developers see a warning coming from their particular subsystem, they'll be more motivated to fix it. Ordinary users on distribution kernels shouldn't see the warnings or the spam at all, since typically users aren't using DEBUG_KERNEL.

     

Acho que é uma má ideia suprimir todas as mensagens de um segurança   ponto de vista da engenharia.

     

Muitas pessoas não executam kernels de depuração. A maioria dos usuários que querem ou precisam   saber das questões não vai perceber o seu acontecimento. Considere, o   A razão pela qual nós aprendemos dos problemas do systemd foi devido ao dmesg.

     

Suprimir todas as mensagens de todas as configurações gera uma rede maior do que   necessário. Configurações que poderiam ser detectadas e corrigidas   provavelmente vai passar despercebida. Se o problema não for trazido à luz, então   não será corrigido.

     

Eu sinto que o kernel está tomando decisões políticas para alguns   organizações. Para quem tem hardware que é efetivamente   unfixable, então a organização tem que decidir o que fazer com base em sua   risco de adversidade. Eles podem decidir viver com o risco, ou podem   decidir atualizar o hardware. No entanto, sem informações sobre o   problema, eles podem nem perceber que têm um item acionável.

O compromisso alcançado mais tarde no tópico foi pelo menos um dmesg por módulo de chamada.