http://software.intel.com/file/37157

Post a reply to this message

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?  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?

Probably will be appear in crypto devices and gaming machines (i.e. 
poker machines etc.) where the enabled processor is specified rather 
than in general use.  Even there, in things like poker machines the 
vendor has to be able to prove that the RNG is compliant with whatever 
rules a jurisdiction sets.  True randomness may strangely not be 
acceptable but I'm not sure.

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 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.

Post a reply to this message

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

Yeh.  I read the PDF.

Thanks for the info on Ivy Bridge.  I haven't looked at processor 
generations for a while.  Bought a laptop about a year ago with an I7 
processor.  Still have a couple of desktops with Q6600 processors from a 
few years back which are still absolutely fine for day to day use and 
development.

Rendering is the only thing that is really processor bound and I don't 
do much of that lately.  Oh, I did have a crack at the Eternity II 
puzzle but there isn't enough CPU power on the planet for that yet.

On a meta-question - Why not post a brief summary when you provide a 
link?  A lot of people wouldn't bother to follow an unknown link.  I 
usually don't.  Then, some people would follow the link and find it a 
waste of time to them and be less inclined to look at anything you post 
in the future.

Is it a deliberate strategy to tempt people, are you too lazy, or do you 
feel the Invisible brand of off-beat random linkage is sufficiently 
powerful?  Probably the latter and I guess around this forum that is 
true - except where Haskell is involved :)

Post a reply to this message

On 06/01/2012 04:14 PM, Paul Fuller wrote:
> Thanks for the info on Ivy Bridge. I haven't looked at processor
> generations for a while.

One of the annoying things about this stuff is that if you stop paying 
attention for a while, it becomes nearly impossible to easily get back 
up to speed. Plenty of places will tell you about the latest and 
greatest up-to-the-minute developments, but if you haven't been 
following recently, you won't have the context to know WTF they're 
talking about. Nothing seems to provide that context. Nothing that I've 
discovered, anyway.

> Rendering is the only thing that is really processor bound and I don't
> do much of that lately.

I do quite a bit of rendering, and I *have* been doing it recently. ;-) 
Also, my current PC seems to be slowly dying. (!) My sister got me a 
shiny new CPU for Christmas, I already have the motherboard, so now I 
just need to buy an OS...

> On a meta-question - Why not post a brief summary when you provide a
> link?

Eh, I don't know. I was just being playful really. It's a random link to 
a paper about randomness. It amused me.

But yeah, sure. For most of the things I post, the description could be 
absolutely anything and nobody would be interested. I guess I'm just a 
really boring person...

Post a reply to this message

On 7/01/2012 3:26 AM, Invisible wrote:

> ... I guess I'm just a really boring person...

Not at all.

I think it was a careers guide that had an entry "Boring - See tunnel 
engineering".  Way to go sterotyping a whole profession that I'm sure 
would have its fair share of interesting individuals.

Post a reply to this message

On 1/6/2012 9:48 AM, Paul Fuller wrote:

> 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.

When I was a cryptographic maintenance technician in the USAF, I did 
work on one piece of gear which actually generated random bits, using 
the thermal noise from a component chosen for this task.  The voltage 
bias on the components had to be within precise limits.  I forget 
exactly what the random bits were used for.  I recall that we were told 
in no uncertain terms not to fiddle with any of the circuitry involved; 
if it didn't work, we simply pulled the circuit card and sent it back to 
the depot.  For the rest of the equipment, we troubleshot down to the 
component level.  The equipment was phased out around 1990.

Regards,
John

Post a reply to this message

On 1/6/2012 8:14, Paul Fuller wrote:
> On a meta-question - Why not post a brief summary when you provide a link?

While I normally agree, I must admit the title of the post and the "intel" 
in the URL told me what was going to be at the other end. :-)

-- 
Darren New, San Diego CA, USA (PST)
   People tell me I am the counter-example.

Post a reply to this message

On 8/01/2012 12:25 AM, John VanSickle wrote:

>
> When I was a cryptographic maintenance technician in the USAF, I did
> work on one piece of gear which actually generated random bits, using
> the thermal noise from a component chosen for this task. The voltage
> bias on the components had to be within precise limits. I forget exactly
> what the random bits were used for. I recall that we were told in no
> uncertain terms not to fiddle with any of the circuitry involved; if it
> didn't work, we simply pulled the circuit card and sent it back to the
> depot. For the rest of the equipment, we troubleshot down to the
> component level. The equipment was phased out around 1990.
>
> Regards,
> John

Wow.  Somebody with real world knowledge.

Thanks for sharing.

Post a reply to this message