Re: [dsfjdssdfsd] getentropy(2)

Theodore Ts'o <> Tue, 15 July 2014 21:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A9C441B291F for <>; Tue, 15 Jul 2014 14:07:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id epzsHSePWLru for <>; Tue, 15 Jul 2014 14:07:01 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe96:be03]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA6961A00A3 for <>; Tue, 15 Jul 2014 14:07:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=NStWJqeNE0sxuEpq2ic3otNhxs0WlwRETkSiW31H7eI=; b=xRcR6GHqlvOx/omcVQUgtL9qTbPARtgj70aHHHTSEXAjflN8QF2Y3JVxKCAuFki+JGjkBktf/zYUYwgZUaE0Ak+o9wZr7E3o1bIKcBAOQamv2n2mYrwOiCNd6yfhFI2rz9nnUcfYhhmxFiCA2qlZTe3HK6qs9hZ1ekQyO4IX88s=;
Received: from root ( by with local-esmtp (Exim 4.80) (envelope-from <>) id 1X79wA-0002l9-5F; Tue, 15 Jul 2014 21:06:58 +0000
Received: by (Postfix, from userid 15806) id 06938580179; Tue, 15 Jul 2014 17:06:51 -0400 (EDT)
Date: Tue, 15 Jul 2014 17:06:51 -0400
From: Theodore Ts'o <>
To: Watson Ladd <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Cc: "" <>, Benjamin Kaduk <>
Subject: Re: [dsfjdssdfsd] getentropy(2)
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: Tue, 15 Jul 2014 21:07:04 -0000

On Tue, Jul 15, 2014 at 07:09:05AM -0700, Watson Ladd wrote:
> > Well, a large number of these uses should be done in the crypto
> > library -- since if the application writer can't tell the difference
> > between an IV and a session key, I'm not sure I want that person
> > anywhere near crypto code...
> What is the difference in how random they should be? There isn't one,
> and making it exposable in system policy invites
> all sorts of issues.

Some people believe, quite passionately, that there should be a
difference in at least some of those use cases.  NIST believes that
there is a difference between what is output by a DRBG and what a NRBG
which is used to seed a DRBG.  Presumably if you need to sell into the
US government market, you'll be forced to care as well, just as
companies who have US government customers are forced to deal with
FIPS whether or not it is actively harmful to security.

And I would *hope* that people would agree there should be a
difference between what is needed for a Monte Carlo simulation and
other various cryptographic use cases.  (I've gotten bug reports from
people who insisted on using /dev/urandom for Monte Carlo simulations,
and who then complained when it was too slow for their purposes....)

So my including Monte Carlo simulations was quite deliberate --- I can
pretty much guarantee some cluess graduate student will come across
the interface, and decide to use it, and if we list "monte carlo
simulations" as one of the options, hopefully they will chose it and be happy.

	     	       	   	    - Ted