GnuPG PRNG insecure?
sroberts at uniserve.com
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 cs.auckland.ac.nz>, 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
> 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
> 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 :-).
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
Sam Roberts <sroberts at uniserve.com> (Vivez sans temps mort!)
More information about the Gnupg-devel