| |||||||||||||
bogus random entropy sourcesbogus random entropy sourcesPosted Oct 5, 2010 17:09 UTC (Tue) by strappe (guest, #53440)In reply to: bogus random entropy sources by jzbiciak Parent article: Solid-state storage devices and the block layer All VIA x86-compatible processors since the C3 (introduced 2003?) have included a hardware random number generator based on quantum effects; it produces millions of random bits each second, and is accessible with a non-privileged instruction. AFAIK, their opcode choice is unused by either AMD or Intel, so those companies could implement similar functionality (an infinitesimal bit of silicon) and we would have a standard solution at least across the x86 architecture going forward.
(Log in to post comments)
bogus random entropy sources Posted Oct 5, 2010 17:22 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link]
Yeah, I was aware of VIA's accelerator. It boggles me that Intel and AMD bothered to put AES acceleration on their chips without getting something more basic and generic like random numbers on there too. Is it a verification issue? What's holding them back?
bogus random entropy sources Posted Oct 5, 2010 18:24 UTC (Tue) by ejr (subscriber, #51652) [Link]
It's not as easy as it seems. You can generate random bits, but they are highly skewed, with different skews depending on the temperature, etc. You need to extract a more regular randomness from them, and extractors can require a good bit of space. The extractors I know (theory, not actual architecture) also must be running continually, sucking power.
bogus random entropy sources Posted Oct 5, 2010 19:10 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] VIA's approach on the C3 doesn't sound too unwieldy. This white paper analyzing the generator's output makes for an informative read. The punch line is that it looks like a pretty reasonable source of entropy as long as you do appropriate post processing. The random numbers it generates aren't caveat free, but they're heckuva lot better than disk seeks and keypresses.
bogus random entropy sources Posted Oct 6, 2010 8:40 UTC (Wed) by pcampe (guest, #28223) [Link]
I don't understand why they didn't follow the guidelines in NIST Standard 800-22 (rev 1a), "A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications".
bogus random entropy sources Posted Oct 6, 2010 13:56 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Probably because they didn't have a time machine. ;-) The document you reference was written this year. The white paper I reference was written in 2003. And if you meant Rev 1, that didn't come out until 2008. Maybe you meant the original 800-22? That one came out in 2001. (Dates came from here.)
bogus random entropy sources Posted Oct 5, 2010 18:26 UTC (Tue) by mpr22 (subscriber, #60784) [Link] The AES accelerator probably lets them tick a required-feature box for some government programme or other.
bogus random entropy sources Posted Oct 5, 2010 18:46 UTC (Tue) by jzbiciak (✭ supporter ✭, #5246) [Link] If anything, it would make it harder for them to export the chips outside of the United States without getting special approval from the Feds. Cryptographic hardware is a munition under ITAR. I remember there was some concern awhile back when we put our AES implementation in ROM on some devices, because it calculated AES "too quickly" for some peoples' taste. We ended up making that part of the ROM protected (ie. not user accessible) so that it was only used for boot authentication.
bogus random entropy sources Posted Oct 6, 2010 11:27 UTC (Wed) by intgr (subscriber, #39733) [Link]
> without getting something more basic and generic like random numbers on there too.
The solution has always been obvious to cryptographers. Use a solid cryptographical pseudorandom RNG; as long as there is _some_ truly random data in its input -- 128 or so bits worth -- the output will always be irreversible. As long as this randomness exists, it doesn't matter that the attacker can predict all other input.
In fact, hardware RNGs should _never_ be used directly, because there may be manufacturing flaws or deliberate sabotage. And unlike deterministic algorithms like AES, non-deterministic hardware RNG sources are almost impossible to verify completely. Also it's really quite easy to replace the hw RNG with a deterministic PRNG that passes all randomness tests, yet whose output is entirely predictable to its designer.
So at most, the hw RNG is just one of several randomness sources on any system. As such cryptographers in general don't consider it worthwhile -- only on diskless embedded systems where there really aren't any entropy sources.
Unfortunately /dev/random is a poor legacy choice in Linux that goes against this concept.
bogus random entropy sources Posted Oct 7, 2010 12:24 UTC (Thu) by nix (subscriber, #2304) [Link]
"Diskless embedded systems" of course includes "all virtual machines". So there are a lot of them.
bogus random entropy sources Posted Oct 7, 2010 12:48 UTC (Thu) by intgr (subscriber, #39733) [Link]
For virtual machines you already have a paravirtual RNG device called 'virtio-rng' (CONFIG_HW_RANDOM_VIRTIO).
But in general, virtual machine disk I/O still reaches a physical disk sooner or later, so entropy can be successfully gathered from interrupt timings. In some virtualization scenarios, you wouldn't want the VM to access host-CPU-specific features anyway.
|
|||||||||||||