On 06/01/2012 02:48 PM, Paul Fuller wrote:
> On 6/01/2012 10:57 PM, Invisible wrote:
>> http://software.intel.com/file/37157
>
> Neat.
>
> I wonder what generation of processors will gain this facility?

Ivy Bridge. (I.e., the next release after Intel's current Sandy Bridge, 
found in processors such as my shiny new Core i7 2600K.) Also whatever 
the codename for the corresponding Xeon component is.

> It won't
> be generally useful until it becomes widespread and even then what is
> the fallback when software detects that it is not running on a processor
> with the facility? Use less secure PRNG and seeds as now?

Depends on the use case, I suppose.

Gaming really does /not/ require true randomness. Human players suck at 
distinguishing psuedo-randomness from true randomness. (Humans suck even 
more at *producing* randomness...)

Numerical simulation sometimes *requires* repeatable "random" inputs. 
And sometimes true randomness is desirable.

Cryptography is the real one where true randomness becomes a Big Deal.

Given how trivially easy it is to use this new system, I'm sure lots of 
people will add support for it. But, as you say, you cannot rely on it 
until it becomes widespread. I wonder if AMD will copy this?

> It reminds me of the Integrated Cryptographic Facility available on IBM
> S/390 mainframes circa 1990 (?). It was a separate processor module that
> offloaded crypto functions from the CPU. From memory they supported
> highly tamper proof key storage and hardware implementation of DES,
> Triple DES etc. but not a hardware entropy source.

I gather crypto devices like that are still quite popular.

> I saw an early hardware RNG device that relied on thermal noise. It was
> about the size of a microwave oven. Most of it was I think to ensure
> that the noise source was kept in a very narrow temperature range so
> that physical randomness was never biased. One of these was hooked up to
> the Internet and you could get the random stream. Sort of defeats many
> of the possible uses of randomness when everybody can see the same
> stream. But for simulations and testing algorithms it was useful I guess.

This implementation uses thermal noise for the truly random part. It 
then uses a normal psuedo-random generator seeded from that.

Something like the Linux /dev/random driver collects things like 
keypress timings, packet arrival times, etc., and puts it into a big 
"entropy pool". It then computes a hash of that pool whenever somebody 
wants a random number. Makes it very hard for an external attacker to 
predict the numbers. It has problems though:

1. This might be running on a headless server, so no keypress events. 
Indeed, if the server is mostly idle other than generating keys, there 
might not be much entropy comming in at all.

2. It's implemented in software. If you can somehow subvert the OS, you 
can take a peek at the entropy pool and predict the future. Similarly, a 
DMA attack might be possible if you have hardware access. On top of 
that, you might be able to change the driver implementation to make it 
spit out NON-random numbers that you decide.

3. It's fairly slow. It fundamentally relies on I/O events, which are 
glacial compared to the speed of the CPU.

4. Other users can see the random output. If the algorithm leaks, that 
might help an attacker. Timing attacks might be possible. An attacker 
might be able to suck the entropy pool dry just be requesting (and 
throwing away) lots of random numbers very quickly. Depending on the 
implementation, this causes either denial of service or reduced random 
quality.

By contrast, Intel's new design is implemented in hardware. It's 
impossible to see the output of the entropy source. It's impossible to 
know exactly when reseeding happens. It's impossible to replace the 
random number algorithm with a broken one. It's impossible to stick 
probes onto the FSB and snoop the entropy pool. (You can still snoop any 
actual keys generated, mind you.)

I also like how there's hardware to monitor the generated random data to 
check it's random enough. The bizarre thing about randomness tests is 
that they _should_ fail occasionally, because a truly random data series 
always contains the occasional pattern by fluke.

Post a reply to this message