On Mon, Jun 12, 2000 at 07:04:33AM +0900, OKUJI Yoshinori wrote:
> From: Sune Kirkeby <[EMAIL PROTECTED]>
> Subject: entropy-0.2 [Was: Re: /dev/{,u}random driver]
> Date: Sun, 11 Jun 2000 20:53:09 +0200
>
> > There is one thing with the implementation that bothers me, though. The
> > data is hashed both by egd and by my entropy translator, which seems a
> > bit wasteful of cycles...
>
> I think it would be better to convert egd to a translator and
> replace it with your entropy translator. That should simplify your
> implementation and you will lose nothing.
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 have just uploaded a new version of the entropy translator, with the
> > egd-glue program mentioned. So, now there is a completely user-space
> > /dev/{,u}random driver for the Hurd.
>
> I appreciate your work very much. It will be a starting point for
> some programs which require a random device.
>
> However, I hope that someone will work on a kernel-space random
> device driver, because it should be less predictable.
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.
Does that sound like a sensible and doeable way to go, or were you
thinking of an entirely in-kernel driver?
--
Sune Kirkeby | "Imagine, if you will, that there were no such
| thing as a hypothetical situation..."
PGP signature
