Re: [PATCH] let Net Devices feed Entropy, updated (1/2)

[David Ford <david@blue-labs.org>]

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.