-----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-----

Reply via email to