David,
> so as I see this discussion it goes something like this.
>
> 1. the entropy pool is not large enough on headless machines.
> 2. you don't want to use urandom as there are theoretical attacks against
> it
>
> so as a result you propose adding an option to weaken random (network
> traffic is not that random which is a large part of why it's not included
> now)
An option, yes.
> you are trading one theoretical attack for another known attack (a
> difficult attack to pull off yes, but still known)
Not exactly, because to break /dev/random (with the config option on)
you have to (a) do the work that would have broken /dev/urandom, and
(b) break the translation of network traffic into entropy. If you
were using /dev/urandom only, you'd have to just do (a). IE if the
two alternatives are /dev/urandom, and /dev/random with Robert's
patch, the latter is certainly more secure (i.e. it's not a tradeoff).
> as for the arguments that applications all use random and would have to be
> changed to use urandom.
>
> don't forget that it's not the names that matter to the kernel it's the
> major/minor numbers. you can rename random to really.random and urandom to
> random and your software will not know the difference.
This is a fair point, but doesn't take into account the 'waiting for
sufficient entropy' point - which of course relies on network traffic
timing being sufficiently unobservable that it constitutes valid entropy.
> if you were arguing that the network traffic was truly random and that it
> should be added in as well that would be a different story, but you're not
> saying that you just don't want the incomvienience of blocking while
> waiting for truely random data but want to fool yourself into thinking
> that you are.
Well, I was arguing that network traffic was sufficiently unobservable
that it constitutes valid entropy under some circumstances, until I went
and read the code. It is so (it seems to me) on some i386 versions, where
the cycle clock is used. It is definitely not (and neither are any of
the other interrupt timings) where jiffies are used, for a start
because /proc/interrupts gives you the jiffie count (timer interrupts)
and the other interrupt counters simultaneously. So my argument is
that in some situations (where you know are happy with the extent
to which there is no observation of your wire locally), net IRQs
are no worse than the other sources of entropy, and sometimes they
are better (consider keyboards connected by radio). Obviously, in
cases like 802.11, they are substantially worse (and, no doubt, we
could omit Robert's patch from things like 802.11 drivers which
are obvious 'don't do that' cases).
-- Alex Bligh - 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:40 EST