Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Behind Intel's New Random-Number Generator

spectrum.ieee.org

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Behind Intel's New Random-Number Generator

#21

Post by Daniel_Newby »

marshray wrote: post #15
learc83 wrote: post #2

Now that's a perfect example of something that seems obvious in hindsight, but obviously wasn't since the problem has existed for so long without a solution. It's also nice to see a more EE oriented post on hacker news now and again.

No. There has been no shortage of perfectly workable designs for hardware random number generators patented over the years. If anything, it's something that engineering types with a fondness for crypto obsess about too much. The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers. The ca…

Nothing needs gigabit rates of random numbers.

Consider a Monte Carlo algorithm on a 2 GHz processor, with a 50 instruction cycle inner loop, using a 64 bit random value per loop: it needs 2.5 Gb/sec of random bits.

Re: Behind Intel's New Random-Number Generator

#22

Post by learc83 »

marshray wrote: post #15
learc83 wrote: post #2

Now that's a perfect example of something that seems obvious in hindsight, but obviously wasn't since the problem has existed for so long without a solution. It's also nice to see a more EE oriented post on hacker news now and again.

No. There has been no shortage of perfectly workable designs for hardware random number generators patented over the years. If anything, it's something that engineering types with a fondness for crypto obsess about too much. The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers. The ca…

I've never really looking into integrated hardware random number generators, but I got the impression from the article that the previous hardware random number generators were based on analog circuits.

Re: Behind Intel's New Random-Number Generator

#23

Post by jbri »

marshray wrote: post #17
wmf wrote: post #8

Earlier quoted context omitted.

Yeah, IIRC VIA is using the same ring oscillator style that Intel used to use. This article is about a new, lower-power RNG design.

The idea that a hardware RNG would ever need to consume a noticeable amount of power on a 20W CPU seems strange to me. Lots of low power chips have them. A quick search returns a paper titled "A 2.92μW Hardware Random Number Generator".

Having a look at that paper, the actual rate at which it produces bits is very low - for 2.92μW, they're producing only 500 bits per second.

For an embedded device that might be suitable, but for a consumer or server machine you need a much higher bitrate.

Re: Behind Intel's New Random-Number Generator

#24

Post by Daniel_Newby »

cpeterso wrote: post #10
shabble wrote: post #4

It seems like it's (ab)using the metastability[1] of the dual inverter circuit as the input source. Since metastable states can persist for arbitrary long periods (with asymptotic probability), the bias testing and reset mechanisms are needed. I assume they're controlling the system to ensure that the thermal noise dominates, and that the de-bias feedback loop and signal conditioner can strip out any low frequency th…

Is there a risk that, after running for a long time, the dual inverter circuit (hardware) could degrade into a "stuck" or severely biased state? At some point, the conditioner probably can't compensate. Is there a method for software to query the RdRand's "health"?

Not unless the hardware fails. The conditioner is a simple, bulletproof feedback loop. (I think it can be done with two resistors, a transistor, and a capacitor, with one internal state: moving towards 0/1 balance.)

Re: Behind Intel's New Random-Number Generator

#25

Post by tedunangst »

Daniel_Newby wrote: post #21
marshray wrote: post #15

Earlier quoted context omitted.

No. There has been no shortage of perfectly workable designs for hardware random number generators patented over the years. If anything, it's something that engineering types with a fondness for crypto obsess about too much. The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers. The ca…

Nothing needs gigabit rates of random numbers. Consider a Monte Carlo algorithm on a 2 GHz processor, with a 50 instruction cycle inner loop, using a 64 bit random value per loop: it needs 2.5 Gb/sec of random bits.

There's no need for the bits to be truly random. In fact, if you ever want anyone to replicate your simulation, you'll need to provide them with the prng algorithm and seed used.

Re: Behind Intel's New Random-Number Generator

#26

Post by tedunangst »

jbri wrote: post #23
marshray wrote: post #17

Earlier quoted context omitted.

The idea that a hardware RNG would ever need to consume a noticeable amount of power on a 20W CPU seems strange to me. Lots of low power chips have them. A quick search returns a paper titled "A 2.92μW Hardware Random Number Generator".

Having a look at that paper, the actual rate at which it produces bits is very low - for 2.92μW, they're producing only 500 bits per second. For an embedded device that might be suitable, but for a consumer or server machine you need a much higher bitrate.

You only need a little "grade-A" random to seed an appropriate high bitrate algorithm from time to time.

Re: Behind Intel's New Random-Number Generator

#27

Post by ars »

mdda wrote: post #19
bdonlan wrote: post #6

Earlier quoted context omitted.

Both sides have to generate secure random numbers in order to perform an ephemeral diffie-helmann exchange securely; if the client's random number is insecure, a man in the middle attack becomes possible. Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.

But surely the client could use human input as it's source of randomness too : After all, in this case (browser purchases) the user is going to be hitting keys and/or moving the mouse.

It could, and today it does. But back then it didn't.

Re: Behind Intel's New Random-Number Generator

#28

Post by Dylan16807 »

palish wrote: post #18
marshray wrote: post #15

Earlier quoted context omitted.

No. There has been no shortage of perfectly workable designs for hardware random number generators patented over the years. If anything, it's something that engineering types with a fondness for crypto obsess about too much. The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers. The ca…

Speaking as a graphics programmer, I hope to see this hardware-level randomness eventually incorporated into GPUs. Randomness on a GPU is hard , and there are so many ways that a RNG can improve visual quality. For example, adding a tiny amount of film grain to the final rendered image would most easily be done with RNG. Another example: it's common for renderers to accumulate the scene's illumination into a HDR text…

In what way is randomness on a GPU hard? The nVidia SDK apparently comes with a few of them, and you can implement an LCG in handful of arithmetic operations. If you need a seed feed it in from the CPU.

I don't see the benefit of having a high-cryptographic-quality RNG for rendering.

Re: Behind Intel's New Random-Number Generator

#29

Post by marshray »

jbri wrote: post #23
marshray wrote: post #17

Earlier quoted context omitted.

The idea that a hardware RNG would ever need to consume a noticeable amount of power on a 20W CPU seems strange to me. Lots of low power chips have them. A quick search returns a paper titled "A 2.92μW Hardware Random Number Generator".

Having a look at that paper, the actual rate at which it produces bits is very low - for 2.92μW, they're producing only 500 bits per second. For an embedded device that might be suitable, but for a consumer or server machine you need a much higher bitrate.

No one has ever broken a properly designed CSPRNG properly seeded with more than 100 or 200 bits of entropy, total.

Re: Behind Intel's New Random-Number Generator

#30

Post by [deleted] »

nitrogen wrote: post #20
palish wrote: post #18

Earlier quoted context omitted.

Speaking as a graphics programmer, I hope to see this hardware-level randomness eventually incorporated into GPUs. Randomness on a GPU is hard , and there are so many ways that a RNG can improve visual quality. For example, adding a tiny amount of film grain to the final rendered image would most easily be done with RNG. Another example: it's common for renderers to accumulate the scene's illumination into a HDR text…

Do bloom effects generally use Gaussian filters? Is anybody doing full convolution with something more natural looking, like a flat circle or a regular polygon (e.g. like Gimp's Focus Blur plugin)?

[deleted]
Post reply on HN