Re: /dev/random is probably not
Charles M. Hannum wrote:
Most implementations of /dev/random (or so-called "entropy gathering daemons")
rely on disk I/O timings as a primary source of randomness. This is based on
a CRYPTO '94 paper[1] that analyzed randomness from air turbulence inside the
drive case.
I would agree with the later analysis posted, but
what OSs use disk I/O timing only for /dev/{u,}random device
today?
- Linux? (I don't think so, If we have network and other I/O device
such as keyboard, I thought that would be used, too.
but I want confirmation from people in the know.)
- Solaris (I don't think so with the latest Solaris (7,8,9,10).
I read somewhere (probably here on bugtraq) that
it uses ever changing OS internal data structure and memory
pool as the partial source of entropy.
But again, I want confirmation from
someone who has seen, say, OpenSolaris source code.)
This leaves
OpenBSD, FreeBSD, NetBSD and the like, and of course
Windows family OSs.
People in the know may want to add comment about the
latter OSs.
My tenet is that two OSs that I use often, linux and solaris,
are free from the worry mentioned.
(When I think about it, I am not sure what Windows does
for random number generation.)
Looong time ago, SSH used to contain a so called
entropy gathering daemons that would run various simple
commands and use the output from these programs to
obtain quasi-random numbers by running the output
after hashing. But even then, they used
output not solely depending on the disk I/O randomness.
(system load, and bunch of other stuff. Granted, they
remain relatively constant on a non-busy system, but
they fluctuate enough for practical purposes.)
On a pre-solaris 7, I used this as "poor man's /dev/random".
One of these days, on desktop PCs,
we could add the reading of diode used for measuring
CPU temperature to the mix of
entropy source. (Of course, we need a good source of
`entropy' to begin with, and adding another source such
as diode is a good thing IMHO.)
And maybe the fan rotation/speed, too. I found that
they change constantly on my PC!
Some of these CPU-bound devices may have
implications when we have a dual core CPU.
Reading of such device by one thread may be
highly predictable by another thread running on the
CPU chip.
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */