bugtraq - Re: /dev/random is probably not

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 02 Jul 2005 16:56:51 +0900
From: Chiaki <ishikawa@...rim.or.jp>
To: bugtraq@...urityfocus.com
Cc: "Charles M. Hannum" <mycroft@...bsd.org>
Subject: 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@...tCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */