On Mon, Dec 07, 2009 at 11:58:02AM +0000, Rob OpenSuSE wrote:
I have taken an interest in Fate #306591 https://features.opensuse.org/306591 Andreas Jaeger has mused on community volunteer to package something. Now, I took a look at few suggestions, but 2 of them weren't "just work" in sense that they required webcam or mic, which seems like a possible can of worms to me.
So I wondered about using timing jitter from user space? As a prototype I've knocked up short piece of C, which uses calls :
nanosleep( &tsleep, 0); clock_gettime(CLOCK_REALTIME, &ttnow)
This has been tested on i686 Athlon MP & P4 (Celeron Willamette) and x86_64 Athlon 64 x2; and I do appear to get a useful amount of unpredictable bits from this, even if the raw timings are not random.
The timing jitter provides an externally unobservable measurement, and would allow sysadmin to tune to some extent eg) run 10 times/s (80bits/s) - 25 times/s (400bits/s).
If this sounds like a useful approach, then I'd propose to continue on and develop a small daemon which gathers entropy bits from timing unpredictabilities caused by scheduler & interrupts, and also periodically gathers extra entropy (especially on startup) borrowing from techniques uses in the perl egd daemon (which would need modifying in any case).
Obviously I'm a bit concerned about any move on power saving, this would obviously requires N wake ups, perhaps precautions would be needed to avoid them getting squeezed together by power saving patches which aim to batch up, code that sleeps like this?
Most of the stuff running in the system is not a good enough random source. Geting input from a true noise source would be more helpful, like from TPMs. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org