Messages in this thread | | | Date | Fri, 17 Aug 2001 16:56:03 -0600 | From | "D. Stimits" <> | Subject | Re: [PATCH] Optionally let Net Devices feed Entropy |
| |
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 - 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/
| |