Se um pequeno redirecionamento for aceitável, pv é uma boa maneira, em geral, de atingir esse tipo de coisa, mas GPG tem (sem surpresas) /dev/random codificado para ele, então isso não vai funcionar aqui sem alguma hackeria. No linux, usando unshare temporariamente sobrepor /dev/random é provavelmente o menos desagradável, embora exija permissões de root:
mkfifo $HOME/rngfifo
pv -s 300 /dev/random > $HOME/rngfifo
pv irá bloquear até que haja um leitor no fifo. Então, como root ou via sudo :
unshare -m -- sh -c "mount --bind $HOME/rngfifo /dev/random && gpg --gen-key [...]"
Uma possível fonte útil de dados é o próprio driver de dispositivo aleatório ( drivers/char/random.c ). Ele suporta um parâmetro "debug", mas, infelizmente, nas versões que eu verifiquei, ele foi definido ( #if 0 , 2.6.xe 3.4.x) e foi removido completamente nos kernels recentes em favor de suporte ao ftrace . O driver faz uma chamada ftrace ( trace_extract_entropy() ) toda vez que os dados são lidos. Para isso, parece um exagero para mim, assim como systemtap , e o outro opções de rastreamento e depuração (PDF) .
Uma opção simples (mas pouco atraente para a maioria) é usar uma biblioteca injetada para agrupar as chamadas open() e read() relevantes na interface libc, semelhante à solução para essa pergunta: Dynamic file content generation: Satisfazendo um 'arquivo aberto' por um 'execução de processo' . Se você agrupar open64() e organizar para armazenar em cache o descritor quando /dev/random for aberto, você poderá registrar o tamanho de cada read() .
Para ajudar a entrar na entropia, eu recomendo asciipacman ; -)