Why does gpg use so much entropy from /dev/random?

Hauke Laging mailinglisten at hauke-laging.de
Sun Mar 31 19:33:19 CEST 2013

Am So 31.03.2013, 10:45:54 schrieb Philip Potter:

> GPG uses /dev/random as its entropy source. It pulls a lot of entropy from
> this source. More entropy, in fact, than the linux /dev/random manpage
> suggests it should. Quoting from the manpage:

I don't know the gpg source, the following (3) is just a guess.

> Recently when generating a 2048-bit key, I got a message that GPG needed
> 280 *bytes* more entropy. This is far more than 256 bits.

1) If you don't do anything special then two keys are generated (mainkey and 

2) A 2048 bit RSA key is supposed to be as secure as a 112 bit symmetric key. 
I don't know whether you can map a 112 bit symmetric key directly to RSA key 
values. You need find primes after all. Maybe the algorithm to do that 
consumes additional entropy.

3) Who knows how random the /dev/random output really is? I guess that the 
entropy quality can be increased by consuming more ("make one good bit from 16 
bad bits").

strace -e trace=open,read gpg --armor --gen-random 0 16
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\332\376J\314\1[\357\n7ee\303\372\3555h", 16) = 16

strace -e trace=open,read gpg --armor --gen-random 1 16
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\3471=\307+n\3656\204\31!\232\270\303\324[", 16) = 16

(Strange. Werner, have I found a bug? :-)  )

strace -e trace=open,read gpg --armor --gen-random 2 16
open("/dev/random", O_RDONLY)           = 4
read(4, "\1\362P\231..."..., 300) = 128
read(4, "+7m\2314|\353..."..., 172) = 128
read(4, "\233\272~\237\..."..., 44) = 44

So we see: If high quality entropy is required then gpg reads 
(128+128+44)/16=18.75 times as much entropy from /dev/random as demanded.

PGP: 7D82 FB9F D25A 2CE4 5241 6C37 BF4B 8EEF 1A57 1DF5 (seit 2012-11-04)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 572 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20130331/a8a87c8c/attachment.sig>

More information about the Gnupg-users mailing list