From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 21:05:41 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CC3E31D for ; Sat, 19 Jul 2014 21:05:41 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6D582EAE for ; Sat, 19 Jul 2014 21:05:40 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id m15so4754388wgh.17 for ; Sat, 19 Jul 2014 14:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=JCgGHdrp/Jbq90R1/yXcCqXvLOvrHU+p9skYXM2eOgg=; b=seg3lFlvZTZfPPTXxMN0oovx/9XXD1HhF2HxJXSkqnXdYiKY0W/V010rM2s9JNoU/P 5vlJYBaRdj2tGmTbjaIa9SvskjUefTKZXRERED/H3cIpnYL96ZLCuvgfzaslcGOZcDvT RFf8Sh77y7hRWqo8k5tVBXloPrwm7CUcynZ6Os5NRBUaZddg7vX9SPsrBMnIrntEWQo9 jTxA5cseguZEgOwBYRpzkokXALXkiqwFV4YHsma15e9np7As5turyouKApOTujJHICVP pQp3JyhsrdCooy8gDKKbvUQCYPnMIU/QYsRw/GxSptDjYXHGcLVjknLipqRFotm0fwHl SNpA== X-Received: by 10.180.95.136 with SMTP id dk8mr19272176wib.8.1405803938119; Sat, 19 Jul 2014 14:05:38 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id jb16sm22146511wic.10.2014.07.19.14.05.36 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 19 Jul 2014 14:05:37 -0700 (PDT) Date: Sat, 19 Jul 2014 23:05:34 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719210534.GA4630@dft-labs.eu> References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> <53CAD950.1010609@pyro.eu.org> <20140719205350.GX93733@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140719205350.GX93733@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, Steven Chamberlain X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 21:05:41 -0000 On Sat, Jul 19, 2014 at 11:53:50PM +0300, Konstantin Belousov wrote: > On Sat, Jul 19, 2014 at 09:47:12PM +0100, Steven Chamberlain wrote: > > On 19/07/14 20:26, Konstantin Belousov wrote: > > > I think that using sysctl for non-management functionality is wrong. > > > If this feature is for the libraries and applications, and not for > > > system management and introspection utilities, it should be normal > > > syscall. > > > > If this is only to seed the arc4random in userland (with ~256 bytes or > > so), it would be just like OpenBSD getentropy(2)? > > > > Just yesterday, something very similar is proposed for Linux, called > > getrandom(2): > > http://lists.openwall.net/linux-kernel/2014/07/18/329 > > We, in fact, do not use sysctl for seeding SSP canary. Kernel puts > random bytes on stack, and libc fetches them. But it is 64 bytes for > 64-bit platforms, 32 bytes for 32-bit. > > Yes, the interface of the getrandom(2) from the link above looks > reasonable. The big question is, indeed, about its supposed use > models. For one-time seeding of RNG with fixed amount of bytes, > the ELF aux vector mechanism is much less intrusive and faster. I believe the idea here is to have reliable source for reseeding after fork. -- Mateusz Guzik