Re: [TLS] RNG vs. PRNG
Dean Anderson <dean@av8.com> Thu, 06 May 2010 17:15 UTC
Return-Path: <dean@av8.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CEE63A67EF for <tls@core3.amsl.com>; Thu, 6 May 2010 10:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.522
X-Spam-Level:
X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lqyy5gsxJ4cd for <tls@core3.amsl.com>; Thu, 6 May 2010 10:15:20 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id A5DF43A695F for <tls@ietf.org>; Thu, 6 May 2010 10:15:08 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (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, 06 May 2010 13:14:47 -0400
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Nicolas Williams <Nicolas.Williams@oracle.com>
In-Reply-To: <20100505062823.GW9429@oracle.com>
Message-ID: <Pine.LNX.4.44.1005061259060.30940-100000@citation2.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] RNG vs. PRNG
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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) [0..47]; 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) --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 256 5494
- Re: [TLS] RNG vs. PRNG Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] RNG vs. PRNG Nicolas Williams
- Re: [TLS] RNG vs. PRNG Marsh Ray
- Re: [TLS] RNG vs. PRNG Steven Bellovin
- Re: [TLS] RNG vs. PRNG Dean Anderson
- Re: [TLS] RNG vs. PRNG Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] RNG vs. PRNG Nicolas Williams
- Re: [TLS] RNG vs. PRNG Kemp, David P.
- Re: [TLS] RNG vs. PRNG Marsh Ray
- Re: [TLS] RNG vs. PRNG Nicolas Williams
- Re: [TLS] RNG vs. PRNG Dean Anderson
- Re: [TLS] RNG vs. PRNG Martin Rex