Re: [dsfjdssdfsd] getentropy(2)

Watson Ladd <> Tue, 15 July 2014 14:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 47B791A03F9 for <>; Tue, 15 Jul 2014 07:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D8UCv3JJvk_9 for <>; Tue, 15 Jul 2014 07:09:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03E9A1A03DE for <>; Tue, 15 Jul 2014 07:09:05 -0700 (PDT)
Received: by with SMTP id 20so1651634yks.1 for <>; Tue, 15 Jul 2014 07:09:05 -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=vG+cfbOWeI6sDdNa+nJu8Wa1A8zHAqnkrNy2cKqullw=; b=ogy0OxTwR14E/v5wF/DFLb8Fu/1+RgJChzufGDxVxrMEeaGbD7EuNVpBD9d9uG02At zHuJfRnDEyRyz+FJEDZ9pLgjwcSANp/rPDKuJFn5i/CvLxp5qUQEHbs7oUsGcXECUP+c C0aCujZagb7uksRUWOEsaPVFX94zCHppXNpituBX8ccqpkkY4hxqJ4VYhGqsidvZmUzD GFH10i7pJqUAtRdhdK4+fOd8Z9tWuieUny6VfyYuZ3ZTr+n7lN20Op3IXsctgwTz0Crl x7sbzoQlqvtgf6sXvSW93xtVYPLi5RSytcoT/YSnq1k57zHgrH6yR9i7I4MO4IMtitbL IOYg==
MIME-Version: 1.0
X-Received: by with SMTP id z70mr40443234yhz.107.1405433345334; Tue, 15 Jul 2014 07:09:05 -0700 (PDT)
Received: by with HTTP; Tue, 15 Jul 2014 07:09:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 15 Jul 2014 07:09:05 -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: Tue, 15 Jul 2014 14:09:07 -0000

On Tue, Jul 15, 2014 at 6:13 AM, Theodore Ts'o <> wrote:
> On Tue, Jul 15, 2014 at 08:39:07AM -0400, Benjamin Kaduk wrote:
>> I'm not confident that [all] application writers will even be competent to
>> correctly choose amongst the 5 listed uses [plus whatever others might be
>> added].  If it stays a small number of easily identified things, it might
>> still be better than only exposing the blocking/nonblocking-ness directly,
>> but it doesn't seem clear-cut to me.
> 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.

>> BTW, FreeBSD exposes a sysctl MIB (CTL_KERN.KERN_ARND) to get entropy
>> directly, saving syscalls over open("/dev/[u]random")/read()/close().
> That only matters if you want to encourage applications to be
> constantly asking the kernel to generate numbers, though, yes?  I'm
> arguing that it might be better to have a standardized userspace
> library, ala OpenBSD's arc4random, which takes care of all of the OS
> specific issues, and also provides a crypto-based DRBG.  In that case,
> it saves even more syscalls, since it only needs to read entropy from
> the kernel at application startup time, and perhaps periodically every
> so often when it wants to reseed, but not every single time you need
> crypto-sensitive padding, IV's, session keys, etc.

getentropy(2) could  be getentropy(3). What's more important is what I
want it to do
- Block if the random system is not initialized (or return a return
value indicating failure)
- Return random numbers, even if I've forked or have a multithreaded process
- Do so promptly

Currently on Linux none of the available options work. Forking
requires a post-fork call, /dev/random blocks constantly, and
does not block on startup. I'm probably going to open /dev/urandom:
it's the best current alternative.

Perhaps arc4random is better to imitate: I don't really care. I just
need it to work and ship yesterday.

Watson Ladd
(And don't use RC4 for it!)
> Cheers,
>                                                 - Ted
> _______________________________________________
> dsfjdssdfsd mailing list

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