[PYTHON-CRYPTO] CSPRNG schemes : Any comments?

[PC Drew]

--On Thursday, February 15, 2001 6:15 AM -0500 Bryan Mongeau
<bryan at EEVOLVED.COM> wrote:

>> 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...
>

If that's a problem, does anyone on this list have a machine that they
could give people SSH access to?  Is there any way we could get something
like this?  Or, since the export restrictions have been relaxed...does
anyone know what the law says about all of this?  I read some of the law,
but like every other stupid law, I didn't understand it.

> 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.
>

I looked again, but couldn't find the exact text in the Yarrow spec, but it
mentioned accumulating entropy from places that have nothing to do with
each other.  To me, that means pick enough entropy sources such that an
attacker couldn't possibly affect each and every one of them at the same
time (or over a given period of time) enough so that it he would be able to
dictate the pseudo random output.  For instance, why not accumulate entropy
from thread scheduling (as you mentioned above), time, networking packets,
process ids, keyboard input, mouse movement, etc?

> 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.
>

Well yeah, we're looking for random input for a random number generator!!
At some point, we're going to have to use data from some deterministic
algorithm in order to create our random numbers!

> 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.
>

woah.  Sorry, had to re-read that a few times :)

> 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.
>

That's why we need to support all of these...so that software engineers can
make their own decisions and not be cornered into one area just because we
didn't implement RSA or something.

--
PC Drew

  Be nice or I'll replace you with a very
  small shell script.