On Sun, 1 Aug 1999, bram wrote:
> On Mon, 2 Aug 1999, Anonymous wrote:
>
> > Disagree. /dev/random in cryptographic mode should be adequate as long
> > as the machine is secured. If the machine is attacked to grab PRNG
> > state the attacker can probably weaken the code.
>
> No, /dev/random's propensity to block can be unacceptable, especially for
> machines which don't have a source of entropy available.
Which is why /dev/urandom is provided. The newer random drivers also
offer an entropy count (accessible through /proc).
This is a policy decision - do we want a failure mode where the software
shuts down (entropy exhaustion on /dev/random) or continues operating
with reduced security (/dev/urandom).
> > If the gateway machine is vulnerable to attacks which get root access,
> > that is a serious weakness, but no work on the RNG can fix it. If not,
> > then any decent cryptographically strong PRNG is fully adequate.
> > No one has shown any value whatsoever for large entropy pools in this
> > circumstance.
>
> Right now, everything which collects entropy has to be run as root or in
> the kernal, which is uncomfortable from a security standpoint.
It currently has to be in the kernel. IIRC bytes written to /dev/random
are hashed into the entropy pool but not credited to the entropy count.
I have asked for a means to say "please add these bytes to the pool
and increment the entropy counter", but have received not response.
> I disagree that bad entropy attacks are unrealistic - if a machine is
> running several different sources of entropy, getting information from god
> knows what source, it's quite possible one of them could be made by
> external forces to start spewing controlled data into the pool, and if you
> have a machine which, for example, is running a web server which isn't
> being hit by anyone but the attacker, and that web server is the only
> thing reading data out of /dev/random, suddenly an attack looks quite
> possible.
There attacks require the attacker to either know the current state of
the pool or to reverse SHA1.
> This is especially true for possible future sources of entropy where, for
> example, some sysadmin might figure 'I'll just spew the traffic logs into
> /dev/random, it's the only source of randomness I have, and it's pretty
> random.' As things stand, that would leave the system much more wide-open
> than it would have to be.
There is still the entropy from things like disk interrupt timings, as
well as the state collected during boot.
> > Yarrow does not use a block cipher. In PRNG mode, it is simply an
> > iterated SHA-1 hash, with the hash output provided as the RNG output.
> > It hashes a 20-byte seed, then hashes the previous 20 bytes of output
> > to get the new 20 bytes of output. Every so often it updates the seed
> > to be a new hash output value.
>
> That isn't quite accurate, but the basic point is that Yarrow is based on
> a hash algorithm as a primitive, and any hash algorithm could be
> substituted in there. Further work on figuring out what core trickery
> should be at the heart of the randomness source is unnecessary, especially
> since other work on the same problem has come up with essentially the same
> algorithm.
The random driver already uses SHA1, but it doesn't do the bulk reseeding
that Yarrow does.
> > > Continue discussions on cryptography list,
> > > focussing on the hardest problem: acquiring and
> > > estimating entropy.
> >
> > This may be the hardest problem, but it is not the most important one,
> > especially not for FreeS/WAN use. Mis-estimates of entropy are not crucial
> > for this purpose. FreeS/WAN does not need "true" entropy and the current
> > design of /dev/random does a soft fallback from true RNG to pseudo RNG,
> > which is perfect for FreeS/WAN.
>
> No, this is actually the biggest gaping hole in the entire system - if the
> randomness source starts spewing after only getting 40 bits of entropy
> then it's wide open to attack, regardless of how much whitening it does on
> the output.
Good point - it makes sense to modify the random driver to not output
until a lower bound of entropy has been collected.
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)
