Re: [dsfjdssdfsd] getentropy(2)

Watson Ladd <> Wed, 16 July 2014 05:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E33B1B2A74 for <>; Tue, 15 Jul 2014 22:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oSjvb_I5fNeQ for <>; Tue, 15 Jul 2014 22:03:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 75BBF1B2A64 for <>; Tue, 15 Jul 2014 22:03:52 -0700 (PDT)
Received: by with SMTP id 131so212521ykp.18 for <>; Tue, 15 Jul 2014 22:03:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QnrDFY4zwiCjhW70Zlm8joMl4pHwI09fG2XuSaxIcPo=; b=nDnZGTtBFEC55EG/9edtE//aM2lVrvJq9sGzxJEniuEOQvR1bTrI1ft3DpW1ySp8RQ h2ambOwNUQgvRzecr71Rolr5HMdVgLTV2hWCHmMRrJacjAjF9gy2zAvvbUHPhwmgjvJ+ jwHVTkoY+2blqlwm5BfS9lIS2yRZrQwPjTb+8BvUD1mtfQA8ZflNZOAG1vCVLusgRLof ZR1uQodU8RnmzqbWOECRryfb4Lo30xnZSMtbeBppDJCogCMPNPCkxRnYnhevz7aGb9K/ BDbKL9h0PVTmFYXD4zm0E/YU/VkEvyHN30MbxqNUsIIQcKrZHQs8t6cpo5e8JY7rQcNF Cmaw==
MIME-Version: 1.0
X-Received: by with SMTP id f5mr47787457yhf.63.1405487031717; Tue, 15 Jul 2014 22:03:51 -0700 (PDT)
Received: by with HTTP; Tue, 15 Jul 2014 22:03:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 15 Jul 2014 22:03:51 -0700
Message-ID: <>
From: Watson Ladd <>
To: Theodore Ts'o <>
Content-Type: text/plain; charset="UTF-8"
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: Wed, 16 Jul 2014 05:03:54 -0000

On Tue, Jul 15, 2014 at 2:06 PM, Theodore Ts'o <> wrote:
> 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.

OpenBSD supplies both getentropy(2) and arc4random(3). I need at least
one of these.
Make getentropy(2) the seed, and arc4random(3) the RNG. Also, just
because you have a portable
method not suitable for everyone doesn't mean you can't have a
nonportable one for niche uses like
getting seeds.

The problem is only partly /dev/urandom vanishing in chroots. It's the
fact that every system has
a different way to do things, so cross-platform compatibility is
difficult. Just stick with a good idea,
and use arc4random(3).

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

If the library lives in userspace it can be fast enough, even while
using AES or HMAC to generate the random samples.
> 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

Watson Ladd

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin