GnuPG PRNG insecure?
pgut001 at cs.auckland.ac.nz
Fri Feb 8 07:13:01 CET 2002
>Recently, out of curiosity, I looked at GnuPG's random number generation and
>stumbled across something I think is problematic. However, I'm not a
>cryptographer, nor do I have in-depth knowledge on cryptographic secure pseudo
>random number generation. That's why I ask people here to comment on this. So
>read this with care; any or all of the things presented herein may be totally
It's a pretty accurate analysis. The flaw is worrying, but not fatal, since
(assuming it accurately implements the design in
http://www.cryptoapps.com/~peter/06_random.pdf) the output is only taken from
the mixed input of a significant portion of the pool, ie 640 bits of pool data
are used for each output block.
However, if user seeding is allowed it's a bit more problematic since an
attacker can overwrite the pool contents with known values. The original
implementation has the comment:
/* Mix the incoming data into the pool. This operation is resistant
to chosen- and known-input attacks because the pool contents are
unknown to an attacker, so XOR'ing in known data won't help them.
In an attacker could determine pool contents by observing the
generator output (which is defeated by the postprocessing), we'd
have to perform an extra input mixing operation to defeat these
which addresses chosen/known-input attacks (and just for the record, it does
XOR the data :-). Without the XOR, you don't have these guarantees. Since GPG
doesn't allow outside control of the seeding, this isn't a big problem, but
it's still something which should be fixed.
Incidentally, this bug is identical to the PGP 2.x xorbytes bug, a web search
for that name will find further discussion on this topic. I think copying
xorbytes is taking GPG's PGP compatibility a bit far :-).
More information about the Gnupg-devel