I thought the 40-bit keys were used due to cryptographic export restrictions, and not lack of randomness?
http://en.wikipedia.org/wiki/40-bit_encryption
Seems to agree with me.
Behind Intel's New Random-Number Generator
11–20 of 43 posts
Re: Behind Intel's New Random-Number Generator
#12I thought the 40-bit keys were used due to cryptographic export restrictions, and not lack of randomness? http://en.wikipedia.org/wiki/40-bit_encryption Seems to agree with me.
[deleted]
Re: Behind Intel's New Random-Number Generator
#13I thought the 40-bit keys were used due to cryptographic export restrictions, and not lack of randomness? http://en.wikipedia.org/wiki/40-bit_encryption Seems to agree with me.
The authors didn't cite Netscape because the 40-bit key is too short, they cited it because the the PNRG in the SSL implementation was faulty.
They link to this page with more details: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html
Re: Behind Intel's New Random-Number Generator
#14It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders. Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
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.
[deleted]
Re: Behind Intel's New Random-Number Generator
#15Now 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 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.
Re: Behind Intel's New Random-Number Generator
#16It 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"?
Yes, the instruction that returns random bits returns a flag indicating that the bits were successfully obtained. I guarantee you somebody somewhere is going to forget to check that flag.
Re: Behind Intel's New Random-Number Generator
#17Earlier quoted context omitted.
VIA's "Nehemiah" core C3 CPUs had hardware random number generation, as well as hardware AES assist, way back in 2003. (And, of course, VIA's "PadLock" instructions and Intel's RdRand instruction + AES-NI instructions are totally different. Hooray for continued x86 instruction set fragmentation!) Edit: It just occurred to me that you're probably referring to the implementation, not the existence of a hardware RNG in…
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".
Re: Behind Intel's New Random-Number Generator
#18Now 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…
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.
Re: Behind Intel's New Random-Number Generator
#19It's easy to see that {process-id, parent-id, timestamp} can lead to a pretty predictable random number seed. But Amazon also had another easily available source of randomness : the timestamps of other customer's orders. Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
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.
Re: Behind Intel's New Random-Number Generator
#20Earlier 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…
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)?