GnuPG PRNG insecure?

Sam Roberts sroberts at
Sat Feb 9 01:33:02 CET 2002

"just for the record, it does XOR the data"

I guess I'm missing something, too, because it certainly looks to me
like new data is assigned over data already in the pool, and my
understanding was XORing known values into a pool could not DECREASE
the entropy in the pool, but assigning seems to mean you'll lose some
of the current contents of the pool.

What am I missing, where's the XOR occuring?


Quoting Peter Gutmann <pgut001 at>, who wrote:
> >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
> >wrong.
> It's a pretty accurate analysis.  The flaw is worrying, but not fatal, since
> (assuming it accurately implements the design in
> 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
>    attacks */
> 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 :-).
> Peter.
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at

Sam Roberts <sroberts at> (Vivez sans temps mort!)

More information about the Gnupg-devel mailing list