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]
Message-ID: <42C648C3.5000301@yk.rim.or.jp>
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 */


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ