Há um grão de verdade nisso, na verdade mais verdade do que mito, mas, no entanto, a afirmação reflete um mal-entendido fundamental do que está acontecendo. Sim, mover o mouse enquanto gera uma chave com o GPG pode ser uma boa ideia. Sim, mover o mouse contribui com uma entropia que torna aleatórios os números aleatórios. Não, mover o mouse não torna a chave mais segura.
Todos os bons geradores aleatórios adequados para criptografia, e os Linux estão nessa categoria, têm dois componentes:
- Uma fonte de entropia , que não é determinística. O objetivo da entropia é inicializar o gerador de números aleatórios com dados imprevisíveis. A fonte de entropia deve ser não determinística: caso contrário, um adversário pode reproduzir a mesma computação.
- Um gerador de números pseudo-aleatórios , que produz números aleatórios imprevisíveis de maneira determinística a partir de um estado interno variável.
A entropia deve vir de uma fonte externa ao computador. O usuário é uma fonte de entropia. O que o usuário faz geralmente não é aleatório, mas o bom momento das teclas e movimentos do mouse é tão imprevisível que pode ser um pouco aleatório - não muito aleatório, mas pouco a pouco, ele se acumula. Outras fontes potenciais de entropia incluem o tempo dos pacotes de rede e o ruído branco da câmera ou do microfone. Versões e configurações diferentes do kernel podem usar um conjunto diferente de fontes. Alguns computadores possuem circuitos RNG de hardware dedicados baseados em decaimento radioativo ou, menos impressionante, em circuitos eletrônicos instáveis. Essas fontes dedicadas são especialmente úteis em dispositivos e servidores incorporados, que podem ter um comportamento bastante previsível em sua primeira inicialização, sem que um usuário faça coisas estranhas.
O Linux fornece números aleatórios para programas através de dois dispositivos: /dev/randome/dev/urandom . A leitura de qualquer dispositivo retorna a qualidade criptográfica. Ambos os dispositivos usam o mesmo estado RNG interno e o mesmo algoritmo para transformar o estado e produzir bytes aleatórios. Eles têm limitações peculiares que tornam nenhum deles a coisa certa:
/dev/urandom pode retornar dados previsíveis se o sistema ainda não tiver acumulado entropia suficiente./dev/randomcalcula a quantidade de entropia disponível e bloqueia se não houver o suficiente. Isso parece bom, exceto que o cálculo é baseado em considerações teóricas que fazem com que a quantidade de entropia disponível diminua linearmente com cada bit de saída. Assim, /dev/randomtende a bloquear muito rapidamente.
Os sistemas Linux salvam o estado RNG interno em disco e o restauram no momento da inicialização. Portanto, a entropia é transferida de uma inicialização para a seguinte. O único momento em que um sistema Linux pode não ter entropia é quando ele é instalado recentemente. Uma vez que existe entropia suficiente no sistema, a entropia não diminui; apenas o cálculo defeituoso do Linux diminui. Para mais explicações sobre essa consideração, leia /dev/urandomé adequado para gerar uma chave criptográfica , por um criptógrafo profissional. Veja também. Você pode explicar a estimativa de entropia usada em random.c .
Mover o mouse adiciona mais entropia ao sistema. Mas o gpg pode apenas ler /dev/random, não/dev/urandom (uma maneira de resolver esse problema é criar /dev/randomo mesmo dispositivo 1: 9 que /dev/urandom), por isso nunca corre o risco de receber números aleatórios que não sejam aleatórios o suficiente. Se você não mover o mouse, a chave é o mais aleatória possível; mas o que pode acontecer é que o gpg pode ser bloqueado em uma leitura de /dev/random, aguardando o contador de entropia do kernel subir.