This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: draft random-number-generator API
- To: tb@mit.edu (Thomas Bushnell, BSG)
- Subject: Re: draft random-number-generator API
- From: Zack Weinberg <zack@rabi.phys.columbia.edu>
- Date: Thu, 03 Sep 1998 20:31:27 -0400
- cc: libc-hacker@cygnus.com
On Thu, 3 Sep 1998 19:33:37 -0400, Thomas Bushnell, BSG wrote:
> Date: Thu, 03 Sep 1998 18:36:26 -0400
> From: Zack Weinberg <zack@rabi.phys.columbia.edu>
>
> You create a state block with another function, which takes a selector for
> the algorithm, an initial seed, and any tunable parameters. It returns you
> a pointer to malloced memory. You can reseed the block with yet another
> function, or set the default state block to one of your choosing.
>
>I would like it also to have an interface to take bits of randomness
>and cycle them into the function in the Right Way. Various system's
>/dev/random does this right; look in their kernels and read the papers
>to understand it (I did that once, but could not reproduce the answer
>here).
This is interesting but may not fit.
/dev/random usually works by maintaining an 'entropy pool'. Events that are
supposed to be "truly random" - often the time difference between external
interrupts (disk, keyboard, etc.) - contribute entropy to the pool. You
extract randomness by passing the pool through a cryptographically strong
hash function (e.g. SHA). There's a bunch of feedback stuff to prevent
someone from draining the pool.
What I think you're asking for - correct me if I'm wrong - is a function to
'contribute entropy' to a RNG's state. It would be like srand() but would
just perturb the RNG not reset it. There's a problem, though: I think
unless the RNG is designed to allow this, perturbing its state may *reduce*
its randomness. I could be wrong, I know very little of number theory.
zw