EDP (entropy distribution protocol), userland PRNG design

[Travis H.]

> I can't say I a fan of the idea of having multiple ways of mixing entropy into
> the system. In particular, the idea of producing output by XORing your PRNGs
> output with the output of a semi-public RNG seems like a bad idea to me,
> because an attacker can easily control those values by taking over the web
> server or modifying packets in the network, and if they can somehow predict
> your PRNG outputs then they will be able to actually control the final output.

Is it that XOR is too simple?  That is, if I used a "secure mixing
function" (RFC 1750), perhaps a OWF, would this solve the problem? 
Then an attacker couldn't find a preimage that would produce a chosen
output.

>  source(s) --> mixer --> pool --> extractor --> X9.31

I would think you'd want to use an extractor* on the sources before
they get commingled with other stuff.  Of course the extractor
operates on two sources (one weakly random, the other uniformly
random) to generate nearly-uniform values, so it is doing a kind of
mixing of streams.  However, the output of the PRNG subsystem could be
fed back as the "uniformly random" input probably.  Of course you'd
need a good seed to bootstrap the whole thing.

[*] mathematics sense of the word: http://en.wikipedia.org/wiki/Extractor

One good reason to do some randomness work outside the kernel is you
can't do floating point in most Unix kernels, so if you're computing
chi-square or some other statistic, you've either got to convert it to
integer math or do it outside the kernel.

On the down side, you've got scheduler delays adding to the latency of
each request.

> I believe most common hardware RNGs produce data at fairly high rates, often

I don't trust most of those sources to generate non-correlated bits at
high rates.

You know, the designs where they latch the output of oscillators based
on some signal with random jitter is kind of like performing a modulo
operation.  Some information is thrown away in a many-to-one mapping,
I wonder if you could gain something by modeling the jitter
measurement before it is used to latch the output of the oscillator. 
It'd be like knowing g^x prior to modular reduction (mod n) in
Diffie-Hellman.

> You could also just solve the problem you mention directly, and try to find a
> cheaper HWRNG design. I know people who have built them for a few dollars

Terry Ritter has a lot of designs like this:
http://www.ciphersbyritter.com/NOISE/NOISRC.HTM

I'd like a system that is elegant and simple for harnessing,
purifying, and securely stretching such values.  By elegant and
simple, what I mean is that it obviously has no weaknesses, as opposed
to having no obvious weaknesses.
--
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com