Re: [TLS] RNG vs. PRNG

Nicolas Williams <> Wed, 05 May 2010 22:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 991DC3A6AEB for <>; Wed, 5 May 2010 15:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.332
X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YkKTEM21iBiF for <>; Wed, 5 May 2010 15:26:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B3B223A6D28 for <>; Wed, 5 May 2010 15:26:01 -0700 (PDT)
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45MPkgH018597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 May 2010 22:25:47 GMT
Received: from ( []) by (Switch-3.4.2/Switch-3.4.1) with ESMTP id o45KXiBj005054; Wed, 5 May 2010 22:25:45 GMT
Received: from by with ESMTP id 240583321273098245; Wed, 05 May 2010 15:24:05 -0700
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 May 2010 15:24:04 -0700
Date: Wed, 5 May 2010 17:24:00 -0500
From: Nicolas Williams <>
To: Marsh Ray <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: []
X-CT-RefId: str=0001.0A090208.4BE1F06B.0161:SCFMA4539811,ss=1,fgs=0
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 22:26:03 -0000

On Wed, May 05, 2010 at 05:02:37PM -0500, Marsh Ray wrote:
> On 5/5/2010 1:28 AM, Nicolas Williams wrote:
> > I'm not sure what the point of this sub-thread is.
> The currently language in the spec is broken and misleading to the point
> that people (implementers) are unclear about the requirements for
> various protocol structures.
> It's entirely within the scope of the spec to specify what properties of
> various structures (e.g., premaster secret) are required for security.
> The current specs do talk about it, but people seem to come away with
> different meanings because the terminology is inconsistent.
> In the case of client_hello.random and server_hello.random, I believe
> that even though they are sent in-the-clear they need to be
> crypto-quality unpredictable (and of course reveal no information about
> any secret internal state).

This is really the province of RFC4086/BCP0106.  TLS has no business
having different entropy requirements than other security protocols (set
aside for now the fact that having weak entropy sources will have
varying impact depending on the use).  As such there are better fora
than the TLS WG for this discussion.

In any case, we've not exactly been debating what properties we need for
*RNGs for TLS.  We've instead ratholed into a "true RNGs are better"
"are not" situation.

> > Also, none of this is new; the subject has been
> > exhaustively treated before, thus we're just annoying uninterested TLS
> > WG list subscribers and wasting our own time.
> I agree that some of this is a tiny bit annoying, it bugs me that
> everyone isn't on the same page with the terminology. I don't understand

Welcome to the world of... well, this world.

> why anyone would confuse a raw thermal noise source with a
> well-constructed RNG (e.g., a healthy /dev/random), with a deterministic
> PRNG (e.g. TLS's PRF), and so on.

We don't have good, standard terminology.  Some people don't mean
PRNG-seeded-with-static-seed-and-maybe-a-counter when they speak of
PRNGs, but others interpret "PRNG" to mean just that and then treat the
first as idiots.  Trouble ensues.  I agree, we need common terminology.

> Still, it seems pretty important that the next revision of the spec (or
> some other IETF document) conveys the requirements clearly enough that
> insecure implementations don't get shipped.

I don't agree.  The next revision, like the current one, should
reference RFC4086, though we might want a normaitive reference instead
of an informative one.  We might also want a standard, rather than just
a BCP, on entropy.  Also, BCP0106 should have a glossary.