8 ms·

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 eng

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 cases where applications have had lousy random numbers have all been boneheaded implementation bugs (like the early 90s Netscape one the reference). There are two reasons why this had not been implemented until now: 1. Low demand. It's entirely practical for applications to generate random numbers in software, especially with help from the kernel. With a hardware RNG on some chips, a fallback implementation would still have to be available and people who care about their CSPRNGs in software wouldn't fully trust Intel's numbers anyway. 2. Additional design, documentation, and testing burden. Every feature has a cost. The cryptographic qualities of random numbers are nearly impossible to test as a black box.

palish 15y ago
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 texture, and then radially blur it. The goal is to approximate the halo you observe around light sources at night time. The problem is, a Gaussian blur is perfectly smooth --- so the resulting glow typically ends up being a perfectly smooth blurry circle of light. But a real photograph of the same scene rarely has smooth glows. The image exhibits all kinds of subtle noise in the light's corona. After all, a photograph results from interaction of light with the camera lens, multiple scattering in outdoor scenes, chromatic dispersion, interaction between polarized light and certain materials, ... and many, many more phenomena. So rather than try to model each of those physical lighting effects in realtime, it would be wonderful to have a "RNG()" shader function to simply add a smidgen of unpredictability to our realtime rendering techniques. The closer your final image resembles nature, the better it looks --- and nature is many things, but she is not a perfectly smooth BRDF lighting model! So yeah... It would be frickin' sweet to have this RNG on a GPU.
- nitrogen 15y ago
  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 15y ago
    [deleted]
- Dylan16807 15y ago
  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.
  - palish 15y ago
    You'll have to take my word for it, or try it yourself: there are visually noticeable repetitive patterns that are a direct result of the naive PRNG. For example I once modeled raindrops as falling billboards that struck the ground at some random (x,y) in your field of view, followed by a "splash" animation billboard where it struck the ground. I started by using C rand() to determine the random (x,y) of the raindrop. And it looked terrible! The raindrops would mysteriously clump together in sinewave-like patterns, and seemingly avoid some spots altogether. I dropped in a Mersenne Twister RNG and the problem instantly went away. I didn't change a thing except the RNG. So yeah, a few arithmetic ops gets you rand() quality. But humans are unfortunately good at noticing the overall bias in the resulting patterns. And you'll run into similar problems when e.g. trying to implement a non-repeating perlin noise function on a GPU. I tried it with a weighted combination of several different perlin noise textures... but I had to be very careful about aliasing artificts in some of the more interesting effects; while also being careful of avoiding visually-repetitive patterns (which almost always occur). The value of Intel's RNG, I'd imagine, is that it's uniformly random and also unbiased -- meaning repetitive moire patterns won't show up in your results. Of course it's not deterministic, which is tricky, but I can still think of several use cases for something like this.
Daniel_Newby 15y ago
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.
- tedunangst 15y ago
  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.
- ghshephard 15y ago
  Perhaps this should be better written as "Nothing needs gigabit rates of _cryptographically strong_ random numbers." Using a megabit rates of cryptographically strong random numbers to seed a PRNG would be fine for most purposes. Can anyone think of a reason why you would want/use gigabit rates of truly random numbers instead of using a slower rate to see a PRNG?
  - algorias 15y ago
    >Using a megabit rates of cryptographically strong random numbers to seed a PRNG would be fine for most purposes. And that's exactly what the hardware described in the article does for you.
  - marshray 15y ago
    Perhaps this should be better written as "Nothing needs gigabit rates of _cryptographically strong_ random numbers." Yes that's what I meant to say. I probably didn't realize the discussion had widened to include insecure number generation.
  - Daniel_Newby 15y ago
    True. Although the new Intel system is not cryptographically secure. Gigabit true random numbers could be used to modulate a jam-resistant radar signal. That makes it difficult for an opponent to use active electronics to cloak their target, even in principle. However actual systems would use dedicated hardware, not an Intel chip. The profoundly paranoid could interleave true random bits with their data bits before encrypting (discard them on receipt). Pattern analysis would become much more difficult.
learc83 15y ago
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.

palish 15y ago

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 texture, and then radially blur it. The goal is to approximate the halo you observe around light sources at night time. The problem is, a Gaussian blur is perfectly smooth --- so the resulting glow typically ends up being a perfectly smooth blurry circle of light. But a real photograph of the same scene rarely has smooth glows. The image exhibits all kinds of subtle noise in the light's corona. After all, a photograph results from interaction of light with the camera lens, multiple scattering in outdoor scenes, chromatic dispersion, interaction between polarized light and certain materials, ... and many, many more phenomena. So rather than try to model each of those physical lighting effects in realtime, it would be wonderful to have a "RNG()" shader function to simply add a smidgen of unpredictability to our realtime rendering techniques. The closer your final image resembles nature, the better it looks --- and nature is many things, but she is not a perfectly smooth BRDF lighting model! So yeah... It would be frickin' sweet to have this RNG on a GPU.

nitrogen 15y ago
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 15y ago
  [deleted]
Dylan16807 15y ago
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.
- palish 15y ago
  You'll have to take my word for it, or try it yourself: there are visually noticeable repetitive patterns that are a direct result of the naive PRNG. For example I once modeled raindrops as falling billboards that struck the ground at some random (x,y) in your field of view, followed by a "splash" animation billboard where it struck the ground. I started by using C rand() to determine the random (x,y) of the raindrop. And it looked terrible! The raindrops would mysteriously clump together in sinewave-like patterns, and seemingly avoid some spots altogether. I dropped in a Mersenne Twister RNG and the problem instantly went away. I didn't change a thing except the RNG. So yeah, a few arithmetic ops gets you rand() quality. But humans are unfortunately good at noticing the overall bias in the resulting patterns. And you'll run into similar problems when e.g. trying to implement a non-repeating perlin noise function on a GPU. I tried it with a weighted combination of several different perlin noise textures... but I had to be very careful about aliasing artificts in some of the more interesting effects; while also being careful of avoiding visually-repetitive patterns (which almost always occur). The value of Intel's RNG, I'd imagine, is that it's uniformly random and also unbiased -- meaning repetitive moire patterns won't show up in your results. Of course it's not deterministic, which is tricky, but I can still think of several use cases for something like this.

Daniel_Newby 15y ago

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.

tedunangst 15y ago
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.
ghshephard 15y ago
Perhaps this should be better written as "Nothing needs gigabit rates of _cryptographically strong_ random numbers." Using a megabit rates of cryptographically strong random numbers to seed a PRNG would be fine for most purposes. Can anyone think of a reason why you would want/use gigabit rates of truly random numbers instead of using a slower rate to see a PRNG?
- algorias 15y ago
  >Using a megabit rates of cryptographically strong random numbers to seed a PRNG would be fine for most purposes. And that's exactly what the hardware described in the article does for you.
- marshray 15y ago
  Perhaps this should be better written as "Nothing needs gigabit rates of _cryptographically strong_ random numbers." Yes that's what I meant to say. I probably didn't realize the discussion had widened to include insecure number generation.
- Daniel_Newby 15y ago
  True. Although the new Intel system is not cryptographically secure. Gigabit true random numbers could be used to modulate a jam-resistant radar signal. That makes it difficult for an opponent to use active electronics to cloak their target, even in principle. However actual systems would use dedicated hardware, not an Intel chip. The profoundly paranoid could interleave true random bits with their data bits before encrypting (discard them on receipt). Pattern analysis would become much more difficult.

learc83 15y ago

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.