Then add another factor to the equation, randomly pick the next event.
Consider if you would, gather entropy by choosing random bytes from
checksums from random packets. All the selection isn't technically
random but very uncontrolled. You start by picking a random packet
(seeded from existing entropy), and take a random byte from the checksum
of that packet. Using that byte, add it to the entropy pool and use it
to help determine the next 'random' packet you'll swipe data from.
An attacker would have to have absolute control over the packets
arriving at the machine to have a chance. He still cannot know exactly
which packets are chosen for entropy gathering being that the next
packet is chosen randomly from two or more entropy sources. Neither
will he know which byte(s) in the checksum are chosen.
In real world situations you should have a plentiful source of 'noise'.
The above idea can be improved upon significantly I'm sure.
David
Alex Bligh - linux-kernel wrote:
> Robert,
>
>> I claim there is entropy from what? The difference between interrupts
>> for net devices? Everyone agrees that there is. The issues is that an
>> external attacker could influence the interrupts to the net device, and
>
> ^^^^^^^^^
>
> Actually, to be fair, the true risk is more that an external attacker
> could
> /obvserve/ the timing of packets to the NIC with sufficient accuracy to
> predict the inter-IRQ timing, and hence the consequent manipulation of
> the pool. This would mean that entropy was being added, (assuming a
> system
> free of entropy to start with), eventually causing /dev/random not to
> block,
> and thus, short of any other entropy, the net effect would be that
> /dev/random would become exactly as good/bad a random number source
> as /dev/urandom. However, in most environments, it is not possible
> to observe and accurately (microseconds) time the packet coming into
> the NIC without physical access to the machine (in which case there
> are, urm, easier attacks), and there is a largely indeterminable latency
> between the arrival of the packet and the consequent network IRQ, this
> latency being neither externally visible, nor being determinable by
> some non-root user.
-
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:32 EST