This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: draft random-number-generator API


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]