[PYTHON-CRYPTO] CSPRNG schemes : Any comments?

[Bryan Mongeau]

> So it SourceForge accepting crypto projects these days?  Last I
> checked, it was not allowed.

Arg! American export restrictions are such a pain, thanks for the reminder. I
couldn't find any docs on the site concerning this policy, so I submitted my
project anyway. Lo and behold, it was accepted, so either it was okay, or
they didn't read the words "crypto" and "AES" in the title. Nevertheless, I
posted a msg in the open forum, we'll see what develops. A quick search for
"crypto" seems to turn up many, many projects though...

> BTW, there is a Yarrow-160 implementation included in Pisces at
> http://www.cnri.reston.va.us/software/pisces

Thanks. I've been playing with Pisces for a few weeks now, my main interests
being the PKCS routines. I liked it, especially the documentation, and if it
weren't for the underlying OpenSSL dependency, I would have used it.  You
also reminded me your class is named EntropyPool as well. Whoops. I will
change the name of my CSPRNG in the next release to avoid any confusion.

As for your Yarrow-160 implementation, I examined and tested it, but
ultimately needed more entropy than it could provide. But I did have a few
questions I would like to bounce off you now that we're on that topic, if you
don't mind. These popped into my mind this morning:

1- Why doesn't anyone use a block cipher in CBC mode to make things even more
funky in the random pools? The initialization vector could be a hash slice of
a given entropy pool... The Yarrow specs uses 3des in counter mode, you use
ECB.

2- I noticed in the Yarrow 160 spec section 4.2 that entropy sources are
closely tied to a given pool, be it the fast or slow to prevent bogus entropy
sources from reseeding the PRNG continously. However, in the addSource()
method, you add an entropy source to both pools. Additionally, the addInput()
method alternates between pools, effectively leaving the PRNG open to an
iterative guessing attack should one entropy source be vastly overestimating
its contribution. Also the slowIntoFast() method calls addInput() which has a
50% chance of adding the slow pool to the slow pool... As AMK would say, it's
a Bad Thing. :)  Am I missing something here?

Don't get me wrong, I don't think your implementation is insecure in any way.
In fact I believe it to be quasi unbreakable.  I simply have issues with
Yarrow and its rigid implementation. Entropy collection routines are fine if
you're running a daemon or an entropy server that is given a period of time
to accumulate sufficient entropy, but most applications require entropy on
demand. Take for example pgp keygen that prompts you to pound the keyboard
until it's got enough randomness. Effective granted, but crude.

Here is a theory I would appreciate salient commentary on:

I take a different approach that uses thread scheduling to generate massively
parallel race conditions that operate on a common buffer.  I use this thread
entropy to add events to a Yarrow-esque pool on the fly and on demand.

This mechanism was posted to sci.crypt and the response was (expectedly)
harsh. The primary arguments raised were that the thread scheduler is a
deterministic algorithm thus cannot produce entropy and that an attacker
could cause system load to be unusually high which would result in more
deterministic scheduling.

My defense lies partly in python's GIL, which by default is acquired and
released every 10 cycles (I believe). This constant acquisition and release
process, in conjunction with the other system processes, has an effect of
making *all* system activities ( keyboard hits, mouse movements, disk and
network I/O, running hardware drivers, other processes running, etc.)
influence the overall outcome of the thread race. Iterate the algorithm for a
given number of rounds, and you have effectively created an PRNG scheme that
encompasses all the other methods of entropy accumulation.

So far this defense has met with little acceptance, but this is to be
expected in the crypto field. After all, most cryptographers will still
blindly choose RSA over Elliptic Curves simply because they feel safer all
sticking together, even though ECC is ten times as fast and has a key size
that increases exponentially in security. For example, 160 bit ECC is
equivalent to 1024 bit RSA whereas 256 bit ECC roughly equates to 4096 bits
in RSA.

I feel Yarrow has somewhat cornered the CSPRNG market in the same fashion.

I welcome the list's comments on my thoughts and opinions.

Regards,
--
<==================================>
Bryan Mongeau
Lead Developer, Director
eEvolved Real-Time Technologies Inc.
http://www.eevolved.com
<==================================>

"The universe we observe has precisely the properties we should expect if
there is, at bottom, no design, no purpose, no evil and no good, nothing but
blind pitiless indifference." -- Richard Dawkins