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.
> 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.
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.
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.
> 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.
> > 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.
> The iterative guessing attack is being overstated here in terms of its
> practical significance. The root privileges which are necessary to snoop
> the RNG state will also allow for more malicious actions that completely
> compromise security.
The way to diddle with RNG state is to mess with it's sources, not by
directly looking inside the state. Attacks of that form, even if they
aren't 'practical' now, could easily become practical in the future.
-Bram
