| |||||||||||||
Definitely not speaking for my employer, but here goes..Definitely not speaking for my employer, but here goes..Posted Jul 20, 2012 8:55 UTC (Fri) by Aissen (subscriber, #59976)In reply to: Definitely not speaking for my employer, but here goes.. by DavidJohnston Parent article: Random numbers for embedded devices
Compared to the treatment of most CPU logic, Intel has been extraordinarily open with the design on the RNG, exposing the full algorithmic details and opening the design for external review. I've yet to see an comparable expositions of why we should believe the Kernel entropy gathering code achieves a well defined min-entropy. Could you provide links to the papers, algorithms and design source code ?
(Log in to post comments)
Definitely not speaking for my employer, but here goes.. Posted Jul 20, 2012 12:39 UTC (Fri) by nix (subscriber, #2304) [Link]
Links to proof that what's in the CPU matches that design would be necessary too, before this can be trusted. The point about those sources that currently contribute to the entropy estimate is that they are only those sources which an external observer can see cannot be controlled or predicted by an attacker. Something impossible to inspect buried inside your CPU by a major corporation is... not worthy of the same degree of trust.
It's not even worthy of the same degree of trust as, say, the Simtec Entropy Key, because at least Simtec is a small company and you can in theory get to know the people who did the work and become as sure as you wish that they did not get nobbled by the secret services -- though even that entropy is somewhat less trustworthy than environmental entropy not derived from a necessarily-opaque IC. Intel? It's a behemoth, and we know it therefore does business with all sorts of people. Who knows what pressures may have been brought to bear?
This isn't saying that I think pressures *were* brought to bear on Intel to nobble their RNGs -- it's just that had they *been* brought to bear, the design would have looked just like we see now (as the nobbling would happen later in the process, with less risk of public exposure), and the CPUs that resulted would have looked from the outside *just like the ones we see now* except that their 'random' numbers would be predictable by a suitably-privileged outside attacker. So we cannot distinguish between those cases, so cannot grant the entropy derived from those CPUs the same definitely-unpredictable status as entropy derived from environmental noise.
(This is not, of course, unique to Intel. I consider uninspectable RNGs and binary crypto blobs from all vendors untrustworthy, but larger vendors are probably less trustworthy than smaller ones, regardless of the quality of their engineering or employees, simply because they are easier for the security services to quietly nobble.)
Definitely not speaking for my employer, but here goes.. Posted Jul 21, 2012 3:22 UTC (Sat) by DavidJohnston (subscriber, #85852) [Link]
Then I suspect no hardware product will meet your needs.
Definitely not speaking for my employer, but here goes.. Posted Jul 21, 2012 13:48 UTC (Sat) by nix (subscriber, #2304) [Link]
Precisely my point. Or, rather, they do meet my needs, but my needs do not include having this stuff contribute to the entropy estimate. I can't trust that it is truly entropy. That doesn't mean it won't help keep your random numbers look random, of course: it still mixes into the pool.
Definitely not speaking for my employer, but here goes.. Posted Aug 18, 2012 16:32 UTC (Sat) by kjp (subscriber, #39639) [Link]
Use an FM or TV tuner and use the white noise for entropy. I'd trust that.
Definitely not speaking for my employer, but here goes.. Posted Aug 18, 2012 21:37 UTC (Sat) by nix (subscriber, #2304) [Link]
Really? That noise is often fearfully non-random and highly correlated, and anyone with a radio transmitter or indeed any electrical device can introduce new patterning. It's... not a good noise source on its own (though obviously it contains noise, so it could probably contribute *some* entropy.)
Definitely not speaking for my employer, but here goes.. Posted Jul 23, 2012 17:19 UTC (Mon) by tytso (subscriber, #9993) [Link]
Of course there could be hardware products that would meet an independent auditability criteria. It would require a completely open hardware design where the only thing that is done in hardware is a noise diode, and the minimal circuitry to convert the analog signal into a digital one. A quick google search reveraled something like this that could perhaps be used as a basis of such an implementation:
https://mywebspace.wisc.edu/lnmaurer/web/minirng/minirng....
Add a simple USB interface so it can be plugged into a laptop or a server, but the key point is that it's a open hardware design, using basic commodity parts whose operation can be easily verified.
Then what we do in open source software is all of the hard work of analyzing the raw output of the hardware circuit, to make sure it hasn't failed, and then all of the whitening using AES, etc. Alternatively, we could take the unwhitened output and just feed it into /dev/random (since the /dev/[u]random entropy pools will take care of doing the whitening for us).
Definitely not speaking for my employer, but here goes.. Posted Jul 24, 2012 16:59 UTC (Tue) by nix (subscriber, #2304) [Link] Alternatively, we could take the unwhitened output and just feed it into /dev/random (since the /dev/[u]random entropy pools will take care of doing the whitening for us).This is exactly what the Entropy Key's daemon does. There's no point in engaging in whitening and the like, since the key already does all of that (mixing together the output of two RNGs, making sure they are not correlated, and the like) and the daemon just asks the key 'are you broken?' and stops feeding entropy into /dev/random if it says it is.
Definitely not speaking for my employer, but here goes.. Posted Jul 21, 2012 3:11 UTC (Sat) by DavidJohnston (subscriber, #85852) [Link]
>Could you provide links to the papers, algorithms and design source code ?
The design source code isn't available. There's a lot more to designing chip RTL at 22nm than just the implementation of the algorithms, so I'm not at liberty to reveal the source code.
I'm working towards making some C code available that models the design. This served as part of the design validation (it helps show model equivalence and calibrate entropy estimates) but could also answer a lot of the detail questions people have about the nature of the raw entropy.
Patrick OKeef has done an efficient job of linking to all the information that is out there. https://sites.google.com/site/intelrdrand/references
You might find Jesse Walker's talk, particularly the stuff at the end on the Ornstein-Uhlenback process (which nicely models ES) informative. http://www.ists.dartmouth.edu/docs/walker_ivy-bridge.pdf
The Intel Developer Forum talk should be out there somewhere. If not I can send it.
These guys performed external review. They did get to see the source code and had access to raw data and the engineers. Fortunately for us they didn't find anything too horrendous. The paper is here: http://www.cryptography.com/public/pdf/Intel_TRNG_Report_...
I described the details of the conditioning algorithms here: http://software.intel.com/en-us/forums/showthread.php?t=1...
There's more on the way, but we have to write it first.
|
|||||||||||||