[1519] in linux-security and linux-alert archive
[linux-security] Re: /dev/random and MAKEDEV-C-1.6
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Fri Apr 25 12:34:02 1997
Date: Fri, 25 Apr 1997 10:58:01 -0400
From: "Theodore Ts'o" <tytso@mit.edu>
To: linux-security@redhat.com
cc: linux-announce@stc06.ctd.ornl.gov
In-reply-to: David Holland's message of Thu, 24 Apr 1997 11:36:30 -0400 (EDT),
<199704241536.LAA32203@hcs.harvard.edu>
Resent-From: linux-security@redhat.com
Reply-To: linux-security@redhat.com
-----BEGIN PGP SIGNED MESSAGE-----
From: David Holland <dholland@hcs.harvard.edu>
Date: Thu, 24 Apr 1997 11:36:30 -0400 (EDT)
It has come to my attention that the recent 1.6 release of MAKEDEV-C
inadvertently created /dev/random and /dev/urandom with the wrong
permissions.
**** This has potentially serious security implications.
**** Unrestricted write access to /dev/random and /dev/urandom
**** makes them cryptographically worse than useless.
Sorry, but this simply isn't true. I wish someone had contacted me
before sending out the alarums to c.o.l.a. [ To the c.o.l.a. moderator,
if the alert has already been published, if you could send this out as
well, I'd be grateful.]
Writes to /dev/random and /dev/urandom are *mixed* into the entroy
pool. If you don't know the state of the pool before the write, you
don't know anything about the state of the pool after the write. We use
a complex (but invertible, so that no state is lost) mixing function
that involves the use of XOR and a twisted LFSR so that you get good
mixing even if you feed all zero's into /dev/random. A critical design
property of /dev/random's mixing algorithm is that even if the attacker
knows some of the values that are mixed into the pool, it doesn't
detract from the entry of the unknown values which are mixed in.
(To those of you who are wondering SHA is used only on the output side
of the random number generator, when we wish to extract random numbers.)
Also, note that writes to /dev/random do not increase the entropy count
of the pool, because of the possibility that an unprivileged attacker
might be mixing in known values to the pool. In this case, the entropy
will not increase, but neither does it increase either.
There is an ioctl() which you have to use if you want to increase the
entropy count, and this requires root access. This is for the
possibility of user-mode daemons that might sample /dev/audio, or some
such. Note that if you write such a daemon, you will need to do your
own analysis, (probably involving FFT's) in order to properly estimate
the amount of randomness in your /dev/audio input. (i.e., you need to
account for the non-random parts of the /dev/audio stream, such as that
which is attributable to the 60Hz or 50Hz hum.)
- Ted
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface
iQCVAwUBM2DGakQVcM1Ga0KJAQFtCAP9FDleE60dpk63kxUzwSwuvhPHVliWWXRd
hxBJRPiwm5kYqUPrryAPw/EpYwqMfYzcRoc9JYwB888OVDu8T6hLgjgwvNCfivQZ
jd6Z89K0G+Un7jxyLMqU1xdZeOVQVrx81nSX1av+cs0DfTal8Kf2RN6NkOdZ0w4U
GX92c2njDd8=
=MvzW
-----END PGP SIGNATURE-----
