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

Paul Hoffman <> Wed, 02 April 2014 18:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BE9751A0326 for <>; Wed, 2 Apr 2014 11:07:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.747
X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3dOeKLs9QeRH for <>; Wed, 2 Apr 2014 11:06:58 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by (Postfix) with ESMTP id 130791A035C for <>; Wed, 2 Apr 2014 11:06:58 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.8/8.14.7) with ESMTP id s32I6qVJ087233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 11:06:53 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Paul Hoffman <>
In-Reply-To: <>
Date: Wed, 2 Apr 2014 11:06:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: "Theodore Ts'o" <>
X-Mailer: Apple Mail (2.1874)
Cc: "" <>
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:07:03 -0000

On Apr 2, 2014, at 10:34 AM, Theodore Ts'o <> wrote:

> On Wed, Apr 02, 2014 at 10:02:24AM -0700, Paul Hoffman wrote:
>> Personally, I have a strong hesitation of a BCP using phrases like
>> "a few bits of entropy" if we can't measure them and if we don't
>> even know if they exist.
> One of the problems is that there is a lot of nuance which is
> required.  For example, if you can't change the hardware, on a mobile
> device, one of the few sources of unpredictability might be the radio
> strength --- if you grab this in early boot and if you know that the
> values aren't being fed via centralized logging scheme.  It's not
> really _entropy_ per se, but if you are assuming that someone sitting
> in Fort Meade won't know whether your cell phone is in your knapsack
> under the steel desk, or on top of the desk, it probably does add a
> certain amount of protection.
> Ditto grabbing touch screen information; sure, if someone has a camera
> surveilling you, it might not have much unpredictabiliy, but it's
> still probably a good thing to mix into your entropy pool.

Fully agree. We should talk about possible sources, but we should be careful to say that we are not suggesting how many bits (or fractions of a bit) those sources produce. The implementer of the RNG is fully responsible for making the source-to-bit-count assumptions.

> 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.

--Paul Hoffman