On Fri, Aug 17, 2001 at 03:05:39PM -0700, David Schwartz wrote:
> > That's not the only attack, actually. The much simpler attack pathis
> > for an attack to **observe** the network traffic to such a precise
> > extent as to be able to guess what the entropy numbers are that are
> > going into the pool. (Think: FBI's Carnivore).
>
>
> This is a non-issue providing the entropy pool code correctly
> estimates the amount of entropy. The Linux entropy code is written
> so that there is no harm from putting fully known or partially known
> numbers into the pool provided that the pool does not overestimate
> the amount of entropy in those numbers.
Err, yes, I know that....
The problem is that by being able to perfectly observe packets on the
LAN, you know a lot more about the numbers that are going in, and it's
therefore extremely likely that the entropy estimate will be
overestimated.
> Even if you could perfectly time the packets on the LAN, you
> still could not tell the clock skew between the clock on the LAN
> card and the TSC. There would still be unknowns involving how long
> it would take for the interrupt to be acknowledged and the entropy
> gathering code to get to the CPU. These unknowns still contain real
> entropy that there is no known way an attacker could know.
Yes, but the problem is that the entropy estimation code needs to
differentiate between the differences caused by packet (which is
observable by an outsider), and differenences caused by interrupt
timings, etc. At the moment, it doesn't do this at all.
Also, the clock skew between the TSC and the LAN card has only two
components. One is the actual clock frequency on the CPU, and the
other is a fixed offset (roughly based on when the system was booted).
So to an determined adversary, the amount of randomness this adds is a
fixed constant, and not something which changes each time entropy is
sampled. Also, it wouldn't surprise me if a determined adversary
(read: NSA) wouldn't be able to come up with statistical models of
interrupts response times for Linux such that the amount of entropy
that you can dependably rely on is less than you might think.
The bottom line is it really depends on how paranoid you want to be,
and how much and how closely you want /dev/random to reliably replace
a true hardware random number generator which relies on some physical
process (by measuring quantum noise using a noise diode, or by
measuring radioactive decay). For most purposes, and against most
adversaries, it's probably acceptable to depend on network interrupts,
even if the entropy estimator may be overestimating things.
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:31 EST