Re: [PATCH] Optionally let Net Devices feed Entropy

["D. Stimits" <stimits@idcomm.com>]

Robert Love wrote:
> 
> On 16 Aug 2001 14:19:57 -0600, D. Stimits wrote:
> > It would be interesting if an option were possible for entropy pool via
> > loopback traffic.
> 
> is that humor? :)

To a large degree, yes (but now that I think about it, not
entirely...speculation is dangerous to one's sanity).

> 
> it can certainly generate a large amount of entropy if you let it.
> 
> but the general mechanism for grabbing entropy from char/net devices is
> measuring values from their interrupt timings.  this is done via a flag
> value in request_irq.
> 
> loopback has no interrupts thus no request_irq

After hearing about all of the possible ways of sniffing keyboards, I
have to wonder how hard it would be to create an irq sniffing device to
aid monitoring (like the keyboard device, planted directly in the
computer being monitored, though I suppose once you have the keystrokes
it is a moot point). Then there are also all those wireless mice and
keyboards, which could possibly broadcast useful information about irq
(although knowing the exact time between irq's can only be estimated
without actually tapping straight into the motherboard hardware); there
is no reason to stop at simply monitoring keystrokes (would remote
monitoring of wireless devices offer *useful* info on irq timings?).

I noticed add_timer_randomness depends on time between events, and that
it isn't necessarily irq that matters; but irq is most likely the least
predictable event to use, and nobody has bothered to implement any other
random timing source to feed the function. Something else might be used
as a substitute, e.g., perhaps the temperature monitor on a cpu could be
used to modify a moving snapshot of loopback traffic. I don't know if
the raw data from cpu temperature monitoring is available with
sufficient precision (without regard to the accuracy of the value) to
count on it as a source of "environment noise" that in turn, during
change, can be used to trigger the equivalent of random timing. Some of
the hardware crypto devices seem to use diode noise (which can make a
nice microwave generator as well), perhaps temperature monitoring could
be used for a lower quality version; instead of simply passing the
timing of rising and falling peaks/valleys (since it wouldn't be as
rapid or random as a diode noise generator), one could use that timing
in conjunction with a hash on a sliding window of loopback traffic bytes
(or even to act as a coefficient, and not just a timing trigger).

The general weakness with irq seems to be that (a) it isn't always
occurring at a sufficient rate in systems without mouse/keyboard (and
worse on diskless sytems), and (b) there is some very minor possibility
that outside monitoring or influence can sway the pool or provide help
to crackers (the tech to do this usefully doesn't seem to exist right
now, but I wouldn't bet on it staying that way). Loopback is probably
one of the largest sources of byte traffic, is not subject to irq
monitoring, and does not fall down on the job for
mouseless/keyboardless/headless/diskless stations. What it lacks is a
truly random way of using the traffic; supposing something like
temperature monitoring could be found as an alternate timing device (in
place of irq), loopback could be used (or if any event that occurs in
relation to loopback is random in the way that irq is, some other
alternate timing event could be used). Does anyone happen to know
exactly how much "noise" could be extracted from hardware temperature
monitors (would it be practical)?

D. Stimits, stimits@idcomm.com

> 
> --
> Robert M. Love
> rml at ufl.edu
> rml at tech9.net