Que problemas existem ao usar / dev / urandom do Linux para gerar chaves criptográficas?
A partir do Linux 5.1, o /dev/randomnão usa mais o pool de bloqueio. Há uma conversa sobre a mudança na página Removendo o pool de bloqueio Linux / dev / random
Eu acredito que o pool de bloqueio do Linux perdeu sua utilidade. O CRNG do Linux gera uma saída boa o suficiente para ser usada até mesmo para a geração de chaves. O pool de bloqueio não é mais forte em nenhum aspecto material e mantê-lo exige muita infraestrutura de valor duvidoso.
Esta série não deve interromper nenhum programa existente. / dev / urandom não foi alterado. / dev / random ainda irá bloquear logo após a inicialização, mas irá bloquear menos do que antes. getentropy () com sinalizadores existentes retornará uma saída que é, para fins práticos, tão forte quanto antes.
Lutomirski observou que ainda há uma questão em aberto se o kernel deve fornecer os chamados "verdadeiros números aleatórios", que é, até certo ponto, o que o pool de bloqueio deveria fazer. Ele só vê uma razão para fazer isso: "conformidade com os padrões do governo". Ele sugeriu que, se o kernel fosse fornecer isso, deveria ser feito por meio de uma interface totalmente diferente - ou ser direcionado para o espaço do usuário, fornecendo uma maneira de extrair amostras de eventos brutos que poderiam ser usados para criar esse pool de bloqueio.
e depois
Para criptógrafos e outros que realmente precisam de um TRNG, Ts'o também é a favor de fornecer a eles uma maneira de coletar sua própria entropia no espaço do usuário para usar como quiserem. A coleta de entropia não é algo que o kernel pode fazer com segurança em todos os diferentes hardwares que ele suporta, nem pode estimar a quantidade de entropia fornecida pelas diferentes fontes, disse ele. (Os negritos são meus)
Então, quais problemas existem ao usar o Linux /dev/urandompara gerar chaves criptográficas?
Respostas
Usar /dev/urandompara gerar chaves criptográficas ou segredos pode ser um problema quando o estado do sistema operacional não é exclusivo. Este é o caso típico quando uma VM acaba de ser inicializada a partir de um modelo: o estado do CSPRNG pode ser compartilhado entre várias VMs. Em casos semelhantes a este, é importante usar /dev/randomou em getrandom()vez de /dev/urandom, para que a saída do CSPRNG bloqueie até que tenha coletado entropia suficiente.
Obviamente, os clones da VM precisam ser reinicializados ou inicializados a partir de um estado de desligamento para que a contagem de entropia seja zerada.
A saída de /dev/urandome /dev/randomvem de ChaCha20. Para considerar inseguro criar chaves criptográficas uma vez que o estado interno de ChaCha20 é inicializado com entropia suficiente, é necessário:
- conheça o estado interno de ChaCha20,
- ou quebrar a cifra ChaCha20, que hoje é considerada uma das mais seguras.
A questão restante é como contar a entropia. O kernel do Linux é extremamente conservador neste ponto, e o estado interno do CSPRNG provavelmente tem muito mais entropia do que o contado (cerca de duas ordens de magnitude a mais). No entanto, contá-lo com exatidão é matematicamente impossível.
Aviso de isenção de responsabilidade: esta resposta é válida para o kernel Linux da versão 4.8 à versão 5.9 , que é a versão mais recente no momento em que esta resposta foi escrita. O Linux CSPRNG foi fortemente refatorado nas versões 4.8 ( introdução da cifra ChaCha20 ) e na versão 5.6 ( simplificação da arquitetura ), com pequenas alterações introduzidas na versão 4.17 e ao longo do caminho.