Re: [dsfjdssdfsd] what not to do...

"Dan Harkins" <> Wed, 02 April 2014 18:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9D1D51A0370 for <>; Wed, 2 Apr 2014 11:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.267
X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xySuLEQ-24wB for <>; Wed, 2 Apr 2014 11:32:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 72F9C1A0368 for <>; Wed, 2 Apr 2014 11:32:41 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 84BA0A888016; Wed, 2 Apr 2014 11:32:37 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Wed, 2 Apr 2014 11:32:37 -0700 (PDT)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 2 Apr 2014 11:32:37 -0700 (PDT)
From: "Dan Harkins" <>
To: "Paul Hoffman" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "" <>, Theodore Ts'o <>
Subject: Re: [dsfjdssdfsd] what not to do...
X-Mailman-Version: 2.1.15
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: Wed, 02 Apr 2014 18:32:46 -0000

  Hi Paul,

On Wed, April 2, 2014 11:06 am, Paul Hoffman wrote:
> On Apr 2, 2014, at 10:34 AM, Theodore Ts'o <> wrote:
>> And if we try to tell people that if you can't do anything at all
>> which is True Entropy (tm), you might as well go home, then people
>> might just do that.
> That leads into the question of who the target audience for such a
> document should be. The committers for Linux and *BSD /dev/random don't
> need us to create a BCP for them; the writers of a new OS or distro might
> need it. An application writer should either (a) only be pulling from
> their OS or (b) be as smart about random sources as the OS dev so they can
> create their own pool. The eventual document needs to be very clear which
> person should be reading which part. The current document is completely
> unclear on this, and an application developer might think they need to
> understand things that we would be horrified if they tried to implement.

  The idea that linux and BSD developers know what they're doing and
application writers should just use their OS is an appeal to authority that
I think is increasingly falling on deaf ears these days. If you listened to
the experts at Intel you'd have just used their RNG because they know what
they're doing. But it turns out a hardware trojan can reduce the entropy
from their RNG to whatever the attacker wants it to be. Oops.

  Which is not to say that I think the people writing the RNGs for linux and
BSD do not know what they're doing, or that I know better (I certainly do

  Donald is updating an existing RFC and I think the target audience for his
update is the same as that of the existing RFC.

  My hope is that another draft will be written that specifies a strong RNG
and the target audience for that would be people writing security code,
especially for embedded OSs that have a more blurred line between kernel
and application.