GnuPG PRNG insecure?

[Sam Roberts]

"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?

Thanks,
Sam


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
> >wrong.
> 
> 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 :-).
> 
> Peter.
> 
> 
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

-- 
Sam Roberts <sroberts at uniserve.com> (Vivez sans temps mort!)