Re: [TLS] RNG vs. PRNG

Dean Anderson <> Thu, 06 May 2010 17:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CEE63A67EF for <>; Thu, 6 May 2010 10:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.522
X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lqyy5gsxJ4cd for <>; Thu, 6 May 2010 10:15:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A5DF43A695F for <>; Thu, 6 May 2010 10:15:08 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.12.11/8.12.11) with ESMTP id o46HEmgR016539 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 6 May 2010 13:14:48 -0400
Date: Thu, 6 May 2010 13:14:47 -0400 (EDT)
From: Dean Anderson <>
To: Nicolas Williams <>
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: Thu, 06 May 2010 17:15:22 -0000

On Wed, 5 May 2010, Nicolas Williams wrote:

> I'm not sure what the point of this sub-thread is.  

The point of the draft is to extend the random bits.  So a question 
related to that is: "Is anything to be gained by having more 'random' 
bits?"  This sub-thread, in part, answers that question.

The real random value is pre_master_secret. The purpose of the 
*Hello.random additions is to ensure a unique master_secret on 
additional channels. These have no contribution to the security of the 
random set chosen for pre_master_secret:

master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)

The master_secret has 48 bytes, the pre_master_secret has 48 bytes. One 
cannot add "more randomness".  Hence the conclusion is this:

1) One cannot add more "randomness" into the calculation. Either 
pre_master_secret is a true random number or it isn't. 

2) Since the *Hello.random bit set is publicly exposed, using the same 
random generator for these as for pre_master_secret would potentially 
expose the [P]RNG to analysis and thereby expose pre_master_secret as 
well as *Hello.random. If all the inputs to the PRF are known, then 
master_secret is known.

> TLS can't really mandate that implementations use real RNGs

I agree. So we have to assume that some [many] implementers will use 
PRNGs and so exposing these bits to analysis is a very bad thing(tm).

> > True RNG "itself" can't be attacked - though its implementations could
> > (depending on many circumstances). Attacks against PRNG could be both
> > cryptanalytic and implementation-directed.
> A true RNG depends on physical processes.  Therefore it can be attacked
> by physical means.  

Perhaps in principle, the RNG could be tampered with so future bits
aren't random. But the past bits would remain secure. So having a log of
messages encrypted with a true RNG remain unbreakable, even if you
subseqently tamper with the RNG.  This would not be true of a PRNG. Once
you gain the seed, you can compute any output.

> The simplest thing to do is to couple an RNG to a PRNG.

No. A PRNG only generates a subset of the input: equal in size to the
size of the seed. PRNGs reduce entropy to the size of the seed. 

Design Rule: You can't get better than a real RNG. Once you have that,
you can only make it worse. (I suspect that stems from thermodynamics)


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