Re: [dsfjdssdfsd] specifying an RNG

Donald Eastlake <> Fri, 15 November 2013 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C950C11E81A5 for <>; Fri, 15 Nov 2013 07:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.247
X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_SUB_11CONS_WORD=0.352, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PG4n9fUJ1zyx for <>; Fri, 15 Nov 2013 07:11:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::229]) by (Postfix) with ESMTP id CF54011E80F5 for <>; Fri, 15 Nov 2013 07:11:25 -0800 (PST)
Received: by with SMTP id wn1so3990572obc.14 for <>; Fri, 15 Nov 2013 07:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ueB9vcKjGGbZGKszYbL8+9EjDTwd+CxW6RYziop7knE=; b=W/H4bh7B7b745XrcQ7It1eesVWU/shJ3rVptzMPRs5lp0Ar24693tBOt8ZCpkK2Ddj IxAhBvV/LnO9jlutN6DzaXOlv1e3IaEWTbQUAv/xG0ZWr/KLVnqII7vo6R86x0sIhh6o 4+c91rovOmVThYUz+2MuJ1PCxE+ADjEjaIULBKDL4USlqhiUMkiaRpNZD3vf9HyOSZAE 6EVRYsoHZj41M5OUOYIXlENv6s4GCIJGwDE8u0X7SCqg/aqCcLv2sUgF2l1SGYo3tnCZ 3oBwDU9UaaMCW3eh++jiyrFBR5BdGldUym0YGmaEeruIikYAeHxey7wX4dcXSky1n3nM q/DA==
X-Received: by with SMTP id d14mr1003419obt.99.1384528281318; Fri, 15 Nov 2013 07:11:21 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 15 Nov 2013 07:11:01 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Donald Eastlake <>
Date: Fri, 15 Nov 2013 10:11:01 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="e89a8fb1fcac63bda404eb389c31"
Subject: Re: [dsfjdssdfsd] specifying an RNG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Nov 2013 15:11:35 -0000


On Fri, Nov 15, 2013 at 5:55 AM, Eric Burger <>
> On Nov 15, 2013, at 12:55 AM, Dan Harkins <> wrote:
>>  Hello, and welcome to the dsfjdssdfsd list!
>>  At the last IETF the question was asked, "what can we do to harden
>> the Internet?" Given the recent news about Dual_EC_DBRG and the
>> dopant attack against hardware RNGs one of the things that can be
>> done is to have an open specification of a secure RNG.
> I like this idea.
>> This would
>> allow developers to have an alternative to relying solely on
>> /dev/[u]random, a hardware RNG, an RNG specified by a large
>> government-affiliated group to mix the uncorrelated sources of
>> entropy they gather, or an RNG designed in an ad hoc manner by
>> someone who thinks he knows what he's doing but probably
>> doesn’t.
> History is nice, but if we produce a *standard*, one would hope the
developer goes to /dev/IETFrandom. I.e., none of the issues listed above
are relevant.
>>  One of the things that would be nice to get out of this list is a
>> specification on a strong RNG, in the form of a BCP or Informational
>> RFC. This doesn't necessarily mean lets "roll our own" but perhaps
>> there is best practice that can be specified.

RFC 4086, which is on this topic, is a BCP but is out of date and doesn't
recommend a specific random number generator.
is the start of an effort towards a replacement but needs a lot of work.

By the way, not that I am arguing for or against it for this case, but it
is quite possible for a BCP or IETF standard to consist of a set of RFCs…

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

> How is this any different than today’s practice? Today we point to NIST,
FIPS, NSA, RSA, ISO, Government Committee of the Russia for Standards, etc.
>>  So, is there a model that defines what a "robust RNG" would look
>> like? Is there a suitable candidate that exists already for such a thing?
> I am still having trouble understanding what would be different than what
we do today. If you are proposing something akin to the open source codec
work, then I am only just a bit skeptical, but I was proven wrong by that
effort (it seems to be succeeding). However, if all we are doing is looking
for a RNG to put into IETF standards, then are we not doing that already?