From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 22:03:17 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 4B4EAEB1; Sat, 19 Jul 2014 22:03:17 +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 D54BE2315; Sat, 19 Jul 2014 22:03:16 +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=HnzpeLzG8UidtQ515OxVbmoz5rwWeb+72LJabJ00vJI=; b=lArdNjV78Tuc8QntU12TzE2g0mw8VAGFkHY3CCHWbERzbv+DLs3bD6rtyKqz5SHO2sD24iZxpUOlpg/sP/xfQ0NR4cQJX7/bwOYA7CvhmEdB0KfDVdYitoKTJFAeJuryuQSbXrU9FYnDkL7R0ZQdAHNFEYJJe6PgUsh4sjcdvyM=; 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.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80) (envelope-from ) id 1X8cim-0005dM-70; Sat, 19 Jul 2014 23:03:13 +0100 Received: from [10.0.1.191] by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1X8cil-0000CM-6g; Sat, 19 Jul 2014 23:03:11 +0100 Message-ID: <53CAEB1E.2020401@pyro.eu.org> Date: Sat, 19 Jul 2014 23:03:10 +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: Ben Laurie Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-security@freebsd.org security" 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 22:03:17 -0000 On 18/07/14 22:57, Ben Laurie wrote: > Discovering that its OK to use this mechanism seems as vulnerable to > mistakes as the mistakes we've seen. I don't have good suggestions on > how to fix this. I know, this is a scary subject. There is wisdom in a belt-an-braces approach, to keep the PRNG in userland in case the kernel's CSPRNG is weak or glitches sometimes. A counter-example in my mind is the Debian OpenSSL bug - the CSPRNG was accidentally broken and its 'bulletproofing' meant there was still about 15 bits of entropy from getpid, gettimeofday and such. That allowed 2 years to pass before the real problem was noticed, and by then weak keys/certificates were in production use, causing the real damage. If a PRNG is not working, I'd prefer it to output a stream of zeroes, or at least the same sequence on everyone's system so that it is noticed very quickly. I think the amount of code would be reduced and some current concerns become irrelevant if the userland PRNG went away. We already expect the kernel CSPRNG is good if we're seeding from it, and it is used for other things that are important. Or if we're worried about draining entropy too quickly from the CSPRNG, a non-privileged user could do that anyway from /dev/urandom, or it may happen when a server doing crypto work is under stress? Regards, -- Steven Chamberlain steven@pyro.eu.org