building a true RNG

[Arnold G. Reinhold]

At 12:20 PM -0700 7/29/02, David Honig wrote:
>
>"Whether there is a need for very high bandwidth RNGs" was discussed
>on cypherpunks a few months ago, and no examples were found.
>(Unless you're using something like a one-time pad where you need
>a random bit for every cargo bit.)  Keeping in mind that
>a commerical crypto server can often accumulate entropy during
>off-peak hours. 
>

It's been discussed here some time back as well. If you believe your 
crypto primitives are infeasible to break, a crypto-based PRNG with a 
long enough random seed should be indistinguishable from a true, 
perfect RNG. If you are only confident that your crypto primitives 
are expensive to break, then using a true RNG for keys and nonces, 
rather than deriving them all from one PRNG, adds security.

This suggest a continuum of solutions: Construct a crypto PRNG and 
periodically (once enough has accumulated) stir your entropy source 
into it's state in some safe way. If you extract entropy slower than 
you put it in you can expect the equivalent of of a true RNG. If you 
extract entropy faster than you put it in, the system degrades 
gracefully in the sense that someone who expends the effort to break 
the number generation scheme only gets to read messages since the 
last entropy update.

The reason for batching entropy input is to prevent someone who has 
broken your system once from discovering each small entropy input by 
exhaustive search.  (There was a nice paper pointing this out in. If 
someone has the reference...)

Arnold Reinhold

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