geração de chaves gpg no CD ao vivo do Tails - por que tão rápido?

Question

Eu usei apenas gpg2 --gen-key para gerar um par de chaves RSA de 2048 bits em um sistema operacional em execução em um CD ao vivo (Tails). Isso aconteceu muito mais rápido do que eu esperava. Quando eu fiz isso antes em uma máquina comum, leva um pouco de tempo e eu normalmente preciso esperar e fazer algo diferente. Eu acho que é porque leva algum tempo para gerar a quantidade necessária de aleatoriedade.

Um live cd tem algum processo incomum de tal forma que o processo de boot gera mais do que a aleatoriedade normal? Ou é possível que esteja usando /dev/urandom ? Tanto quanto eu sabia, o gpg usa /dev/random e é por isso que pode levar algum tempo para gerar chaves.

    

Answer 1

Eu encontrei a resposta: Tails vem empacotado com o gerador de números aleatórios 'haveged'. link

Eu editei o título da pergunta para refletir que isso é específico para o Tails.

Aqui está uma discussão sobre se o algoritmo HAVEGED é bom:

A abordagem conservadora adotada pelo gpg no uso de /dev/random pode ser um exagero em muitas situações, comparado ao uso de /dev/urandom , mas do ponto de vista específico de um ambiente de CD ao vivo usado para geração de chaves gpg sem restrições de tempo. parece desnecessário.

Então, parece-me que a solução mais simples é eliminar o processo contido no Tails, esperar que o / proc / sys / kernel / random / entropy_avail se esgote, e deixar o gpg fazer o que normalmente faz.

    

Answer 2

Primeiro, a diferença entre /dev/urandom e /dev/random é que /dev/random bloqueará até que haja entropia suficiente para gerar um número aleatório, enquanto /dev/urandom não bloqueia quando a entropia estiver esgotada. Isso também significa que a geração em um aplicativo /dev/urandom pode ser menos aleatória do que um número de /dev/random .

Para as suas perguntas, o tempo de execução para gerar segredos varia com base na entropia disponível no sistema e como você tem sorte de obter dois primos rapidamente (sem esgotar o pool de entropia).

Se você sempre obter um par de chaves gerado rapidamente no Tails, provavelmente há algo errado com a implementação.

    

Answer 3

Entropia ("aleatoriedade") é acumulada no kernel. Se o kernel acumulou entropia suficiente antes do início do GPG, o GPG se beneficia dele imediatamente.

A manipulação de entropia do Linux está um pouco quebrada. O Linux possui dois dispositivos: /dev/random e /dev/urandom . /dev/random bloqueia pelo tempo que for necessário para acumular entropia suficiente. /dev/urandom sempre retorna dados sem bloqueio. Em princípio, isso seria bom. O problema é que o cálculo de entropia do Linux é extremamente conservador: ele pressupõe que a entropia se esgota, o que só é verdade em um sentido altamente teórico. Então /dev/random tende a bloquear quando não deveria.

Em um sistema normal, você deve use apenas /dev/urandom - embora alguns O software, incluindo o gpg, não lhe dá uma escolha . No entanto, em um CD ao vivo, imediatamente após a inicialização, pode haver muito pouca entropia, a menos que seu computador tenha um RNG de hardware (como o RdRand instrução em processadores Intel recentes) e o Linux a suporta. Portanto, nesse caso, você precisa usar /dev/random e aguardar, se necessário. A interação do usuário (por exemplo, mover o mouse) contribuirá para essa entropia.

Veja também Adicionando "entropia numérica aleatória" para Chaves GPG? e Você pode explicar a estimativa de entropia usada no random.c

Novamente, você não precisa se preocupar: o GPG + Linux é muito conservador quando se trata de estimar a entropia. Se o GPG gerar uma chave rapidamente, você já interagiu o suficiente com o computador para fornecer entropia suficiente ou o seu computador tem um RNG de hardware compatível.