| |||||||||||||
Russell: Sources of Randomness for UserspaceRussell: Sources of Randomness for UserspacePosted Mar 30, 2012 8:19 UTC (Fri) by drag (subscriber, #31333)In reply to: Russell: Sources of Randomness for Userspace by alankila Parent article: Russell: Sources of Randomness for Userspace
> Firstly, a freely oscillating circuit inside the CPU to generate random bits doesn't seem complicated to me. It should extract true randomness as fast as you could move bits from the CPU to memory. Why hasn't it been done?
I think a few Intel CPUs implement some form of hardware entropy generation. I don't know the feature very well. There is Via Padlock, which will do this, but I don't have one of those systems. There are a few examples besides that.
Otherwise a USB device can be purchased that features a entropy generator:
I think there are a few problems. One of which is that generating entropy is a lot harder then it sounds like it should be. Another problem is that for many interested parties who would want a good source of entropy there is a number of certification requirements that they have to deal with and for hardware manufacturers it likely expensive and irritating to deal with.
I know from my work with embedded devices used in various places we could not take advantage of the Via padlock system due to it not being up to certification requirements.
(these certifications are largely a bureaucratic matter based mostly around documentation and provability of correctness using certain specific tests. It's very possible to have a secure system that doesn't match government requirements (thus being illegal), but have a insecure one that does. (thus being legal))
> It only takes in the hundreds of bits range of true randomness to properly seed a random number generator, after which it can be run for significant periods (probably years?) without leaking the prng state. In fact, if you unpredictably flip the bits in the prng state based on true random inputs, the problem seems entirely solved to me, as no amount of reading the prng output reveals anything consistent about its state. Am I missing something, again?
I don't know. This does not seem to be a solved problem. I don't know the details, but I know if it is a solved problem then I wouldn't be having these problems with /dev/random and there wouldn't be any reason to have /dev/urandom. It seems that it would be a simple thing to have a PRNG generator in the kernel then to eliminate all the problems people have with dealing with large numbers of SSL connections and such things. It would simplify matters massively.
Haveged seems like a decent solution, but like that advisory said that 'HAVEGE' depends (which is what haveged is based on) on RDTSC to be functioning. Now I know the deamon itself sources the data from the algorithm and then feeds it through PRNG and it could be doing other things for random data, so the actual daemon may not have the same weakness that the algorithm does.
> (Hypothetical answer: people simply are really paranoid about randomness of their random numbers. But is such paranoia justified?)
It can be justified based on the circumstances. Well funded corporate espionage is real. 'Hackivism' is real. Military security concerns are real. Professional organized computer criminals are real. People trying to pursue and defeat governments attempts to monitor and document their activities is real. It's easy to half-ass things and have it work fine, but it's very difficult to be able to prove if it's actually working correctly.
I don't have any strong reason to care right now and probably just symbolic linking /dev/urandom to /dev/random would be perfectly fine for my purposes... however I would like to know the right way to do things and I don't have the expertise to figure it out for myself. :(
(Log in to post comments)
Ivy Bridge first Intel processor with digital hardware random number generator Posted Mar 30, 2012 13:17 UTC (Fri) by jhhaller (subscriber, #56103) [Link] There have been analog random number generators in chipsets before, but they were relatively slow (few hundred kilobits per second), compared to about 3 gigabits per second. See IEEE Spectrum article, including a reference to lavarand, the lava-lamp based random number generator.
Ivy Bridge first Intel processor with digital hardware random number generator Posted Mar 30, 2012 15:17 UTC (Fri) by jhardin (guest, #3297) [Link]
I've always wondered why a 4- or 8-bit register incremented on every clock cycle wouldn't be a simple yet good enough source of entropy? How often is it going to be read?
Ivy Bridge first Intel processor with digital hardware random number generator Posted Apr 2, 2012 12:52 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link]
That was a fine source of randomness for, say the MIPS TLB random replacement, especially since page faults are "far apart," typically.
What about the kernel entropy pool though? First off, where are you sampling this counter to give you data to mix into the pool? Interrupts? With periodic interrupts, you can probably only trust the LSB of the counter to be truly random. That leaves you generating only hundreds or thousands of bits per second.
In any case, on most modern CPUs, we have this freerunning counter already. On x86, it's called the TSC. Of course, it appears RDTSC can get mucked up by virtualization.
|
|||||||||||||