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

[Philip Potter]

This is related to another current thread, but I think this deserves its
own.

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:

"While some safety margin above that minimum is reasonable, as a guard
against flaws in the CPRNG algorithm, no cryptographic primitive available
today can hope to promise more than 256 bits of security, so if any program
reads more than 256 bits (32 bytes) from the kernel random pool per
invocation, or per reasonable reseed interval (not less than one minute),
that should be taken as a sign that its cryptography is not skilfully
implemented."

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.

I am not an expert in cryptography, so I am in no position to pass
judgement on GPG or on /dev/random; however, it seems to me that GPG's
implementation disagrees with /dev/random's manpage.

Can anyone shed any light on this? Why does GPG use more entropy than
/dev/random says it should?

(I've written down these thoughts in more detail at
http://rhebus.posterous.com/why-does-gpg-need-so-much-entropy -- sadly,
this link will expire in a month when posterous shuts down)

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130331/c819d04e/attachment.html>