“Alimentar /dev/urandom no pool de entropia para /dev/random ” é trapaça - você está fingindo fornecer nova entropia quando, na verdade, os dados são derivados deterministicamente do estado atual do RNG. Felizmente, como você notado , a regra de que você está trapaceando é inútil: a entropia não diminui de fato apesar do que o kernel Linux finge.
A baixa entropia da estimativa de /dev/random do Linux é comum e quase sempre um alarme falso: a estimativa é excessivamente conservadora.
/dev/urandom é seguro para geração de chaves , portanto, o Pidgin deve usar /dev/urandom (que não bloqueia) em vez de /dev/random (que pode bloquear e geralmente faz).
Há apenas um caso em que /dev/random de bloqueio é legítimo porque o sistema realmente não possui entropia suficiente: quando o sistema é novo demais para ter entropia acumulada. Os sistemas Linux normalmente salvam entropia para a próxima reinicialização, portanto, na prática, a entropia baixa genuína só acontece em duas circunstâncias:
- em uma instalação totalmente nova - isso é uma preocupação especial em dispositivos incorporados que geram uma chave na primeira vez que são ativados;
- em um sistema ativo.
Onde definir a culpa não é realmente uma consideração produtiva, mas se você precisar: Arch Linux e você são totalmente inocentes. O Pidgin deve usar /dev/urandom ou, pelo menos, oferecer uma maneira, por isso faz parte da culpa. O kernel do Linux deve realmente fornecer uma interface que garanta aleatoriedade com qualidade de criptografia e bloqueie somente se a entropia estiver realmente ausente (como /dev/random do FreeBSD).