Re: [TLS] RNG vs. PRNG
"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Wed, 28 April 2010 00:55 UTC
Return-Path: <prvs=1734df2002=uri@ll.mit.edu>
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 96C5D3A6A77 for <tls@core3.amsl.com>; Tue, 27 Apr 2010 17:55:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.998
X-Spam-Level:
X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 6M9vHZktKmrB for <tls@core3.amsl.com>; Tue, 27 Apr 2010 17:55:08 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id 6F8BF3A6A6A for <tls@ietf.org>; Tue, 27 Apr 2010 17:55:08 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o3S0stsJ016605; Tue, 27 Apr 2010 20:54:55 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "'mrex@sap.com'" <mrex@sap.com>, "'mike-list@pobox.com'" <mike-list@pobox.com>
Date: Tue, 27 Apr 2010 20:54:54 -0400
Thread-Topic: [TLS] RNG vs. PRNG
Thread-Index: Acrma6RwZQURyQElQdWW8JE2+qHVoQAAcXzA
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-27_18:2010-02-06, 2010-04-27, 2010-04-27 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004270239
Message-Id: <20100428005508.6F8BF3A6A6A@core3.amsl.com>
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: Wed, 28 Apr 2010 00:55:09 -0000
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 - regardless of what information you come by. Randomness of PRNG output depends on how secret the seed is, and if it (this secret) can be successfully attacked - all the output is compromised. (Assuming both RNG and PRNG are "ideal" - i.e. there's no known way to attack either algorithm or implementation.) Regards, Uri ----- Original Message ----- From: tls-bounces@ietf.org <tls-bounces@ietf.org> To: Michael D'Errico <mike-list@pobox.com> Cc: tls@ietf.org <tls@ietf.org> Sent: Tue Apr 27 20:42:03 2010 Subject: Re: [TLS] RNG vs. PRNG Michael D'Errico wrote: > > Here are all the places within my code that generate random > values and whether they are purely random or pseudo-random > (via a CPRNG): > > RNG generate RSA premaster secrets > RNG generate encryption key and HMAC secret used > for session ticket protection > > CPRNG generate (part of) session IDs > CPRNG generate initialization vectors > > CPRNG generate hello random values > CPRNG generate random premaster secret in server (as > part of defense against Bleichenbacher attack > and version rollback detection) > > These last two are debatable. Marsh would have the hello > randoms be purely random, not just unpredictable, and the > OpenSSL implementation uses a CPRNG for the last one, but > has a note that it /should/ use an RNG. > > IANAC, but wonder why the hello randoms would need to be purely > random, versus just unpredictable, since they go over the wire > in the clear? > > Also, does anyone know why the random premaster secret should > be generated with a real RNG versus a CPRNG? I am not a cryptographer either, but I believe that it should be OK to use CPRNG output for all of the uses in TLS, provided the CPRNG starts with a sufficiently large seed (like the equivalent of 128+ bits of real entropy) and an sufficiently large internal pool size (256+ bits) and peridical addition of fresh entropy to the pool. Concerning the terminology: RNG supposedly stands for a random number generator that produces consecutive output values that are completely uncorrelated CPRNG "cryptographic pseudo random number generator" supposedly stands for unpredictable random values that are mathematically correlated to the internal state of the CPRNG -- which reproduces in a mathematical correlation of consecutive CPRNG output values. Output values are normally derived with a compression function from a significantly larger internal state in a cryptographically secure fashion so that it is mathematically infeasible to determine the internal state of the CPRNG even for a larger sequence of output values, but some correlation remains. If randomness is needed for the creation of cryptographic keying material that is larger than the CPRNG output value, then a concatenation of consecutive CPRNG output values may leave tiny white spots in the resulting keyspace, caused by the intrinsic correlation of consecutive CPRNG output values. Increasing the size of the internal CPRNG state likely reduces the area of white spots in the resulting keyspace of concatenated CPRNG output values. Concatenating more CPRNG output values will likely increases the area of white spots. Although it might be extremely difficult to limit a brute force keyspace search to the non-white areas for a 3072 DSA or 4096 RSA keypair generated from concatenated CPRNG instead of concatenated RNG output values. For the premaster-secret and master-secret computations with the help of the PRF, I'm more concerned about the overall entropy than about correlation between concatenated CPRNG output values (unless, of course, the CPRNG internal state and output value sizes are patheticalls small (like 128/64 bits). -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- 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