Infelizmente, / 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 uma vez almofadas. A maioria das informações abaixo é resumida no artigo (muito longo) no link
O problema é que / dev / random não é verdadeiramente aleatório; ele usa um CSPRNG para gerar sua saída. De fato, o / dev / random usa exatamente o mesmo CSPRNG que o / dev / urandom. A única diferença é que / dev / blocos aleatórios se sua estimativa interna de entropia é insuficiente.
A palavra "estimativa" na sentença anterior é fundamental. A maioria das pessoas pensa que essa estimativa é sempre precisa e perfeita, mas na realidade não é exata. No instante em que a estimativa está errada, você perde todas as garantias de segurança prováveis do one-time pad, e tudo o que resta é a segurança computacional - não melhor do que se você tivesse usado / dev / urandom!
Obter a estimativa de entropia um pouco errada não torna seu bloco de uso único um pouco inseguro. A garantia de segurança comprovada de um bloco único é tudo ou nada.
A premissa desta questão é 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 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 escolha muito ruim do ponto de vista de segurança, já que o hardware está em posição privilegiada para fazer coisas maliciosas e é essencialmente inadmissível.
