From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 14:26:06 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 B29333E6 for ; Fri, 18 Jul 2014 14:26:06 +0000 (UTC) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 839332A16 for ; Fri, 18 Jul 2014 14:26:06 +0000 (UTC) Received: from [10.20.30.90] (50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s6IEQ2UI073029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 07:26:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-60.dsl.dynamic.fusionbroadband.com [50.1.51.60] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Speed and security of /dev/urandom From: Paul Hoffman In-Reply-To: <53C85F42.1000704@pyro.eu.org> Date: Fri, 18 Jul 2014 07:26:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> References: <53C85F42.1000704@pyro.eu.org> To: Steven Chamberlain X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 18 Jul 2014 15:38:13 +0000 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 14:26:06 -0000 On Jul 17, 2014, at 4:41 PM, Steven Chamberlain = wrote: > Hi, >=20 > FreeBSD is as far as I know, quite unique in using Yarrow to provide a > nice, fast CSPRNG for /dev/urandom >=20 > But OpenSSL, LibreSSL, OpenSSH, and various reimplementations of > arc4random(), don't directly use it. They typically take only ~128 = bits > from /dev/urandom or through other means, to seed a stream cipher, = then > return the output of that. I understand why Linux, even OpenBSD must = do > that. Good-quality random bits from the kernel are scarce, so they > *must* be stretched somehow. >=20 > But isn't that essentially what Yarrow does already in FreeBSD? Yes, for many values of "essentially". This is a discussion that always = ends in a rathole. > Is there a good reason arc4random_buf() can't take bytes directly from > /dev/urandom or sysctl KERN_ARND? Therefore no longer needing to seed > first, periodically reseed, or use any stream cipher? The "good reason" is the same as above: doing so would cause so much = discussion and animosity that it is not worth doing. >=20 > There are a few reasons I mention it now: >=20 > * arc4random relies on the stream cipher being cryptographically = strong > between reseeds, or else you could guess previous/later output. = FreeBSD > still uses RC4 for arc4random, and that seems increasingly risky; > OpenBSD moved recently to ChaCha-20, but who knows if even that will > prove to be safe in the longer term? >=20 > * after seeding, some arc4random implementations completely forget to > reseed after the process forks - the same 'random' stream of bytes = could > occur twice, with security implications >=20 > * LibreSSL tried to detect forking, and to reseed automatically, but > Andrew Ayer showed a corner-case where that still didn't work as > expected (CVE-2014-2970) >=20 > * some arc4random implementations might not be thread-safe >=20 > * (re)seeding can fail sometimes (fd's exhausted reading /dev/urandom, > or that is missing in a chroot; even a sysctl might return an error > code); OpenSSL and LibreSSL each have 'scary' ways to try to gather > entropy in userland as a fallback, especially for Linux; FreeBSD and > OpenBSD may have better expectations that the sysctl will work, and > maybe raise SIGKILL otherwise >=20 > So I wonder, could a simplified arc4random for FreeBSD use Yarrow > directly, to avoid making any of these sorts of mistakes we've seen? Yes, it "could". Whether it "should" is another question on a different = layer. >=20 > (There's also the benefit that having many readers from a single > pseudorandom stream, adds an additional kind of randomness to its = output). How does having an additional *reader* add additional bits? > This is obviously a complex issue, and some of it will be subjective. > But I welcome your comments. Thanks! Subjective wins. --Paul Hoffman=