Re: [TLS] RNG vs. PRNG

Dean Anderson <> Wed, 05 May 2010 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C92AE3A697A for <>; Tue, 4 May 2010 18:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.558
X-Spam-Status: No, score=-0.558 tagged_above=-999 required=5 tests=[AWL=-0.559, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uQMkD4Isls8X for <>; Tue, 4 May 2010 18:09:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6C3D83A6954 for <>; Tue, 4 May 2010 18:09:44 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id o4519K3V003546 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 4 May 2010 21:09:23 -0400
Date: Tue, 4 May 2010 21:09:19 -0400 (EDT)
From: Dean Anderson <>
To: Steven Bellovin <>
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: "''" <>
Subject: Re: [TLS] RNG vs. PRNG
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 May 2010 01:09:53 -0000


On Tue, 4 May 2010, Steven Bellovin wrote:

> On Apr 27, 2010, at 10:22 26PM, Nicolas Williams wrote:
> > On Tue, Apr 27, 2010 at 08:54:54PM -0400, Blumenthal, Uri - 0668 - MITLL wrote:
> >> From practical point of view an important difference between RNG and
> >> PRNG is that it is (in practice, realistically) impossible to
> >> compromise a "true" RNG - its random output is not reproducible, and
> >> there's no way to purposefully get the same sequence from it -

If the RNG is truely random, it can not be biased either.  The bias is
the introduction of a non-random input; and by definition, a true RNG
has no non-random inputs. So a 'biased RNG' is just the discovery that
the device once thought to be an RNG was not one after all.

> > But there may be ways to attack the method by which the RNG works so as
> > to bias it.  Whereas there's no way to do that for a PRNG.  In general
> > it seems best to couple an RNG to a PRNG, using the former to seed and
> > periodically replenish the entropy pool of the latter, thus removing
> > biases from the RNG stream.
> That's right.  Put differently, PRNGs have high behavioral assurance;
> if they're right, they'll continue to be right.  An RNG can be
> affected by the environment in all sorts of nasty analog ways.  This
> is one reason why in the Clipper chip design, the NSA used a PRNG to
> generate the unit keys.
> 		--Steve Bellovin,

Actually, the above is precisely wrong. 

PRNG's have statistical behaviors, as I described in an earlier post.  
However, some PRNGs (with statistically good behavior) have been
successfully analyzed by various methods, most impressively (to me) by
phase space analysis.

This claim by Bellovin's is most definitely not true of PRNGs: "if
they're right, they'll continue to be right".  PRNGs that are 'right'
have been broken in the past.  PRNGs can have bitwise statistical
properties and appear hard to predict, and still be subject to (eg)
phase space analysis.

I suspect the NSA most likely used PRNG's in Clipper because PRNGs were
practical to implement whereas RNGs are not. Or perhaps it was a mistake
altogether; Recall that Clipper was broken.

It is definitely not because PRNGs can't be biased or analyzed.  Just
look at phase space analysis for DNS servers (BIND and DJBDNS), as well
as similar cracking on the GPS PRNG 'variation' that prevents commercial
units from getting the most accurate readings.  The GPS variation is
programmed into and corrected by military units, but not commercial
units. The 'variation' feature was supposed to prevent our enemies from
getting a super-accurate position.  GPS was broken shortly after 
commercial units became widely available.


Av8 Internet   Prepared to pay a premium for better service?         faster, more reliable, better service
617 256 5494