On Mon, Jun 12, 2000 at 06:37:14PM +0200, Niels M�ller wrote:
> 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.
Disclaimer: although I read the article, it was rather late at night
for me, and I only took a cursory glance at the latter parts of it.
What follows might thusly be variations on the truth, or entirely wrong.
There are a few things about the article that (although it was
interesting reading) make me think his entropy pool is less suited for
/dev/random driver purposes than the original Linux driver:
(1) The article seems to imply that if a Bad Guy gets his hands on part
or all of the output, further output from the same pool is less secure
(it seems to be suitable for use internally in a program, where the
generated random-ness is kept secret).
(2) The original Linux /dev/random driver is specifically mentioned,
w/o any obvious (to me) criticism, so reusing the code from there in a
Hurdish way seems to be the easiest thing to do.
> 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.
Do you have a pointer? I am unable to find an archive of the list atm.
On Mon, Jun 12, 2000 at 06:37:14PM +0200, Niels M�ller wrote:
> Sune Kirkeby <[EMAIL PROTECTED]> writes:
> > 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.
There also seem to be reasons aginst doing so,
(1) Given proper process protection (locking in memory, disabling
core-dumps, etc) it should be no easier to get at the internal state.
(2) It will most probably require adding character-devices to the
kernel, which is a lot more work than just adding a Mach device.
(3) In user-space we can experiment with pre-stage pools, using an FPU
for calculations (can the kernel do this?) and getting real random-ness
from real-world entropy (PCI boards with radioactive isotopos, anyone?).
(4) It's not very micro-kernel-ish (tm).
Regards,
--
Sune Kirkeby | "Imagine, if you will, that there were no such
| thing as a hypothetical situation..."
PGP signature
