Entropy-gathering gizmos for Solaris? (fwd)

[Damien Miller]

For those wondering about the Solaris random driver.

-- 
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work)



---------- Forwarded message ----------
Date: Wed, 19 Apr 2000 16:24:57 -0400
From: Don Davis <dtd at world.std.com>
To: Jeff.Hodges at stanford.edu
Cc: cryptography at c2.net, dtd at world.std.com, soley at sun.com
Subject: Re: Entropy-gathering gizmos for Solaris?

> Ok, now I'm curious about what all entropy-gathering gizmos, ...
> might be available for/on Solaris -- anyone know?

the solaris security toolkit has a program called cryptorand.
about 3-4 years ago, i intensively reviewed and tested crypto-
rand for a client.  i talked a lot back then with bill soley,
the sunsoft engineer who designed and wrote cryptorand, and
bill gave me a lot of detail about how the program worked.
because i've worked on true RNGs myself, i was very interested
in bill's approach.

cryptorand is an application program that reads kernel memory
pages from kmem, hashes the pages into an entropy pool, and
exports the pool's bits via a pseudo-device driver.  crypto-
rand is careful to skip a page if the page hasn't changed
since the last time it was examined.  the program also saves
its entropy pool to disk on shutdown, so that the program is
sure to have a different starting state at every reboot.  bill
was very conservative about not publushing too many bits, and
about rejecting pages that might not have changed.

i found that cryptorand could produce kbytes of key-quality
bits per second, and that it was pretty efficient.  when i
pulled bits out as fast as possible, while a web server was
answering http requests on the same machine, i saw a ~5%
reduction in the web-server's throughput.  i concluded that
this 5% hit really came not from cpu load, but from memory-
bus contention.  anyway, the test was perhaps not perfectly
realistic, because a server wouldn't need to pull bits out
as fast as i did.  i also did some statistical testing of
cryptorand's output, though this was unnecessary; cryptorand
uses md5, which is well-known to produce white noise.  finally,
i disabled crypto-rand's state-saving feature, and rebooted
the machine a few hundred times, saving cryptorand's first
few bytes from each reboot.  i then checked these initial
bytes for entropy and for correlations, and found no problems.

here's why i believe it's reasonable to say that cryptorand's
output qualifies as true entropy.  at boot time, the unix
kernel's memory comprises several tables, most of which are
set up as linked lists of control structures, waiting to be
allocated.  in use, these structures are extensively cross-
linked to one another with pointer spaghetti.  when a table
element is freed, it is added to the top of its table's free
list, so that the free-list is shuffled by the kernel's activ-
ity.  since the kernel's activity is strongly i/o-driven, the
kernel's history of i/o timing is recorded in the particular
tangle of pointer spaghetti, in both the active table struc-
tures and in the free-lists.

btw, i got bill's permission to send these comments to the
list.

					- don davis, boston
					  http://world.std.com/~dtd






-