Sune Kirkeby <[EMAIL PROTECTED]> writes:
> (1) The article seems to imply that if a Bad Guy gets his hands on part
> or all of the output, further output from the same pool is less secure
> (it seems to be suitable for use internally in a program, where the
> generated random-ness is kept secret).
A related problem is as follows: Assume that that the attacker at some
point gets to the entire internal state of the pool. Next, a few bits
of entropy (say 20 bits) are added, and some more bits (say 32 bits)
are output. If the attacker observes the output, he can search for the
20 new input bits, and stay on track to the internal state.
> > There was also a thread about possible improvements to /dev/random on
> > the linux-ipsec list, perhaps ten months ago. IIRC, one of the
> > suggestions was to use a "pre-stage" pool, and add fairly large
> > amounts of entropy (say 64 or 128 bits) at a time to the pool that is
> > used for generating the output.=20
>
> Do you have a pointer? I am unable to find an archive of the list atm.
I'm including a summary posting below. Note that there was no
universal agreement, in particular I think Theodore challenged the
appearent statement of "consensus". I haven't been following that list
for a long time so I don't know if the subject has been discussed
again more recently.
> > Perhaps it would make sense to keep the entire entropy pool in the
> > kernel. One argument for that is that it should make it more difficult
> > to capture the internal state of the generator.
>
> There also seem to be reasons aginst doing so,
I think your arguments make sense.
> (1) Given proper process protection (locking in memory, disabling
> core-dumps, etc) it should be no easier to get at the internal state.
With the possibly exception of the "locking in core memory" solution.
I don't quite like that, it's too specialized. I'd prefer an encrypted
swap, where a process's stack and data pages are swapped using a
temporary key, which is destroyed on exec(). This is a pet idea I
have, but I haven't really looked into the details. Perhaps it's
trickier than I think.
Regards,
/Niels
: From: William Allen Simpson <[EMAIL PROTECTED]>
: Subject: linux-ipsec: semantics of /dev/{u}random
: To: "Theodore Y. Ts'o" <[EMAIL PROTECTED]>
: CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
: Date: Sun, 15 Aug 1999 10:00:01 -0400
: Message-ID: <[EMAIL PROTECTED]>
: References: <[EMAIL PROTECTED]>
:
: -----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-----
