Re: [dsfjdssdfsd] getentropy(2)

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 562651B28B7 for <>; Tue, 15 Jul 2014 06:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.952
X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 83r2B1qVld7f for <>; Tue, 15 Jul 2014 06:13:28 -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 01C2A1B28B2 for <>; Tue, 15 Jul 2014 06:13:27 -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=V8CQ6PnbF863n3a/eXOFi/hoKlQpdarx6D2+ipgwWa0=; b=irL/esNOWwlcnbiNbEnNmZj6ilJmUyf5HB8QLnSACK32UPSfK5WS2gW+UFWwZ2Y+F4oRgpki3f1zgx2JEB8n3fltSbjWGGmkLs0bFVolDw8f088ZJ3c6/mNq23IqbA9qTcwtCuKK0aJfvNn5UgWdxB9gzI0/UVJnq3rQ0dRRx0g=;
Received: from root ( by with local-esmtp (Exim 4.80) (envelope-from <>) id 1X72Xu-0007Oq-LU; Tue, 15 Jul 2014 13:13:26 +0000
Received: by (Postfix, from userid 15806) id B7F9A5803B7; Tue, 15 Jul 2014 09:13:21 -0400 (EDT)
Date: Tue, 15 Jul 2014 09:13:21 -0400
From: Theodore Ts'o <>
To: Benjamin Kaduk <kaduk@MIT.EDU>
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: "" <>
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 13:13:29 -0000

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

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


						- Ted