Re: Intel to also add RNG
On 7/13/10, Perry E. Metzger pe...@piermont.com wrote: It is disturbing to me that people oppose this so much. Yes. A hardware RNG seems an obvious Good Thing. Not a complete solution, but a very useful component. For a lot of applications -- servers run in isolation, networking equipment, etc. -- having hardware RNGs available is a really big win, because there is no good local source of randomness. (We had a long discussion of ways to mitigate this some time ago.) Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. IPsec gateways and web servers doing a lot of SSL are obvious cases. Neither has much mouse or keyboard activity, they may have solid state drives or smart RAID so disk timings are not random. Packet timings might be somewhat random, but they may also be knowable by an enemy. I would suggest that in most cases, you are better off with a very very mildly untrusted but ubiquitous hardware RNG than with the kinds of kludges to get random numbers on unattended hardware we end up with in the real world. In some cases, a non-kludge alternative is Turbid: http://www.av8n.com/turbid/paper/turbid.htm That uses a sound card or on-board equivalent. Some boards will have this, or it is cheap easy to stick in a slot. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Tue, Jul 13, 2010 at 05:46:36PM +1200, Peter Gutmann wrote: Paul Wouters p...@xelerance.com writes: Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. Do you have any more details on this? Was it a hardware problem, software problem, ...? How was it caught? I couldn't say, as regards AMD's chipset RNG. Intel's, however, was on an optional component of one of their motherboard chipsets. Many motherboard vendors chose to buy that component from other sources, who implemented something register-compatible to the Intel part but with the RNG register not actually connected to a random number source. Worse, when Intel increased chipset integration and pulled the optional chip into one of the host bridge chips, they did the exact same thing. The basic problem was that the register indicating presence-of-RNG was not on the same piece of silicon (originally) as the actual RNG. So the register really indicated only that this Intel chipset *was capable of interfacing to the chip with the RNG on it*; nothing more. Worse, a lot of people read noise -- but not really random noise -- from those notional RNG registers and persuaded themselves that since the output wasn't continuous, there must really be an RNG present. Oops. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On 12 July 2010 18:13, Jack Lloyd ll...@randombit.net wrote: On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: BTW, let me note that if Intel wanted to gimmick their chips to make them untrustworthy, there is very little you could do about it. The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. Given that, I see little reason not to trust them on an RNG, and I wish they would make it a standard part of the architecture already. I think it's important to make the distinction between trusting Intel not to have made it actively malicious, and trusting them to have gotten it perfectly correct in such a way that it cannot fail. Fortunately, the second problem, that it is a well-intentioned but perhaps slightly flawed RNG [*], could be easily alleviated by feeding the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take your pick I guess). And the first could be solved by also feeding your CSPRNG with anything that you would have fed it with in the absense of the hardware RNG - in that case, you're at least no worse off than you were before. (Unless your PRNG's security can be negatively affected by non-random or maliciously chosen inputs, in which case you've got larger problems). Several years ago I reviewed a new design for FreeBSD's PRNG. It was vulnerable to sources that had high data rates but low entropy (they effectively drowned out lower data rate sources). This was fixed, but I wonder how common an error it is? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
Paul Wouters p...@xelerance.com writes: Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. Do you have any more details on this? Was it a hardware problem, software problem, ...? How was it caught? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On 12/07/2010 22:13, Eric Murray wrote:/ On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote: On Mon, 12 Jul 2010, Eric Murray wrote: Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So you can do HWRNG - SWRNG - Fips ? Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only. X9.62 or FIPS 186 or X9.31 or SP 800-90. I couldn't even use a HW RNG for the seed. /dev/random was acceptable. The Smart Card industry uses True RNG a lot. There, a common line of thought is to use: - a hardware RNG, which raw output (perhaps biased) is directly accessible for testing purposes (only), so that the software can check it in depth at startup and from time to time to ascertain that it is at least generating a fair amount of entropy - followed by appropriate post-processing in hardware (so as to gather entropy at all time), acting as a mixer/debiaser:; e.g. something LFSR-based - followed by a crude software test (e.g. no bit stuck) - optionally followed by software postprocessing (the subject is debated; this software has to be proven to not include weakness, and the hardware + crude software test is certified to eliminate such weakness, so why bother, some say) There is a standard, known as AIS31, on evaluating True RNG, which de-facto enforces the first three steps https://www.bsi.bund.de/cae/servlet/contentblob/478130/publicationFile/30270/ais31e_pdf.pdf which references https://www.bsi.bund.de/cae/servlet/contentblob/478152/publicationFile/30275/ais20e_pdf.pdf For German-reading audience, the page linking to that is https://www.bsi.bund.de/cln_174/DE/Themen/ZertifizierungundAkkreditierung/ZertifizierungnachCCundITSEC/AnwendungshinweiseundInterpretationen/AISITSEC/aisitsec_node.html Google does good work when fed with AIS31. François Grieu - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
Have they forgotten the enormous amount of suspicion last time they tried this? More likely they're expecting everyone else to have forgotten about being suspicious. /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
Ben Laurie b...@google.com writes: On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? You mean rampant paranoia from a small group of people... if you are genuinely worried about this, just use it as another input to mix into your entropy pool (which you should be doing anyway, never trust a single source of entropy). I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this manner, let alone an Intel CPU. What killed it wasn't paranoia about Intel but their almost total lack of interest in supporting it once the initial media attention waned. This doesn't look any different, note that it's not saying This will be in Core2's starting August but We've done this in the lab. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Tue, 13 Jul 2010 03:58:51 +1200 Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@google.com writes: On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? You mean rampant paranoia from a small group of people... if you are genuinely worried about this, just use it as another input to mix into your entropy pool (which you should be doing anyway, never trust a single source of entropy). I'd be quite happy to use the RNG on a Loongson CPU (if there was one) in this manner, let alone an Intel CPU. What killed it wasn't paranoia about Intel but their almost total lack of interest in supporting it once the initial media attention waned. This doesn't look any different, note that it's not saying This will be in Core2's starting August but We've done this in the lab. It is disturbing to me that people oppose this so much. For a lot of applications -- servers run in isolation, networking equipment, etc. -- having hardware RNGs available is a really big win, because there is no good local source of randomness. (We had a long discussion of ways to mitigate this some time ago.) Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. I would suggest that in most cases, you are better off with a very very mildly untrusted but ubiquitous hardware RNG than with the kinds of kludges to get random numbers on unattended hardware we end up with in the real world. BTW, let me note that if Intel wanted to gimmick their chips to make them untrustworthy, there is very little you could do about it. The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. Given that, I see little reason not to trust them on an RNG, and I wish they would make it a standard part of the architecture already. Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Jul 12, 2010, at 11:22 AM, Perry E. Metzger wrote: The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. I happen to be re-reading Vernor Vinge's _A Deepness in the Sky_ right now. In it, a conquering power needs to use the computing and communication technology of its subjugated foe, and has unusual resources to carry out a thorough code audit. However, the foe has been hiding secrets since before the victors were fooling with electricity ... smime.p7s Description: S/MIME cryptographic signature
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: BTW, let me note that if Intel wanted to gimmick their chips to make them untrustworthy, there is very little you could do about it. The literature makes it clear at this point that short of carefully tearing apart and analyzing the entire chip, you're not going to catch subtle behavioral changes designed to allow attackers backdoor access. Given that, I see little reason not to trust them on an RNG, and I wish they would make it a standard part of the architecture already. I think it's important to make the distinction between trusting Intel not to have made it actively malicious, and trusting them to have gotten it perfectly correct in such a way that it cannot fail. Fortunately, the second problem, that it is a well-intentioned but perhaps slightly flawed RNG [*], could be easily alleviated by feeding the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take your pick I guess). And the first could be solved by also feeding your CSPRNG with anything that you would have fed it with in the absense of the hardware RNG - in that case, you're at least no worse off than you were before. (Unless your PRNG's security can be negatively affected by non-random or maliciously chosen inputs, in which case you've got larger problems). -Jack [*] Even if it were perfectly designed, it seems plausible to me that manufacturing defects and/or any number of runtime problems (age, overheating, bad voltage control, cosmic rays, dirty power, etc, etc) might cause subtle failures/biases that might be difficult to detect reliably; I would personally be dubious of using any hardware RNGs output directly for this reason. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 12:22:51PM -0400, Perry E. Metzger wrote: Plugging in an external unit is not going to happen in practice. If it isn't nearly free and built in, it won't be used. I completely agree. But HW RNGs are a pain in a lot of ways- modern chip design libraries don't include RNG modules. You have to make your own. Verification software won't verify it and considers it an error. When it runs it sucks a lot of power and generates a lot of heat. Not a problem for Intel, but if you're using a contract fab (TSMC) they probably won't guarantee that part of your chip will even work because according to chip design rules, it's wrong. Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So while I think it'd be great to have a decent RNG on chip (no more blocking on /dev/random!) I don't see it being much of a market advantage and would not be surprised if it never makes it in to a shipping product. Mixing the output with something else would address any lack of randomness either deliberate or accidental... but still wouldn't meet FIPS. BTW Intel isn't close to the first to put an RNG on a CPU chip. I worked for a company in the late 1990s that did it and I'm sure we wern't the first. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 01:13:10PM -0400, Jack Lloyd wrote: I think it's important to make the distinction between trusting Intel not to have made it actively malicious, and trusting them to have gotten it perfectly correct in such a way that it cannot fail. Fortunately, the second problem, that it is a well-intentioned but perhaps slightly flawed RNG [*], could be easily alleviated by feeding the output into a software CSPRNG (X9.31, a FIPS 186-3 design, take your pick I guess). And the first could be solved by also feeding your CSPRNG with anything that you would have fed it with in the absense of the hardware RNG - in that case, you're at least no worse off than you were before. (Unless your PRNG's security can be negatively affected by non-random or maliciously chosen inputs, in which case you've got larger problems). You need an entropy pool anyways. Adding entropy (from the CPU's RNG, from hopefully-random event timings, ...) and non-entropy (from a flawed HW RNG, from sadly-not-random event timings, ...) to the pool results in having enough entropy (once enough entropy has been added to begin with). You'll want multiple entropy sources no matter what, to deal with HW RNG failures for example. BTW, SPARC CPUs have shipped with on-board HW RNGs; Intel is hardly first. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, 12 Jul 2010, Ben Laurie wrote: On 2 July 2010 13:19, Eugen Leitl eu...@leitl.org wrote: http://www.technologyreview.com/printer_friendly_article.aspx?id=25670channel=Briefingssection=Microprocessors Tuesday, June 29, 2010 Nanoscale Random Number Circuit to Secure Future Chips Intel unveils a circuit that can pump out truly random numbers at high speed. Have they forgotten the enormous amount of suspicion last time they tried this? I love how they pretend to be the first ones with this, totally ignoring others who have had this for years, such as the VIA PadLock. The article lists NIST having done tests, but does not mention any CPU model where this is on. Anyone knows? Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, 12 Jul 2010, Eric Murray wrote: Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So you can do HWRNG - SWRNG - Fips ? Which is what you should do anyway, in case of a hardware failure. I know the Linux intel-rng and amd-rng used to produce nice series of zeros. The padlock rng has never produced warnings piping it through rngd. So while I think it'd be great to have a decent RNG on chip (no more blocking on /dev/random!) I don't see it being much of a market advantage and would not be surprised if it never makes it in to a shipping product. With every phone doing crypto these days, I'd think you are wrong. Also, the VIA PadLock already ships with an HWRNG on die. It's been shipping for years. Paul - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Intel to also add RNG
On Mon, Jul 12, 2010 at 03:37:45PM -0400, Paul Wouters wrote: On Mon, 12 Jul 2010, Eric Murray wrote: Then there's FIPS- current 140 doesn't have a provision for HW RNG. They certify software RNG only, presumeably because proving a HW RNG to be random enough is very difficult. So what's probably the primary market (companies who want to meet FIPS) isn't available. So you can do HWRNG - SWRNG - Fips ? Last FIPS cert I did (140-2, a couple years ago), it was SWRNG only. X9.62 or FIPS 186 or X9.31 or SP 800-90. I couldn't even use a HW RNG for the seed. /dev/random was acceptable. Also, the VIA PadLock already ships with an HWRNG on die. It's been shipping for years. True that. Eric - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
