[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
|
|
Subscribe / Log in / New account

Getting more entropy

Getting more entropy

Posted Oct 10, 2010 11:55 UTC (Sun) by kleptog (subscriber, #1183)
In reply to: bogus random entropy sources by nix
Parent article: Solid-state storage devices and the block layer

A while back just for the fun of it I wrote a kernel driver whose goal was to extract entropy from the timer interrupt. After all, if anything is predictable, then it'd have to be the timer interrupt.

The point is that while the interrupt is predictable, between the time that the interrupt fires and the driver finally gets run you have cache misses at various levels, PCI bus transfers, DRAM refresh cycles and even just hyperthreading making things very unpredictable. Conclusion: if there's predictability here, I couldn't find it (there's a toolkit for estimating randomness, it concluded that the output was indistinguishable from real random data).

The basic idea was to just use the last few bits of the cycle counter, don't worry about the high order bits. The last bit was enough, but even taking the last four bits didn't show any patterns. It might be worth making such a driver for the purpose of giving otherwise entropy starved machines something to work with. I imagine within VMs the cycle counter becomes even more variable, due to contention with things outside the VM.


to post comments

Getting more entropy

Posted Oct 10, 2010 21:56 UTC (Sun) by man_ls (guest, #15091) [Link]

I guess that the problem is to prove that an attacker cannot influence the timers so that the result is predictable. For example a guy on a different VM doing odd things with the same CPU. As it is hard to prove a negative statement of this kind, then people may tend to distrust such a source of entropy, even if it sounds really interesting.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds