Sune Kirkeby <[EMAIL PROTECTED]> writes:
> True, but currently the egd source seems messy to me, which was a real
> turn-off for me, that and learning more Hurd programming this way made
> the choice an easy one. So, there are not really any technical
> reasons speaking for my current implementation.
I would recommend anybody hacking on /dev/random or egd like programs
to also read Peter Gutmann's article titled "Generating practically
secure randomness" or some such. Although it is aimed at user level
programs, I think the pool management he describes is good reading no
matter where the implementation lives.
There was also a thread about possible improvements to /dev/random on
the linux-ipsec list, perhaps ten months ago. IIRC, one of the
suggestions was to use a "pre-stage" pool, and add fairly large
amounts of entropy (say 64 or 128 bits) at a time to the pool that is
used for generating the output.
> I was thinking of implementing only the bare-bones in-kernel, probably
> just providing the raw data (inter-interrupt timings, etc) to
> priviledged user-space processes. Then it should be a simple matter to
> make my current implementation grab it's input from the kernel.
Perhaps it would make sense to keep the entire entropy pool in the
kernel. One argument for that is that it should make it more difficult
to capture the internal state of the generator.
/Niels
