VPN Author WireGuard lançou nova atualização RDRAND

Jason E Donenfeld, autor de VPN WireGuard tornou conhecido há alguns dias uma nova implementação atualizado a partir de um gerador de números aleatórios RDRAND, que é responsável pela operação dos dispositivos /dev/random e /dev/urandom no kernel Linux.

No final de novembro, Jason foi incluído na lista de mantenedores do controlador aleatório e agora publicou os primeiros resultados de seu trabalho de retrabalho.

É mencionado no anúncio que a nova implementação é notável por a mudança para usar a função de hash BLAKE2s em vez de SHA1 para operações de mistura de entropia.

O próprio BLAKE2s tem a boa propriedade de ser internamente baseado no
Permutação ChaCha, que o RNG já está usando para expansão, então
não deve haver problema com novidade, originalidade ou CPU incrível
comportamento, uma vez que é baseado em algo que já está em uso.

Além disso, nota-se que a mudança também melhorou a segurança do gerador de números pseudo-aleatórios eliminando o problemático algoritmo SHA1 e evitando sobrescrever o vetor de inicialização RNG. Como o algoritmo BLAKE2s está à frente do SHA1 em desempenho, seu uso também teve um efeito positivo no desempenho do gerador de números pseudo-aleatórios (testes em um sistema com processador Intel i7-11850H mostraram um aumento de 131% na velocidade). ) .

Outra vantagem que se destaca é a de transferir a mistura de entropia para BLAKE2 é a unificação dos algoritmos utilizados: BLAKE2 é usado na criptografia ChaCha, que já é usada para extrair sequências aleatórias.

BLAKE2s geralmente é mais rápido e certamente mais seguro, foi realmente muito quebrado. Além da A compilação atual no RNG não usa a função SHA1 completa, pois especifica e permite que você sobrescreva o IV com a saída RDRAND de uma maneira não documentado, mesmo se RDRAND não estiver definido como 'confiável', ele o que significa possíveis opções maliciosas de IV.

E seu comprimento curto significa para manter apenas meio segredo ao realimentar o mixer nos dá apenas 2 ^ 80 bits de sigilo direto. Em outras palavras, não só a escolha da função hash está desatualizada, mas seu uso também não é muito bom.

Além disso, foram feitas melhorias no gerador de números pseudo-aleatórios CRNG cripto-seguro usado na chamada getrandom.

Também é mencionado que melhorias se resumem a limitar a chamada para o gerador RDRAND lento ao extrair entropia, o que Pode melhorar o desempenho por um fator de 3,7. Jason demonstrou que a chamada para RDRAND Só faz sentido em uma situação em que o CRNG ainda não foi totalmente inicializado, mas se a inicialização do CRNG estiver completa, seu valor não afeta a qualidade do fluxo gerado e, neste caso, é possível fazê-lo sem chamar RDRAND.

Este compromisso visa resolver estes dois problemas e, ao mesmo tempo, manter a estrutura geral e semântica o mais próximo possível do original.
Especificamente:

a) Em vez de substituir o hash IV com RDRAND, colocamos nos campos "sal" e "pessoal" documentados do BLAKE2, que são criado especificamente para este tipo de uso.
b) Como esta função retorna o resultado do hash completo para o coletor de entropia, retornamos apenas metade do comprimento do hash, assim como foi feito antes. Isso aumenta a segredo de avanço de construção de 2 ^ 80 a 2 ^ 128 muito mais confortável.
c) Em vez de usar apenas a função bruta "sha1_transform", em vez disso, usamos a função BLAKE2s completa e apropriada, com conclusão.

As alterações estão agendadas para inclusão no kernel 5.17 e já foram revisados ​​pelos desenvolvedores Ted Ts'o (o segundo responsável por manter o controlador aleatório), Greg Kroah-Hartman (responsável por manter o kernel Linux estável) e Jean-Philippe Aumasson (autor dos algoritmos BLAKE2 /3).

Por fim, se estiver interessado em saber mais sobre o assunto, pode consultar os detalhes no link a seguir


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.