From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 20:06:39 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 274BAED for ; Fri, 18 Jul 2014 20:06:39 +0000 (UTC) Received: from manchester-1.man.uk.cluster.ok24.net (manchester-1.man.uk.cluster.ok24.net [213.138.100.64]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AEC522990 for ; Fri, 18 Jul 2014 20:06:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=07.2014; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=NN4E/as0CAQdfv0x5iDb0aBpo3Cs4qPrbOhgOTv+Wzk=; b=yAOzSnlmkzCO+J4+lB4KQHn3cTkQ2qt0+xqxgr38SG+N+zwYVAZT+e5WZ9ZtPfdyWZXgsf2TpF0wbCcjSqYT9x5+mYYgpJ6BEfabPGQGVK/u/L9amhBjqVwpHGzYttA/c3DkyNppdyyBnvw+q2FCCJHmWmoEbqDfqoVNY73MBBw=; X-Spam-Status: No, score=-1.1 required=2.0 tests=ALL_TRUSTED, BAYES_00, DKIM_ADSP_DISCARD Received: from guisborough-1.rcc.uk.cluster.ok24.net ([217.155.40.118]) by manchester-1.man.uk.cluster.ok24.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1X8EQK-00011c-Hm; Fri, 18 Jul 2014 21:06:34 +0100 Received: from [10.0.1.191] by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1X8EQJ-0000e3-Nd; Fri, 18 Jul 2014 21:06:32 +0100 Message-ID: <53C97E47.4030100@pyro.eu.org> Date: Fri, 18 Jul 2014 21:06:31 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.6.0 MIME-Version: 1.0 To: Leif Pedersen Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org" 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: Fri, 18 Jul 2014 20:06:39 -0000 On 18/07/14 20:01, Leif Pedersen wrote: > I believe one of Steven's points was (I'm fairly sure I understood him > correctly) that neglecting to reseed after fork() has led to problems. Yes, it's one of many things that has gone wrong in the past. It's been pointed out to me that OpenBSD solved that particular issue with MAP_INHERIT_ZERO: the state of the arc4random PRNG is zeroed out on forking, and it knows to reseed then. FreeBSD since r227520 (2011-11-15), calls getpid() on every arc4random_buf call, to see if the pid has changed since it seeded, and thus reseed. It was shown recently (in the context of LibreSSL Portable) that this may not work in a contrived corner-case, so there they added an atfork handler, but again might not always be called. *If* getpid involves a syscall on every arc4random_buf call, that is going to already going to limit its performance? Would it really be any slower to just return random bytes from the kernel, with the KERN_ARND sysctl? The overhead of currently having to initially and periodically seed RC4, discard the early keystream, and apply that cipher thereafter, would be gone. The risk of the problem described above, or of weaknesses in RC4, or implementation issues with arc4random's PRNG seeding are also gone. And if FreeBSD's kernel CSPRNG wasn't trusted already, the arc4random PRNG is badly seeded and untrusted anyway. arc4random wasn't doing anything to supplement with entropy gathered from userland (which seems to be the belt-and-braces approach taken by OpenSSL). I don't suppose there's a risk of exhausting entropy by reading too much via the sysctl, or else an unprivileged user could do that already. Yarrow should already handle this. I very much welcome critique here, I think that's a necessary part of design and evolution of security code. I think we should periodically look at what we have to make sure it still holds up to scrutiny, even if it 'aint broke (as far as we know). Please point out any wrong assumptions you think I've made, even if it seems obvious. > will have exactly the > same initial state if there is no provision to reseed the PRNG. There is arc4random_stir, but an application could easily forget to do that. Users of libevent for example, which uses arc4random, doesn't expose an API function to do an explicit stir if the application forks. Regards, -- Steven Chamberlain steven@pyro.eu.org