Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
At 6:19 pm -0500 2000-01-26, Tom McCune wrote: Just in case anyone else is interested in my findings on whether I could use the Intel RNG with my Celeron machine: I needed help to find the driver installation file at the Dell site - I had searched for Intel RNG, but it can be found by searching for Intel Security Driver. It can be used by Celeron machines, but not mine::-( Tom, If you're right, this could be a *feature* of your Celeron, not a bug. Persons who shall remain nameless shared some info with me (under privacy lock: I'm not prepared to discuss the details they provided in public without permission) about the Intel RNG and how it was presented for review by various software vendors. Coupled with my experience in my former corporate security job where we "reviewed" limited aspects of similar Intel technology, I'm now just about on the same wavelength as Bill Geiger at this point (though our styles differ significantly, I respect Bill's learnéd opinion). This is to say that: (A) I'm not sanguine about it being a "default" in any version of PGP, knowing what I do and having been told more by others, (B) I strongly encourage the PGP engineering group to include and explicit checkbook preference/option for disabling PGP's use of the Intel RNG completely into v7.0, (C) I'm troubled that Intel has not yet --even at this late date-- provided comprehensive technical data on how the RNG works for public review and, (D) I'm extremely glad there doesn't appear to be one in my Mac or SparcStation, and my hand-built PC's have AMD K2/3's in 'em. ;) I'm definitely NOT out to scare anyone or start any silly rumors, so if anyone on this list is unclear about why this COULD BE a very serious security threat situation, FIRST, I recommend that you not comment on the situation off of this list (i.e. starting uninformed rumors on Usenet or elsewhere) unless you're a mathematician or security professional who knows something about random number generation and SECOND that you be aware of the following: ALL of the strength of your cryptographic security is based primarily on RNGs (Random Number Generators) and their ability to generate cryptographically-random seed values for everything from public keypair generation (your identity and security) to session key generation (each message's cryptographic randomness). Left on it's own, PGP's software PseudoRNG has been studied extensively, and while it's not *perfect* the community knows it's flaws, considers them manageable, and has compensated for them adequately to date. Also, I'm NOT saying that the following is the status quo, but a cautious person's analysis of hypothetical situations where the unknown Intel RNG could be a security threat might go something like this: IF 1+2+3+4=TRUE, where: (1) a large security software vendor were pressured at the executive level and unknown to the engineering staff, (2) (directly or indirectly) by government officials in charge of message interception, (3) to incorporate a piece of hardware, designed in secret and kept proprietary, that generated flawed randomness and thus provides traction for cryptanalytic attacks (4) even on large keysizes now allowed for export under current regulations and thought (mistakenly?) by the security community to be reasonably secure... THEN: A product from that vendor using that hardware RNG cannot truly be considered secure against the most sophisticated attacker. The solution would be for Intel to fully divulge precisely how it's RNG works, not only to vendors like the hypothetical one above, but to the entire Internet community. If it turns out that it's a really great RNG, then we can all rest more easily. If it turns out that it produces non-random strings that compromise keys and messages (and adds processor-unique id strings and timestamps ;), then all PGP users have the right to know about it immediately and eschew use of Intel products that incorporate that RNG. Several good questions remain unanswered: why has Intel not revealed how this RNG works to the world? Why has Intel not at least completely divulged the internal functions to the PGP engineering team (who I'd trust a lot more than Intel, since they have good engineers on staff who still *have* a reputation for integrity to protect). What exactly are they protecting themselves from, or what pressures are they under from external entities to provide an intentionally-flawed security product to benefit the spy agencies, a la the infamous Walsh Report? (c.f. http://www.efa.org.au/Issues/Crypto/Walsh/index.htm.) Keep in mind that the vendors themselves may be unwitting victims of Intel's (forced?) collaboration with unknown agencies. Note also that OpenPGP would *never* incorporate RNG input from a proprietary device as a "MUST" in any draft or RFC. NAI's PGP is not currently fully OpenPGP-compliant in this regard, though it's functionally
Companies Ignore China's Encryption Regulations (was Re:NewsScan Daily, 1 February 2000 (Above The Fold))
At 9:48 AM -0700 on 2/1/00, NewsScan wrote: COMPANIES IGNORE CHINA'S ENCRYPTION REGULATIONS If everyone covered by China's new regulations on encryption registration had complied, about nine million Internet users would have shown up in one tiny government office to hand-deliver a form specifying what kind of encryption they used on their computers. Instead, only a handful of people showed up. Chinese officials have said there will be no extension of the deadline, but apparently have not yet decided what to do about the companies that missed it -- a group that includes virtually every Chinese and foreign company doing business in China. (Reuters/New York Times 1 Feb 2000) http://www.nytimes.com/library/tech/00/02/biztech/articles/01china-encryptio n.html - R. A. Hettinga mailto: [EMAIL PROTECTED] The Internet Bearer Underwriting Corporation http://www.ibuc.com/ 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
It may not have been mentioned here, but Intel has released the programmer interface specs to their RNG, at http://developer.intel.com/design/chipsets/manuals/298029.pdf. Nothing prevents the device from being used in Linux /dev/random now. As for the concerns about back doors, the best reference on the design of the RNG remains cryptography.com's analysis at http://www.cryptography.com/intelRNG.pdf. Paul Kocher and his team concluded that the chip was well designed and that the random numbers were of good quality. (Note, BTW that the RNG is extremely small, crammed into the margins of the device. An RNG which produced undetectably backdoored random date would probably be an order of magnitude larger.) Even if Intel wanted to put in a back door, it would be very difficult to exploit it successfully. There is no way for the chip to predict how any given random bit will be used: it may go into a session key directly, it may be hashed through some kind of mixing function along with other sources of randomness, it may seed a PRNG which is then used to find RSA primes. There are a multitude of different possibilities and it would be hard in general to design an effective backdoor without knowing how the output will be used. And as pointed out before, this level of paranoia is ultimately self defeating, as Intel could just as easily put back doors into its CPU. Unless or until you are willing to use a self-designed and self-fabbed CPU, you are fundamentally at the mercy of the hardware manufacturer.
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
lcs Mixmaster Remailer wrote: As for the concerns about back doors, the best reference on the design of the RNG remains cryptography.com's analysis at http://www.cryptography.com/intelRNG.pdf. The one problem I have with the RNG, based on my reading of the analysis, is that programmers cannot access the "raw" bitstream, only the stream after the "digital post-processing" that converts the bitstream into a stream of balanced 1 and 0 bits. And as pointed out before, this level of paranoia is ultimately self defeating, as Intel could just as easily put back doors into its CPU. Also, there are much better places to leak information, including keyboard and monitor designs that radiate detectable signals (the "Tempest" problem). Martin Minow [EMAIL PROTECTED]
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
At 9:00 PM + 2/2/2000, lcs Mixmaster Remailer wrote: It may not have been mentioned here, but Intel has released the programmer interface specs to their RNG, at http://developer.intel.com/design/chipsets/manuals/298029.pdf. Nothing prevents the device from being used in Linux /dev/random now. As for the concerns about back doors, the best reference on the design of the RNG remains cryptography.com's analysis at http://www.cryptography.com/intelRNG.pdf. Paul Kocher and his team concluded that the chip was well designed and that the random numbers were of good quality. (Note, BTW that the RNG is extremely small, crammed into the margins of the device. An RNG which produced undetectably backdoored random date would probably be an order of magnitude larger.) I respect Paul, but there is a matter of principle here. Crypto is hard enough without having to rely on trusted experts to verify what should simply be made public. The business case for Intel's RNG secrecy is weak at best. I want to make it weaker. As for the RNG being crammed in, who knows what will happen in future chips? Even if Intel wanted to put in a back door, it would be very difficult to exploit it successfully. There is no way for the chip to predict how any given random bit will be used: it may go into a session key directly, it may be hashed through some kind of mixing function along with other sources of randomness, it may seed a PRNG which is then used to find RSA primes. There are a multitude of different possibilities and it would be hard in general to design an effective backdoor without knowing how the output will be used. I don't agree. All that is needed is for the backdoored RNG to produce an output stream that is determined by some state with a relatively small number of bits. Then an otherwise infeasible search strategy would become feasible. An attacker would still have to know how the program-under-attack used the RNG output, but we do not rely on software obscurity. (Of course if the RNG output is first mixed with another source of high entropy randomness then there is no added vulnerability. I am positing that, over time, vendors who use the Intel RNG will neglect this step.) And as pointed out before, this level of paranoia is ultimately self defeating, as Intel could just as easily put back doors into its CPU. Unless or until you are willing to use a self-designed and self-fabbed CPU, you are fundamentally at the mercy of the hardware manufacturer. CPU back doors are a different risk and are more subject to your first criticism than the RNG. Weak random number generation is a vulnerability common to almost all crypto systems. We should not lower standards in one area because there are risks in other areas. To paraphrase the Strategic Air command, "paranoia is our profession." Arnold Reinhold
RE: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
-Original Message- From: Arnold G. Reinhold [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 02, 2000 5:14 PM To: lcs Mixmaster Remailer; [EMAIL PROTECTED] Subject: Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support I respect Paul, but there is a matter of principle here. Crypto is hard enough without having to rely on trusted experts to verify what should simply be made public. The business case for Intel's RNG secrecy is weak at best. I want to make it weaker. As for the RNG being crammed in, who knows what will happen in future chips? One thing that is probably worth pointing out is that the Intel RNG isn't actually built into the CPU itself. The RNG is in the motherboard chipset, currently available on the Intel 810/820/840 chipsets. If you have a motherboard that does not contain the Intel 8x0 chipset then no matter what CPU you are running, you will not have access to the Intel RNG. Not that this changes anything about whether Intel should publish all the specs or not, it just seems that the posts so far have not been clear and some people may be confused. Regards, Jeff Gilchrist
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
On Wed, 2 Feb 2000, Martin Minow wrote: http://www.cryptography.com/intelRNG.pdf. The one problem I have with the RNG, based on my reading of the analysis, is that programmers cannot access the "raw" bitstream, only the stream after the "digital post-processing" that converts the bitstream into a stream of balanced 1 and 0 bits. It not only does that, it hashes the thing using sha-1. For all we know, the thing might be producing unacceptably small amounts of entropy for crypto purposes but large enough amounts that it hardly ever repeats. The work on the studying the output of Intel's RNG has only had accessed to the post-processed output, plus I believe a file directly from Intel which was claimed to be unprocessed output. Yeah ... right. If Intel wants people to trust them, they should quit acting like they're coving for bad engineering. -Bram
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
On Tue, Feb 01, 2000 at 09:00:33PM -0800, Dave Del Torto wrote: At 6:19 pm -0500 2000-01-26, Tom McCune wrote: Just in case anyone else is interested in my findings on whether I could use the Intel RNG with my Celeron machine: I needed help to find the driver installation file at the Dell site - I had searched for Intel RNG, but it can be found by searching for Intel Security Driver. It can be used by Celeron machines, but not mine::-( Tom, If you're right, this could be a *feature* of your Celeron, not a bug. Persons who shall remain nameless shared some info with me (under privacy lock: I'm not prepared to discuss the details they provided in public without permission) about the Intel RNG and how it was presented for review by various software vendors. Coupled with my experience in my former corporate security job where we "reviewed" limited aspects of similar Intel technology, I'm now just about on the same wavelength as Bill Geiger at this point (though our styles differ significantly, I respect Bill's learnéd opinion). This is to say that: (A) I'm not sanguine about it being a "default" in any version of PGP, knowing what I do and having been told more by others, (B) I strongly encourage the PGP engineering group to include and explicit checkbook preference/option for disabling PGP's use of the Intel RNG completely into v7.0, (C) I'm troubled that Intel has not yet --even at this late date-- provided comprehensive technical data on how the RNG works for public review and, (D) I'm extremely glad there doesn't appear to be one in my Mac or SparcStation, and my hand-built PC's have AMD K2/3's in 'em. ;) [..] I've also received Intel security info under NDA (and nothing in this post will violate same). I do not think that your point D is fair- even if the Intel RNG is totally and utterly compromised, it's not a threat to your security just by being there on the chip. Something has to call it and use it's output in a protocol. I do agree with point B however. Until Intel releases the design for the RNG, I would treat it the same as any suspect source of entropy- assume that it can contain no entropy. That means that you whiten its output before mixing it together with your other entropy sources (some of which you beleive do provide real entropy) to provide random numbers. If your entropy pool mechanisim would still provide good random numbers if it got a constant stream of zeros from the Intel RNG, then there's no harm that a compromised Intel RNG could do to your protocol. Don't use the Intel RNGs results directly in your protocols! Heck, I don't even do that for h/w RNGs I _do_ know the design of. Intel's refusal to publish info on their RNG could be because it's compromised, or because their security people (some of whom are ex- government) think that there is value to secrecy, or from some misguided "trade secret" intellectual property reason (RNGs being patentable and worth some money). Unfortunately none of those reasons are all that great. -- Eric Murray www.lne.com/~ericm ericm at the site lne.com PGP keyid:E03F65E5
Re: [PGP]: PGP 6.5.2 Random Number Generator (RNG) support
At 9:15 AM -0800 2/2/2000, Eric Murray wrote: On Tue, Feb 01, 2000 at 09:00:33PM -0800, Dave Del Torto wrote: At 6:19 pm -0500 2000-01-26, Tom McCune wrote: ... (A) I'm not sanguine about it being a "default" in any version of PGP, knowing what I do and having been told more by others, (B) I strongly encourage the PGP engineering group to include and explicit checkbook preference/option for disabling PGP's use of the Intel RNG completely into v7.0, (C) I'm troubled that Intel has not yet --even at this late date-- provided comprehensive technical data on how the RNG works for public review and, (D) I'm extremely glad there doesn't appear to be one in my Mac or SparcStation, and my hand-built PC's have AMD K2/3's in 'em. ;) [..] I've also received Intel security info under NDA (and nothing in this post will violate same). I do not think that your point D is fair- even if the Intel RNG is totally and utterly compromised, it's not a threat to your security just by being there on the chip. Something has to call it and use it's output in a protocol. I do agree with point B however. The threat to my security from Intel's RNG "just by being there on the chip" is that more and more encryption products will come to rely on the Intel RNG alone, or combined with some inadequate source of entropy like the system clock. Worse, more and more software vendors will adopt Intel's "trust us" attitude, and refuse to divulge details of their randomness generation. Some may even attempt to block reverse engineering that would expose their weaknesses, a la CSS. Intel's marketing department would love to have a long list of products that "take advantage" of their proprietary RNG scheme. The open cryptographic community should endeavor to keep that list as short as possible, at least until Intel repents and opens its design to public inspection and verification. Arnold Reinhold
