Re: linux-ipsec: Re: semantics of /dev/{u}random

[Damien Miller]

On Wed, 18 Aug 1999, Arnold G. Reinhold wrote:

 Finally, I think thought should be given to the question of how to 
 use copious hardware random number generators on systems where they 
 are available. These could include on-chip RNGs, like the Pentium 
 III's, sound cards with noise input, HRNG boxes connected to a serial 
 or USB port, or even video cameras. I have located a number of 
 relatively inexpensive hardware RNG solution 
 (http://world.std.com/~reinhold/truenoise.html). I suspect they would 
 be used more if they were fully supported in the OS.
 
I have written a piece of software that may be of assistance here.

audio-entropyd periodically reads audio from a stereo soundcard and
feeds the difference between the left and right channels into 
/dev/random (via SHA1).

The time between reads, size of the input buffer, length of the hash 
and number of bits credited to the KRNG are all user configurable.

There is an alpha version at:

http://toad.ilogic.com.au/~dmiller/files/audio-entropyd-0.0.0.tar.gz

Regards,
Damien Miller

--
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.ilogic.com.au/~dmiller
| Email: [EMAIL PROTECTED] (home) -or- [EMAIL PROTECTED] (work)

semantics of /dev/{u}random

[William Allen Simpson]

-BEGIN PGP SIGNED MESSAGE-

Catching up, and after talking with John Kelsey and Sandy Harris at
SAC'99, it seems clear that there is some consensus on these lists that
the semantics of /dev/urandom need improvement, and that some principles
of Yarrow should be incorporated.  I think that most posters can be
satisfied by making the functionality of /dev/random and /dev/urandom
more orthogonal.

/dev/random would be essentially the same as today:
 * provide TRNG stream to kernel/system-wide processes
 * maintain entropy "accumulator" pool(s)
 * estimate "available" entropy
 * block when more requested than available

/dev/urandom would be updated:
 * provide PRNG stream to userland processes
 * counter mode
 * non-blocking
 * fast re-seed in smaller chunks periodically
 * slow re-seed in large chunks when TRNG is "full"
 * force ("explicit") re-seed function at critical times

By dividing the responsibilities, each can be better analysed, and
future changes made without disturbing applications.

There does not seem to be consensus whether to limit /dev/random to
"rw---", as this might affect current applications.  I think that
we should bite the bullet, and make this change, to make future changes
more clean and prevent "entropy exhaustion" attacks from userland.
Consider this as a security bug fix for a known attack.

I suggest that fast re-seed occur when estimated new entropy (since last
fast re-seed) from all sources is 128-bits, but that only 64 bits be
used.  This is different than Yarrow-160, as a concession to the
blocking nature of /dev/random.  Leaving half the entropy will allow a
build-up to the slow re-seed, and accomodate other uses of /dev/random.

I suggest that slow re-seed occur when estimated new entropy (since last
slow re-seed) from all sources is 320-bits, with at least TWO sources of
160-bits each (see Yarrow-160 section 5.4), but that only 160 bits be
used.

I suggest that the force re-seed function be rewind(), and that only
min( available-bits/2, 64-bits ) be used, counting as a fast re-seed.

The re-seed threshholds probably have to be implemented in /dev/random,
requiring a close coupling with /dev/urandom.  But as long as the
defined semantics are clearly delineated, details can more easily be
changed transparently.

-BEGIN PGP SIGNATURE-
Version: PGP 6.5.1

iQCVAwUBN7bHjtm/qMj6R+sxAQH9iQP/bLCHCV5LrkehICGQzoGchC8lB0OL6lRC
Ut4uDxUZ6/zGSP4nAnwE3MqPuNOf2R16y90CR6LwsF9kPI9yr90SbCJL/aaJsXI7
xilXSdYAyatfZd3ETWzBmuYwdG63Gchxu6v2xU7NqVPIvy9q1Xz8hhaAFEFgCmml
Ee0RCu12bDw=
=4XF/
-END PGP SIGNATURE-