Sandy Harris writes:
> Conclusions I've reached that I hope there's agreement on:
>
> More analysis is needed, especially in the area of how
> to estimate input entropy.
>
> (Yarrow does this quite differently than /dev/random.
> I'm not convinced either is right, but I've nothing
> else to propose. This is clearly a hard problem.)
It's really impossible to do it in general. What you can do is to come up
with a model for a particular entropy source, such as mouse movements or
disk timings, assuming the details are unknown to an attacker. But there
is no feasible algorithm which can be given a block of data and say how
much entropy is in it.
> There could be a serious weakness on a gateway machine.
> At a minimum, such machines should use the largest
> possible entropy pool (2K 32-bit words for current
> /dev/random) and enable all entropy sources.
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.
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.
> Yarrow's two-stage design, where the output from
> hashing the pool seeds a pseudo-random number
> generator based on a strong block cipher, offers
> significant advantages over the one-stage design
> in /dev/random which delivers hash results as
> output. In particular, it makes the hash harder
> to attack since its outputs are never directly
> seen, makes denial-of-service attacks based on
> depleting the generator nearly impossible, and
> "catastrophic reseeding" prevents iterative
> guessing attacks on generator internal state.
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.
> So possible actions are:
>
> 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.
> FreeS/WAN project should take steps in docs or
> scripts to ensure /dev/random is appropriately
> compiled on gateway systems.
Yes, but more to the point, it should not run if /dev/random does not
exist. In that case it would certainly be convenient to inform the user
of any potential problems at install time.
> /dev/random should become two-stage, preferably
> using an AES candidate cipher with 256-bit key,
> 128-bit block and reseeding operations which
> change at least 128 bits at a time.
The two-stage design, which is really just a matter of having a separate
entropy buffer so it doesn't come in too slowly, is designed to protect
against an attack where the PRNG state is snooped. No one has shown
a practical method for doing so which could not be easily extended to
weaken the RNG code.
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.
Here is an alternative proposed set of actions.
Emphasize the need to make gateway machines secure. These machines have
sensitive keys and other data in addition to RNG state. If an attacker
can get root privileges on your gateway, you have no security. This is
the most crucial element in the whole security setup.
Make sure the RNG in /dev/random is strong as a pseudo RNG, even with
no entropy being brought in. Most gateway machinse will be stand-alone
boxes without many events other than network events themselves, which
cannot be assumed to be unknown to an attacker. Entropy is likely to
be scarce in normal operation and the machine must run well without it.
Hence the PRNG behavior of the system (without entropy addition) is the
most crucial element for the analysis of its security.
Having settled both of those problems, then you can add an input entropy
buffer for the PRNG. Just bring input entropy into a hash context
(doesn't even need to be cryptographically strong), and dump that into
the entropy pool using the existing mechanisms when you have "enough".
It's probably less than 50 lines of code to add this, so you might as well
do it. But this is not a major addition to the security of your system.
The other elements above are far more important.
