From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 00:02:40 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 2E176D41 for ; Fri, 18 Jul 2014 00:02:40 +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 BAF972042 for ; Fri, 18 Jul 2014 00:02:39 +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:Subject:To:MIME-Version:From:Date:Message-ID; bh=QYo2mw8XWBHDIuq2G7f/D/4fR4VWY9rZULLB2Syufbo=; b=IWDITGroc6Ma6zWsBYGzfbPcMJAyuiT3CPuvJ3SYJx8L6YZXeP+rGO+aGAczrMVQCkBhQ2ALi2Ssjt9X0I+31kn37GMeCC+k95/B3zcwu3cl+9CF8m1vsTpFPNOrbDZLpan83jzl9HfA7ES7nBj8np91yJDbohxa3yTnaePHy9E=; 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 1X7vJD-0006ez-RX for freebsd-security@freebsd.org; Fri, 18 Jul 2014 00:41:57 +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 1X7vJD-00013o-Bx for freebsd-security@freebsd.org; Fri, 18 Jul 2014 00:41:55 +0100 Message-ID: <53C85F42.1000704@pyro.eu.org> Date: Fri, 18 Jul 2014 00:41:54 +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: freebsd-security@freebsd.org Subject: Speed and security of /dev/urandom X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 00:02:40 -0000 Hi, FreeBSD is as far as I know, quite unique in using Yarrow to provide a nice, fast CSPRNG for /dev/urandom 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. But isn't that essentially what Yarrow does already in FreeBSD? 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? There are a few reasons I mention it now: * 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? * 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 * 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) * some arc4random implementations might not be thread-safe * (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 So I wonder, could a simplified arc4random for FreeBSD use Yarrow directly, to avoid making any of these sorts of mistakes we've seen? (There's also the benefit that having many readers from a single pseudorandom stream, adds an additional kind of randomness to its output). This is obviously a complex issue, and some of it will be subjective. But I welcome your comments. Thanks! Regards, -- Steven Chamberlain steven@pyro.eu.org 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= From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 18:20:07 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 DE69B72A for ; Fri, 18 Jul 2014 18:20:06 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 52FE12FD5 for ; Fri, 18 Jul 2014 18:20:05 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so3147847lbd.36 for ; Fri, 18 Jul 2014 11:19:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=V76cdOviVzmREDFpW/adxhHCf5O/rJO47TjfnWGgIB0=; b=cmyvle/Dy+WbRf0RatysJF7bdJAQD5qcO+n+zV1ip/3B5bGMUcu/tQouU2BycHnYUT VB42kA9qFXxZ6qOO+8WzlpTS5qy8iJV3sMSoKAo7QdEl474WuIgNwGOPVPN6CEbsDgWv gZCiEFaETayTo9KBrTmfKdsR3iuSpcgGqDjWfZo2onh412AYUXM0XoquxeLFl0ub1/XU G9CcCVUIBH4Rb3KnOBttXkfgy0uSo9C1+PLwCFl1zbLx+F2quHdKH6lzRs/JTwz9Oge9 BGKWQ01iRkmRZLV7RLW+yenIsq5x4+rrmKY8biGMIMkcYfjZUzaELCbHMdEzZAaoLEjG j5zA== X-Gm-Message-State: ALoCoQn/aGryfGJ2/lyFD34uPfBJs6QcKxRAa/00My31R61OyDIq/FaVbc5ipded4USoHTToY1Bk X-Received: by 10.152.3.65 with SMTP id a1mr7349891laa.76.1405707598470; Fri, 18 Jul 2014 11:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.149.65 with HTTP; Fri, 18 Jul 2014 11:19:18 -0700 (PDT) X-Originating-IP: [24.111.146.222] In-Reply-To: <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> From: Leif Pedersen Date: Fri, 18 Jul 2014 13:19:18 -0500 Message-ID: Subject: Re: Speed and security of /dev/urandom To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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: Fri, 18 Jul 2014 18:20:07 -0000 On Fri, Jul 18, 2014 at 9:26 AM, Paul Hoffman wrote: > On Jul 17, 2014, at 4:41 PM, Steven Chamberlain > wrote: > > > * 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 > This is a compelling argument to avoid doing crypto in isolation. One need not do it in the kernel to avoid this (could implement a userland crypto with a daemon that exports a pipe/socket), but the approach of seeding an isolated algorithm that could wind up cloning it's memory space and therefore the seed for the next value seems suboptimal. > > (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? > > The extra readers interrupt the position of the stream, so that it is harder to predict the next value. This only works if one instance of the PRNG is shared by multiple readers, rather than each reader operating in isolation. > This is obviously a complex issue, and some of it will be subjective. > > But I welcome your comments. Thanks! > > Subjective wins. > It's disappointing when emotions bewilder clear rational thinking. I think his point is well stated. Seeding a PRNG from another PRNG (such as seeding arc4random from FreeBSD's Yarrow-backed /dev/random) increases risk since if the seed is compromised then the dependent is also. Not to confuse that with xoring the output of two PRNGs, which can't hurt and may help. I read that sending all hardware randomness through Yarrow is in response to the questionable trustworthiness of hardware randomness; fair enough. It then seems to me that all programs should leave stretching the randomness to the kernel (or other shared resource) rather than instantiating arc4random or the like and only spooning out a little of the result to seed. That way, if the algorithms or randomness backing /dev/random is compromised, one need only patch one piece of software rather than many. Better yet, an operator can potentially choose this or that algorithm system-wide with sysctl, if multiple become available and one is compromised. In the final analysis, if OpenSSL really can't trust /dev/random, then it should xor the stream from /dev/random with its internal arc4random stream, not merely seed arc4random from Yarrow, but even better to solve the trust problem in the kernel rather than solve it selfishly in OpenSSL only for OpenSSL. - Leif -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 19:08:17 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 4BD8CAC for ; Fri, 18 Jul 2014 19:08:17 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 B63C32472 for ; Fri, 18 Jul 2014 19:08:15 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so3185455lbd.36 for ; Fri, 18 Jul 2014 12:08:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B8aTfzEKbYGm0nbzmXCmlW1o9JL7m68DOaEBcsDHUCY=; b=TbriXyqo46wyzV7y1OsTv+N9Ps5I9Ai0sYx51ysqHLvMe2ujiAQPTB3B/E0B7ykUKF 3myPVJuYb677yxwqXf4p68Klyh+6b8FCEPHIbAdSpFTP+iIn7TP0uKR2M2yaP+3QQaOL o8NukGJn1a50ZysJ5QPHX0aFM0jvRgwQX6QjUf38evybEwGf4iWQwjVtaqQwjcVx4da5 FuBM6Vapg0SjFptHUCvplJdT5VpNPEn3cUFQXYzKGVjhDSzzj6pb0DMLeJNitqD9Mmdc OZ8jZ12gSXP2eiASpOJNONj1/3kPOE0rsRJffAO5nrAYQ/kvZmNgJU1a7+qrPK2nrDO8 fWhw== X-Gm-Message-State: ALoCoQnGTnyrSBs6AqF31t8Rc2Lzh8bEVKd1QBGdUNfvH7p4W3KOmjcFXR+0iPFvhssCqjg7W3a9 X-Received: by 10.152.25.229 with SMTP id f5mr7342236lag.87.1405710153191; Fri, 18 Jul 2014 12:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.149.65 with HTTP; Fri, 18 Jul 2014 12:01:53 -0700 (PDT) X-Originating-IP: [24.111.146.222] In-Reply-To: References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> From: Leif Pedersen Date: Fri, 18 Jul 2014 14:01:53 -0500 Message-ID: Subject: Re: Speed and security of /dev/urandom To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 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: Fri, 18 Jul 2014 19:08:17 -0000 On Fri, Jul 18, 2014 at 1:28 PM, Paul Hoffman wrote: > On Jul 18, 2014, at 11:19 AM, Leif Pedersen wrote: > > > The extra readers interrupt the position of the stream, so that it is > harder to predict the next value. This only works if one instance of the > PRNG is shared by multiple readers, rather than each reader operating in > isolation. > > If there was a non-zero chance that an attacker could predict the next > value, your PRNG was already broken. Two of the fundamental properties of a > working PRNG is that if an attacker sees any number of outputs from the > PRNG, the attacker cannot compute any previous values and the attacker > cannot predict any future values. > > if(! fork()) { int x = next_value(); // Do something that depends on the sensitivity of x here. } else { // exec untrusted program here... // distrusted program: int x = next_value(); printf("Known value: %i\n", x); } This has nothing to do with the quality of the PRNG or being otherwise compromised. It's that after being seeded the PRNG operates in isolation and the memory space is cloned exactly. PRNGs run on computers which are currently deterministic, so there is no algorithm that can yield different values for x in the two branches. Crypto libraries frequently fork untrusted processes, for example sshd accept()s, fork()s, does crypto, switches users, and forks a shell. Every child would have the same initial state at the "does crypto" part, and so must be reseeded. Web servers work similarly. Apache is more complicated because one child accepts many connections, but ultimately they always terminate and are replace by another sibling which will have exactly the same initial state if there is no provision to reseed the PRNG. 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. - Leif -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig 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 From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 20:37:29 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 F23509A9 for ; Fri, 18 Jul 2014 20:37:29 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 799CE2C34 for ; Fri, 18 Jul 2014 20:37:28 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so3298858lam.0 for ; Fri, 18 Jul 2014 13:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yVAgYtgGIMW8sAMZM5YULCbHMHiJwj2WqF8JjQxV6uU=; b=hxgcres0Da2OdXUU0WPGxBOnhJOBjuRgc0qPDnB16DOkR8IlmUtbJug/s8jA5NK2ZL +yQwuTJDHqR+FtxC9oHhGn5yXg7MwGSf8Wo5Ub669Jwd3iQBJcHbRk0RHJGwISkYbZiz fHI9mZ+cXLXnNdTB9fA94uKqHlTIvCijii/e0ZBA052kJcMCGJtzVgwBqST/csfq9AZv jkKeXfWZUJZ7wC1zj6nB/ySH8556el0I7V9R90l5HpnHzgu0Gz2LXx5f5KyG6bjfNczV aNcOc2MbK2uep+Rrqwom85lFi1vm3HeBeDdYi9g15tKnA0aQMwabDoj35ThSI7Cv1Rbw gGMw== X-Gm-Message-State: ALoCoQmlTqm5/HVCeLASIP++XwRhIfmKYn6x32mmfIN8PrRzTqL18UB/hUQw0M6U6skkoDWijPp6 X-Received: by 10.152.87.207 with SMTP id ba15mr7952668lab.15.1405715841185; Fri, 18 Jul 2014 13:37:21 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id jk5sm10962869lbc.26.2014.07.18.13.37.20 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 13:37:20 -0700 (PDT) Message-ID: <53C9857D.6000806@freebsd.org> Date: Sat, 19 Jul 2014 00:37:17 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Chamberlain , freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> In-Reply-To: <53C85F42.1000704@pyro.eu.org> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit 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:37:30 -0000 On 18.07.2014 3:41, Steven Chamberlain wrote: > 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? One of the reason I hear is that true random entropy bits can be quickly exhausted if every userland program will drain them so much. -- http://ache.vniz.net/ From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 20:42:18 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 30A8BC84; Fri, 18 Jul 2014 20:42:18 +0000 (UTC) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 B0BB62CF8; Fri, 18 Jul 2014 20:42:17 +0000 (UTC) X-AuditID: 1209190d-f79c06d000002f07-7b-53c986a1b036 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BB.7C.12039.1A689C35; Fri, 18 Jul 2014 16:42:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s6IKg8iC028646; Fri, 18 Jul 2014 16:42:09 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6IKg6Qo007572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Jul 2014 16:42:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6IKg66F010708; Fri, 18 Jul 2014 16:42:06 -0400 (EDT) Date: Fri, 18 Jul 2014 16:42:06 -0400 (EDT) From: Benjamin Kaduk To: Andrey Chernov Subject: Re: Speed and security of /dev/urandom In-Reply-To: <53C9857D.6000806@freebsd.org> Message-ID: References: <53C85F42.1000704@pyro.eu.org> <53C9857D.6000806@freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixCmqrbuw7WSwQftUK4tjJ3qYLHo2PWGz WHBpCrsDs8eMT/NZPI6+/8UUwBTFZZOSmpNZllqkb5fAlXFx+12mgkOsFW/3z2BtYNzJ0sXI ySEhYCJx+vsnZghbTOLCvfVsXYxcHEICs5kkFjWeY4ZwNjJKvHszCypziEni788fTCAtQgIN jBKr7hqA2CwC2hJnTneyg9hsAioSM99sZAOxRQRUJa5+nQG2glnAU+LgvF9AcQ4OYQF9ic2H pEHCnECtLzZPACvhFXCUuLlsDSNIiRBQ+cm7FSBhUQEdidX7p7BAlAhKnJz5hAVioqXEv7W/ WCcwCs5CkpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcMBK8u5g fHdQ6RCjAAejEg/vDq2TwUKsiWXFlbmHGCU5mJREeac1AoX4kvJTKjMSizPii0pzUosPMUpw MCuJ8DqVA+V4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8G1uBGgWL UtNTK9Iyc0oQ0kwcnCDDeYCGx4HU8BYXJOYWZ6ZD5E8xKkqJ8yaBJARAEhmleXC9sITyilEc 6BVh3g0gVTzAZATX/QpoMBPQYOny4yCDSxIRUlINjFU88zpmmt+wMtz5dQvft3SuW35r/Vr6 VC/xrqpKKWVXkuG9Vjehwpff64588qVFJXe/78ud8uucg9TM1dO2eV57G26xae6zp76tyqc9 zOx/Gm+bfe/jQX+heyZ9s3+pGD0UdnzwtkLxnPGcZQ6vU/zl52vkZd1gDmD+7cIgL9u9sS14 LruNoBJLcUaioRZzUXEiACY5iLYDAwAA 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: Fri, 18 Jul 2014 20:42:18 -0000 On Fri, 18 Jul 2014, Andrey Chernov wrote: > On 18.07.2014 3:41, Steven Chamberlain wrote: >> 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? > > One of the reason I hear is that true random entropy bits can be quickly > exhausted if every userland program will drain them so much. Once the DRBG is seeded with a sufficient amount of truly random bits ("entropy"), its output remains unpredictable essentially indefinitely. There is no "loss" or "draining" of entropy from the system over time unless the algorithm is lousy. -Ben From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 20:49:33 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 7FE6EE09 for ; Fri, 18 Jul 2014 20:49:33 +0000 (UTC) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 037532D5F for ; Fri, 18 Jul 2014 20:49:32 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id s18so3270707lam.14 for ; Fri, 18 Jul 2014 13:49:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7YHzVZw5W5WKQB67ce/+4IAQAHPfnYRvgVWXwCJtnq8=; b=AcfJlfrzPijvlsNRRAw8jLPFyvi/RT/f5PlJe8zhI1aoUPqLcMtkfZfmtoMq88TNzy XXx93mFN+GWq5RfuJxMUepVP5qgFkNSmbvbeSqW5+/t/aG4Iop25oOIusQvJKAQIqWC5 uR6KCZOi7CgEO9qyO+ArBdTzbiWMuQHH+jYFAg41BeAkyU+8QFGmME3ywjYPVGBvc5FN lNfEbuVRURDYTbEJQC8TlUjOIKFT25RcNuRdENbNLAJEG33rIjD+l0lPe/TunBVRcPlD dh/JqOyLDvRG41Rvb20ICf7IGHcOvajtN+QMjyKSaOFrJDxPNOmc3d6BojhLAeCoDYIU 7ARA== X-Gm-Message-State: ALoCoQkbKTsNCXZwvYk+qd2iefzuG/PtGGib/WnwvTw9Tw2VLmSzhKrGyuN0YVFturX1EcpVV1jW X-Received: by 10.112.30.99 with SMTP id r3mr7973040lbh.14.1405716570940; Fri, 18 Jul 2014 13:49:30 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id xk7sm5272756lac.10.2014.07.18.13.49.30 for (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Jul 2014 13:49:30 -0700 (PDT) Message-ID: <53C98857.8060603@freebsd.org> Date: Sat, 19 Jul 2014 00:49:27 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Steven Chamberlain , Leif Pedersen Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> <53C97E47.4030100@pyro.eu.org> In-Reply-To: <53C97E47.4030100@pyro.eu.org> Content-Type: text/plain; charset=KOI8-R 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:49:33 -0000 On 19.07.2014 0:06, Steven Chamberlain wrote: > 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. I always say that calling getpid on every arc4random call is ugly and should be replaced by something. pthread_atfork belong to another library and MAP_INHERIT_ZERO is not currently implemented. -- http://ache.vniz.net/ From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 20:53:07 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 491EC181 for ; Fri, 18 Jul 2014 20:53:07 +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 052DB2E15 for ; Fri, 18 Jul 2014 20:53:06 +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:To:MIME-Version:From:Date:Message-ID; bh=hwpLYTN3cHciVVARnx0SwYOc6fR8utSmOOBFPwLg0J0=; b=N0M0BdhY2fvxrvJx1yUliLDtzVxYX2AgTbwX6taUsgMqJk4YVLL7CGKUZWLggUhub7ypClly74LetWiVB0trAkzS8nnXFJRuVHXs26WU11u9dWU87gG/47kXaBxMWSSXlXm9nX4bZhnnglOLitvXcM7Q1NXlaZ82+eanT15QXxc=; 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 1X8F9L-0001Aa-56 for freebsd-security@freebsd.org; Fri, 18 Jul 2014 21:53:04 +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 1X8F9K-0002jQ-Ea for freebsd-security@freebsd.org; Fri, 18 Jul 2014 21:53:02 +0100 Message-ID: <53C9892D.1050002@pyro.eu.org> Date: Fri, 18 Jul 2014 21:53:01 +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: freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> <53C9857D.6000806@freebsd.org> In-Reply-To: <53C9857D.6000806@freebsd.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit 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:53:07 -0000 On 18/07/14 21:37, Andrey Chernov wrote: > One of the reason I hear is that true random entropy bits can be quickly > exhausted if every userland program will drain them so much. True of Linux at least, I assume that's why they must make /dev/random block when the estimated entropy in the pool is low. Applications have been encouraged to not excessively read even from /dev/urandom, for the same reason, so it makes sense on Linux to stretch with RC4 or something. Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 18:28:22 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 C240193D for ; Fri, 18 Jul 2014 18:28:22 +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 98AC120E9 for ; Fri, 18 Jul 2014 18:28:22 +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 s6IISJnN083835 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Jul 2014 11:28:20 -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: Date: Fri, 18 Jul 2014 11:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> To: Leif Pedersen X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 18 Jul 2014 21:52:22 +0000 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: Fri, 18 Jul 2014 18:28:22 -0000 On Jul 18, 2014, at 11:19 AM, Leif Pedersen wrote: > The extra readers interrupt the position of the stream, so that it is = harder to predict the next value. This only works if one instance of the = PRNG is shared by multiple readers, rather than each reader operating in = isolation. If there was a non-zero chance that an attacker could predict the next = value, your PRNG was already broken. Two of the fundamental properties = of a working PRNG is that if an attacker sees any number of outputs from = the PRNG, the attacker cannot compute any previous values and the = attacker cannot predict any future values.=20 --Paul Hoffman= From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 21:57:40 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 5AF8B2FF for ; Fri, 18 Jul 2014 21:57:40 +0000 (UTC) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (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 1D2E3238F for ; Fri, 18 Jul 2014 21:57:40 +0000 (UTC) Received: by mail-qa0-f43.google.com with SMTP id w8so3434659qac.2 for ; Fri, 18 Jul 2014 14:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5E3N9G7BqZHcomE/qijZ01R0N2dFXI9fr5+VgIn4C14=; b=OIxFfwqx06eRZfPGvVIWuQjJT39jF2g0fnfVjVlh2x/c3Ant6a8sidOvG1ioSQSUNe x/gPk1h65wg7D57/jkYWJ1HMOLfHxqc99Gt0eC2tbwgaDF5cih02pP0+CEw47oAmugY0 uHGuGRSW/ytY28pnn7M3oekk4g2nZy/uP43L4k26iYDSTJKoL1do+yNLalc4nP0OcEZX qz7AKA+v7gROhyBEWyOTFN0JivUTzHkuc/3oBQCdAriiKWaphkkei/nCgrGYKTZ1tf1M EJYvQtrD9oNx1hZd4Cn4crV6bnstOzwUruA7GZc5C7fDDUlqKuhhTev7lp2RpHkib4FI A4PQ== MIME-Version: 1.0 X-Received: by 10.224.129.130 with SMTP id o2mr13544580qas.64.1405720659199; Fri, 18 Jul 2014 14:57:39 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.222.168 with HTTP; Fri, 18 Jul 2014 14:57:39 -0700 (PDT) In-Reply-To: <53C85F42.1000704@pyro.eu.org> References: <53C85F42.1000704@pyro.eu.org> Date: Fri, 18 Jul 2014 22:57:39 +0100 X-Google-Sender-Auth: 1CkjCmnG2gk8COXnUTFN1UCkT5I Message-ID: Subject: Re: Speed and security of /dev/urandom From: Ben Laurie To: Steven Chamberlain Content-Type: text/plain; charset=UTF-8 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: Fri, 18 Jul 2014 21:57:40 -0000 On 18 July 2014 00:41, Steven Chamberlain wrote: > So I wonder, could a simplified arc4random for FreeBSD use Yarrow > directly, to avoid making any of these sorts of mistakes we've seen? 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. From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 22:10:59 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 5E6836F5 for ; Fri, 18 Jul 2014 22:10:59 +0000 (UTC) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 E8BB02515 for ; Fri, 18 Jul 2014 22:10:58 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id w61so5136631wes.23 for ; Fri, 18 Jul 2014 15:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=OtyLPkWaI2kdjJIsWpJlmz0kxNeX1I+nBRf1XStcTLY=; b=c3EsZvbAQljKkPL4LW3SUYxzMPrH7AcgH1AzSVIVPpl9AVUt6gP7Nqs+BgPVvVLnIP LcMG1UXm/j+A3y0FAapq6Pc7VxN1XhQDY9IHLe60UORQH6N2y+or6E0BqBZUOjsIbtmE lsKx1XWDutRFxVh9bG0yKvES8MO/8aGxNfDIphrRY8vLb6vpL/OXRTF5GGtzdkPT9rJW lV6MEYo2z3BVnz9i1NpLVjRVUQ4vRTCEZf35mvSNLmfoevGQjYYIRsfnI250wECFM34x pfxn3ydpPtitmzWgwxxQRnYZiC/SNqqTCAJP4XDlegYoAA63hIvzBJN/Ez/CWDgMT6ZA KTsQ== X-Received: by 10.180.92.38 with SMTP id cj6mr12050241wib.64.1405721457109; Fri, 18 Jul 2014 15:10:57 -0700 (PDT) Received: from gumby.homeunix.com (4e5670bd.skybroadband.com. [78.86.112.189]) by mx.google.com with ESMTPSA id fw4sm11141749wib.19.2014.07.18.15.10.55 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Fri, 18 Jul 2014 15:10:56 -0700 (PDT) Date: Fri, 18 Jul 2014 23:10:53 +0100 From: RW To: freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom Message-ID: <20140718231053.3251d0b7@gumby.homeunix.com> In-Reply-To: <53C97E47.4030100@pyro.eu.org> References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> <53C97E47.4030100@pyro.eu.org> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 22:10:59 -0000 On Fri, 18 Jul 2014 21:06:31 +0100 Steven Chamberlain wrote: > *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? I think KERN_ARND uses the kernel version of arc4random rather than Yarrow - unless something changed. > 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. The RANDOM kernel module may not be present, particularly in a stripped-down embedded kernel. In that case yarrow isn't present in the kernel, and kernel arc4random isn't securely seeded. An application may then securely seed userland arc4random via arc4random_addrandom(). Supporting that requires at least the possibility to fall back to a userland PRNG. From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 19:03:56 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 0EA023F2 for ; Sat, 19 Jul 2014 19:03:56 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E09AD250B for ; Sat, 19 Jul 2014 19:03:55 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6JJ3m6r004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 12:03:49 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6JJ3mW7004475; Sat, 19 Jul 2014 12:03:48 -0700 (PDT) (envelope-from jmg) Date: Sat, 19 Jul 2014 12:03:48 -0700 From: John-Mark Gurney To: Steven Chamberlain Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719190348.GM45513@funkthat.com> Mail-Followup-To: Steven Chamberlain , freebsd-security@freebsd.org References: <53C85F42.1000704@pyro.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C85F42.1000704@pyro.eu.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 19 Jul 2014 12:03:49 -0700 (PDT) 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: Sat, 19 Jul 2014 19:03:56 -0000 Steven Chamberlain wrote this message on Fri, Jul 18, 2014 at 00:41 +0100: > FreeBSD is as far as I know, quite unique in using Yarrow to provide a > nice, fast CSPRNG for /dev/urandom > > 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. > > But isn't that essentially what Yarrow does already in FreeBSD? > > 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? Wow, am I really seeing this right, that kern.arc4rand doesn't use the same interface that /dev/random/ uses? And there isn't a sysctl interface to /dev/random? This really needs to b e fixed... > There are a few reasons I mention it now: > > * 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? We should move arc4random to just using the same interface as /dev/random, or, if you're talking about arc4random(3), we should just convert arc4random(3) to using the sysctl... Though this introduces a standard problem... People are using an implementation (arc4random) instead of a generic give me x interface, though it looks like there isn't a way to directly seed the arc4random pool, so hopefully people are expecting to use this to get reproducable random numbers (for testing)... > * 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 > > * 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) > > * some arc4random implementations might not be thread-safe > > * (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 Yes, if there is an error from the sysctl or something, the process should abort or something similar... > So I wonder, could a simplified arc4random for FreeBSD use Yarrow > directly, to avoid making any of these sorts of mistakes we've seen? I assume you mean convert arc4random(3) to use the sysctl, or? > (There's also the benefit that having many readers from a single > pseudorandom stream, adds an additional kind of randomness to its output). Per other person's comment, this shouldn't matter if you have a good PRNG... > This is obviously a complex issue, and some of it will be subjective. > But I welcome your comments. Thanks! So, my suggestions: 1) Convert arc4random(9) in the kernel to use the random pool as /dev/random uses. I vaguely remeber there being an issue w/ arc4random(9) being used early in boot before /dev/random is initalized which would complicate this change... 2) Convert arc4random(3) to use the sysctl, and if the sysctl fails, kill the process. There are also some other improvements that can be made to the /dev/random frame work, but those are more code cleanup, not security related changes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 19:26:10 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 9E06B79D for ; Sat, 19 Jul 2014 19:26:10 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 0E76A26CB for ; Sat, 19 Jul 2014 19:26:09 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6JJQ52b002267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 22:26:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6JJQ52b002267 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6JJQ5PW002266; Sat, 19 Jul 2014 22:26:05 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Jul 2014 22:26:05 +0300 From: Konstantin Belousov To: Steven Chamberlain , freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719192605.GV93733@kib.kiev.ua> References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Gx/Ih+SeBVJCvkYs" Content-Disposition: inline In-Reply-To: <20140719190348.GM45513@funkthat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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 19:26:10 -0000 --Gx/Ih+SeBVJCvkYs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Jul 19, 2014 at 12:03:48PM -0700, John-Mark Gurney wrote: > So, my suggestions: > 1) Convert arc4random(9) in the kernel to use the random pool as > /dev/random uses. I vaguely remeber there being an issue w/ > arc4random(9) being used early in boot before /dev/random is > initalized which would complicate this change... > 2) Convert arc4random(3) to use the sysctl, and if the sysctl fails, > kill the process. 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. Being syscall, it also solves the issue of backward-compatibility, i.e. a new code, running on old kernel, get SIGSYS when using non-existing syscall. If application is so sophisticated that it want to handle the situation, it can, by installing a signal handler. Otherwise, it is terminated automatically. --Gx/Ih+SeBVJCvkYs Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTysZMAAoJEJDCuSvBvK1BEIkP/jMFy5Rx4fpQ2PDYcmdp94wt gMGmwws0mlerSZ7X/FKqQ5drlppeGbTuQoFw7+zIli4mDImTnDEIZ2tBdAVOFmOs OQrutmvoWfUweS2H0kSRcVBKqqII6OaUpSQ2t4ikBCQV5Ww0HooOm9gvm6e23ZPV XTVJx1AMz6HM+Ama+cFsmvUwvsNLWXLQSOdfIdYFjiRTolEAFO0Cx4LqRt7ENWnS G57ztrYjPTA3fegbaSdN24Wg8BkRjtJrWr2SqJeJu2Uy1ZoIrUwRz63HC74+B/ym TLfYqPPoNSDFov+JhoYvaln50K6V3guXx3xhzWNbM4cm2k0CoB4OfeDiwJhHdFg8 IvaQZrSywiH0Bx0G1ZzjVZiBFq4It0iB2u1vwXGkfjL9Rpbh9yBCkDVijuTl0eYd 7qUQY20txEJ2Y28ZWxuJyXik2H+ltAa2rkX52qBRyKH/SKyEYgoijpMmD1iJStPy H8QzN45scHFpS0KTbuPRI7pq3ISg+TJ3iJUSeVfRCBGPwXe/ZZcs4MUfD2+WPObK J6mHeNLID5/xkR4mJA7xdZ71XPIeFG4pTjVZFXHCwrAwMDpDqg+txdoetCv7ElZA dnh6Z3qRv5QFJjZ2RWfUHemkcJOXhtxHLdugDfrvh7oZf32Xu1oYlJ0Zh2nqJ7Ws /UXqCb0gLK7wqYafer9o =F+gt -----END PGP SIGNATURE----- --Gx/Ih+SeBVJCvkYs-- From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 20:17: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 7E379461 for ; Sat, 19 Jul 2014 20:17:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3A78B2AF8 for ; Sat, 19 Jul 2014 20:17:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6JKHaDJ005405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 13:17:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6JKHawF005404; Sat, 19 Jul 2014 13:17:36 -0700 (PDT) (envelope-from jmg) Date: Sat, 19 Jul 2014 13:17:36 -0700 From: John-Mark Gurney To: Konstantin Belousov Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719201736.GN45513@funkthat.com> Mail-Followup-To: Konstantin Belousov , Steven Chamberlain , freebsd-security@freebsd.org References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140719192605.GV93733@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 19 Jul 2014 13:17:37 -0700 (PDT) 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 20:17:39 -0000 Konstantin Belousov wrote this message on Sat, Jul 19, 2014 at 22:26 +0300: > On Sat, Jul 19, 2014 at 12:03:48PM -0700, John-Mark Gurney wrote: > > So, my suggestions: > > 1) Convert arc4random(9) in the kernel to use the random pool as > > /dev/random uses. I vaguely remeber there being an issue w/ > > arc4random(9) being used early in boot before /dev/random is > > initalized which would complicate this change... > > 2) Convert arc4random(3) to use the sysctl, and if the sysctl fails, > > kill the process. > 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. Though in the past we've been discouraged from adding new syscalls, why, I don't know... I'm fine w/ this, though we have had the sysctl for over 7 years.. so, using a sysctl will introduce anoying backward compatibility issues, do you call back to the sysctl when the syscall isn't there? how do you make the new code handle old OS's? We can't remove arc4rand since old apps depend upon it... apprently the sysctl was added for SSP: https://svnweb.freebsd.org/changeset/base/169727 > Being syscall, it also solves the issue of backward-compatibility, > i.e. a new code, running on old kernel, get SIGSYS when using > non-existing syscall. If application is so sophisticated that > it want to handle the situation, it can, by installing a signal > handler. Otherwise, it is terminated automatically. Though broken applications (which there are many), could install SIGSYS and ignore it still.. :) broken apps are broken, not handling an error is broken.. yes it's easier w/ SIGSYS, but not perfect... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 20:47:33 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 109CCA6C for ; Sat, 19 Jul 2014 20:47:33 +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 975D52D24 for ; Sat, 19 Jul 2014 20:47:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=07.2014; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=wF4xBy6NQYycUo+c6457sJ/fh5YKQMSHcwoOE0Qku5o=; b=xIF15E+Y7itzfOsg81pQnysIO1asKMLY6DwagX9XLGizbJaGqBG6PNyue604e/wjPdhO8ttX2VC3htukzAFjMBVb0H9fGnSFca6iwMpdVTuqrXCMZ+tyIpU/3TUUM4bpXB4XL2ot7pc7JgLvyFxoM5LibQfPARzmiz90dAh+vgo=; 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 1X8bXN-0005Pq-Ka; Sat, 19 Jul 2014 21:47:23 +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 1X8bXM-0005ax-LB; Sat, 19 Jul 2014 21:47:20 +0100 Message-ID: <53CAD950.1010609@pyro.eu.org> Date: Sat, 19 Jul 2014 21:47:12 +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: Konstantin Belousov , freebsd-security@freebsd.org Subject: Re: Speed and security of /dev/urandom References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> In-Reply-To: <20140719192605.GV93733@kib.kiev.ua> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hLvdpv21lS3oPbUFC8JOBeBsopI815V9j" 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 20:47:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hLvdpv21lS3oPbUFC8JOBeBsopI815V9j Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 Regards, --=20 Steven Chamberlain steven@pyro.eu.org --hLvdpv21lS3oPbUFC8JOBeBsopI815V9j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBCAAGBQJTytlQAAoJEJeL0N0LpZiv26QH/0C0p1mNsDlmPGRqZoUplWci RpoVLaL1UA2eXNWDwekv3muaRmVj4HhIUmS1MxbaOB25UaOcSl4opzl5EfGQbUAu IxTjOJCZ7IZxFgCRSCv146QBeZc9xhIic43wo9pH7MLSjew5x4PSyhQHl1CTnECl Sp/XJbuLkqdbNieWRmJDOeIQjQSHG+HOBpO6AlnjhVx7ndgxQXqcWfEqOhu9zYNd Rh0lY4NGcjspqqFmcPctB0SOpD0WQl2LkgIUSJyKlBusb2sVkkL039Rs1iiru5lI RmvZWAUtvRGfdNtZAtFYP2Yhba7le+iwvURlYn4P3k6p6ITM0aF58ztU+6443uM= =pnnz -----END PGP SIGNATURE----- --hLvdpv21lS3oPbUFC8JOBeBsopI815V9j-- From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 20:54:00 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 6E89BB96 for ; Sat, 19 Jul 2014 20:54:00 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (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 EC3D22DC0 for ; Sat, 19 Jul 2014 20:53:59 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s6JKroV2021925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Jul 2014 23:53:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s6JKroV2021925 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s6JKro87021924; Sat, 19 Jul 2014 23:53:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 19 Jul 2014 23:53:50 +0300 From: Konstantin Belousov To: Steven Chamberlain Subject: Re: Speed and security of /dev/urandom Message-ID: <20140719205350.GX93733@kib.kiev.ua> References: <53C85F42.1000704@pyro.eu.org> <20140719190348.GM45513@funkthat.com> <20140719192605.GV93733@kib.kiev.ua> <53CAD950.1010609@pyro.eu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DPJBYVEhUEzhw0AK" Content-Disposition: inline In-Reply-To: <53CAD950.1010609@pyro.eu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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: Sat, 19 Jul 2014 20:54:00 -0000 --DPJBYVEhUEzhw0AK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > If this is only to seed the arc4random in userland (with ~256 bytes or > so), it would be just like OpenBSD getentropy(2)? >=20 > 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. --DPJBYVEhUEzhw0AK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTytreAAoJEJDCuSvBvK1BJ4wP/2RhGh6eKONjZy9SoERMeXFA NPby8t4rMlrYMPd8HXRCsBG30Nk6PyR3o2DUTr7gwr4EVnNEeCOGsUxvE+cApNpJ M/0nyThwV+3WUyAkSPkHofrpRWfMtmcVKHdV/b9UoH83Rj2sihKbbihOcEXE7ZIC LJqy5SMu82vWZlzlebOCbgUQrkeB98reVqRBidY5ll58AB3QkoWUB/kUZ2RdcM2Y dl3qfkBdDGZXwYqXQDhhdm8NDNbZRmmie+ROdJS7bKsBB6D07KdiUnVKf8Yrl3jP QpFIoppszAvlASsUycYgHue57bzLaAXLyXMQFSertdN0LEuRWojcEHS1q+BdUjGN FfzcMFja2ct848H2WGK2qkUoBwHZzZIUNZXOkgHmIpKRfgl++6MD/LsgwpWrnRdU gm+rcaOGZh7t5sn7lzlR7dtV+rfxrUcVDVo6G8SDPxwiWZk5m60+peSXc3WbPEoN g+g7QMFafhdhR7EvHAp99DglcD14O0fj4Zh3SREM5k4k+q4u4PIge2wDrOlmI0Yx 1IV7YTwdAFaefoz1VJdIW3poxXZ1vPsBiqwLbd6eaEZ2xba/S6dOyou6RRu/Lt0s 6JRY4DjnuF1xm0SVCUEUZDUmNy/nsi+ycfyLQDLq92Aht0TDs8osrKFwUuYUVJRk b/v4Z+nIcBWcN/9xGmpV =twcs -----END PGP SIGNATURE----- --DPJBYVEhUEzhw0AK-- From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 21:02:20 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 F2495DB for ; Sat, 19 Jul 2014 21:02:19 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 8FA962E88 for ; Sat, 19 Jul 2014 21:02:19 +0000 (UTC) X-AuditID: 1209190c-f79ef6d000005dd6-fa-53cadcd4f351 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id C9.00.24022.4DCDAC35; Sat, 19 Jul 2014 17:02:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6JL2BS0029443; Sat, 19 Jul 2014 17:02:12 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6JL2Anv024520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Jul 2014 17:02:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6JL29qC012183; Sat, 19 Jul 2014 17:02:09 -0400 (EDT) Date: Sat, 19 Jul 2014 17:02:09 -0400 (EDT) From: Benjamin Kaduk To: Konstantin Belousov Subject: Re: Speed and security of /dev/urandom In-Reply-To: <20140719205350.GX93733@kib.kiev.ua> Message-ID: 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> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrnvlzqlgg02dahY9m56wWTRMe8zm wOQx49N8Fo+ds+6yBzBFcdmkpOZklqUW6dslcGVsOraFteAeT8Xv3RkNjPO4uhg5OSQETCSO 7znICGGLSVy4t56ti5GLQ0hgNpNE6/1WVghnI6PEmReLGCGcQ0wSE468ZYJwGhglVi9YwgLS zyKgLTHp2xUmEJtNQEVi5puNbCC2iICuxMcFe5hBbGYBBYn3j08C1XBwCAvoS2w+JA1icgoY Sjx8LAxSwSvgKLFqzhVWEFtIYCejxK9HYLaogI7E6v1TWCBqBCVOznzCAjHRUuLcn+tsExgF ZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXUC83s0QvNaV0EyMoTDkleXYwvjmo dIhRgINRiYf3xelTwUKsiWXFlbmHGCU5mJREeW0OAIX4kvJTKjMSizPii0pzUosPMUpwMCuJ 8P5oAcrxpiRWVqUW5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4lCR4l90GahQsSk1P rUjLzClBSDNxcIIM5wEavg6khre4IDG3ODMdIn+KUVFKnPfaLaCEAEgiozQPrheWRl4xigO9 IsxrB9LOA0xBcN2vgAYzAQ2WLj8OMrgkESEl1cA494Rv/dt1toUN93ttS1SLlLbcj3uTLRxr lt/9u+Pz90aemZdYrxS6tIgZ7uKS/bhFJObIqvbN/rwmtY05Ak/+y8txnrrxe+Kzaocmkd4H ywX7Tkz+fGXVzW/XV/65odv/ib1PSu76yq425QvcvP43Ouw3r3R/LLhiCmPNMTHB5w4bJ4sc 2taqxFKckWioxVxUnAgAZVoEwf4CAAA= 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: Sat, 19 Jul 2014 21:02:20 -0000 On Sat, 19 Jul 2014, 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 I thought so, too, when I read it. > models. For one-time seeding of RNG with fixed amount of bytes, > the ELF aux vector mechanism is much less intrusive and faster. I think there is a lot of value in providing a syscall interface which can be the default way for applications to retrieve random bits. This would avoid any issues with needing to track fork() and such, eliminating many sources of worry. Performance-sensitive applications which do not want to suffer such syscall overhead may implement other PRNGs, and may be assumed to be somewhat aware of what they are doing. -Ben 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 From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 21:08:00 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 AAE7342A for ; Sat, 19 Jul 2014 21:08:00 +0000 (UTC) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 48D002EE1 for ; Sat, 19 Jul 2014 21:07:59 +0000 (UTC) X-AuditID: 1209190c-f79ef6d000005dd6-a3-53cade2ea11e Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E5.20.24022.E2EDAC35; Sat, 19 Jul 2014 17:07:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s6JL7vLi029775; Sat, 19 Jul 2014 17:07:58 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6JL7uBb025825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Jul 2014 17:07:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6JL7tQs012914; Sat, 19 Jul 2014 17:07:55 -0400 (EDT) Date: Sat, 19 Jul 2014 17:07:55 -0400 (EDT) From: Benjamin Kaduk To: Mateusz Guzik Subject: Re: Speed and security of /dev/urandom In-Reply-To: <20140719210534.GA4630@dft-labs.eu> Message-ID: 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> <20140719210534.GA4630@dft-labs.eu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrqt371Swwd/H0hY9m56wWTQeXMzi wOQx49N8Fo+ds+6yBzBFcdmkpOZklqUW6dslcGXs2PCJqeAiU0Xf8rOsDYydTF2MnBwSAiYS 39o+MELYYhIX7q1nA7GFBGYzSbzoqe1i5AKyNzJKHD/2jgXCOcQk8fTnZ1YIp4FRouvPVrAW FgFtiVXz5oLZbAIqEjPfbASzRQRUJZ4fXc8KYjMLKEi8f3wSaDUHh7CAvsTmQ9IgYU4BA4mm 5w/ALuIVcJT4cmMf1LK7jBI7D60HO09UQEdi9f4pLBBFghInZz5hgZhpKXHuz3W2CYyCs5Ck ZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREUqpySPDsY3xxUOsQo wMGoxMP74vSpYCHWxLLiytxDjJIcTEqivDYHgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeH+0 AOV4UxIrq1KL8mFS0hwsSuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK8jHeBGgWLUtNTK9Iy c0oQ0kwcnCDDeYCG37oDMry4IDG3ODMdIn+KUVFKnNcbJCEAksgozYPrhaWSV4ziQK8I86qC rOABpiG47ldAg5mABkuXHwcZXJKIkJJqYAz69nyrtbNZjJLm46Qfr5qCnplpVDxqFLBk6bfV KF6Y9OnFzLxJlpaPPstum/j/dub0PaKTOUzdojccKzDyF2jpKiuT1P85IUm9bkvU1pmS/WLa iy4sCmjYET7/+Lu6hsPX+8pmTV3D9nKGWvGlv7cPp117njLLL2+Jw4UPd4OcuW/tbhfJaVFi Kc5INNRiLipOBADXMUJ4AAMAAA== 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: Sat, 19 Jul 2014 21:08:00 -0000 On Sat, 19 Jul 2014, Mateusz Guzik wrote: > I believe the idea here is to have reliable source for reseeding after > fork. I don't think that's quite right; there are issues in reliably detecting that fork has occurred and a reseed performed. Always getting random bits from the kernel avoids the need to detect fork. -Ben From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 21:41:19 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 630428EA for ; Sat, 19 Jul 2014 21:41:19 +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 1BEF22174 for ; Sat, 19 Jul 2014 21:41:19 +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=U2RQqQhkxr6N0heP8G8+ShV+gtVGImxidxeSMFyRX8U=; b=maW/YdDt8n3/QQ4CfbMKOaDRQaHI5AFARs03BD8BNBUAV2KAAckWyyAydRRT+hWoEIzQucfWuUU/IsdVBaNepyaiHCCs3yL58owrj3OuTm7rkic5X9g5Xk1gX5y2m6bp4jvWPndUteXxhkVWeq+GuMq0t9XjO9tWpvqILCEBIbo=; 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 1X8cNV-0005ZL-P3; Sat, 19 Jul 2014 22:41:15 +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 1X8cNU-0007xy-Oz; Sat, 19 Jul 2014 22:41:12 +0100 Message-ID: <53CAE5F8.9010508@pyro.eu.org> Date: Sat, 19 Jul 2014 22:41:12 +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: Benjamin Kaduk , Mateusz Guzik Subject: Re: Speed and security of /dev/urandom 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> <20140719210534.GA4630@dft-labs.eu> 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 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:41:19 -0000 > On Sat, 19 Jul 2014, Mateusz Guzik wrote: >> I believe the idea here is to have reliable source for reseeding after >> fork. That is one issue, for which getrandom(2) may be an improvement, but I mentioned other problems. On 19/07/14 22:07, Benjamin Kaduk wrote: > I don't think that's quite right; there are issues in reliably detecting > that fork has occurred and a reseed performed. > Always getting random bits from the kernel avoids the need to detect fork. Precisely. A syscall may be fast enough (uniquely on FreeBSD) to provide arc4random_buf output, and perhaps be already as fast as doing getpid on each call and running a stream cipher in userland. RW mentioned kernels without RANDOM, being an awkward situation for which it seems necessary to fall back to the PRNG in userland. Regards, -- Steven Chamberlain steven@pyro.eu.org 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 From owner-freebsd-security@FreeBSD.ORG Sat Jul 19 22:25:08 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 A6E26832; Sat, 19 Jul 2014 22:25:08 +0000 (UTC) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 347FF24AC; Sat, 19 Jul 2014 22:25:07 +0000 (UTC) X-AuditID: 12074422-f79be6d000007518-f3-53caf03d4c5d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.2A.29976.D30FAC35; Sat, 19 Jul 2014 18:25:01 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s6JMP0cD031684; Sat, 19 Jul 2014 18:25:00 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s6JMOvs5012143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 19 Jul 2014 18:24:59 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s6JMOvNf022895; Sat, 19 Jul 2014 18:24:57 -0400 (EDT) Date: Sat, 19 Jul 2014 18:24:57 -0400 (EDT) From: Benjamin Kaduk To: Steven Chamberlain Subject: Re: Speed and security of /dev/urandom In-Reply-To: <53CAEB1E.2020401@pyro.eu.org> Message-ID: References: <53C85F42.1000704@pyro.eu.org> <53CAEB1E.2020401@pyro.eu.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixCmqrGv74VSwwbSXfBbfJs1gtejZ9ITN YsGlKewOzB4zPs1n8Tj6/hdTAFMUl01Kak5mWWqRvl0CV0bf6vlMBVdZKj6uW8vUwHiXuYuR k0NCwERizeGprBC2mMSFe+vZuhi5OIQEZjNJrL3wgwnC2cgo0dF7hBHCOcQkseziHRYIp4FR 4kfvbLB+FgFticYtkxhBbDYBFYmZbzaygdgiQPHz/2axdzFycDALFEnc2mwFYgoL6EtsPiQN YnICVXQ/9QQp5hVwlGhZ+ADsOCGBPkaJ2X9LQGxRAR2J1funsEDUCEqcnPkEzGYWsJQ49+c6 2wRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXLzSzRS00p3cQIClh2F6Ud jD8PKh1iFOBgVOLhfXn6VLAQa2JZcWXuIUZJDiYlUV6vd0AhvqT8lMqMxOKM+KLSnNTiQ4wS HMxKIrw/WoByvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJ3uUgQwWL UtNTK9Iyc0oQ0kwcnCDDeYCGvwWp4S0uSMwtzkyHyJ9iVJQS520HSQiAJDJK8+B6YQnlFaM4 0CvCvHtBqniAyQiu+xXQYCagwdLlx0EGlyQipKQaGLUq3TiUS3TjEoUmHHE6+jRO9faT2+dT sibFi4Z++HCn5sc9t3nzmk1yV1S0Hj1RULRvc8oX0Zhjzv/kw7f8/Vz7YqXksZQdTSHVbQdq 1lxWztnfJPdPJHbGjiBVTqnELJ6/aXFHFoemFkieEdiQGV5SdWz9NTG3VScy83RnLO2w6l5f MvmVoBJLcUaioRZzUXEiAB8NZQcDAwAA Cc: Ben Laurie , "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:25:08 -0000 On Sat, 19 Jul 2014, Steven Chamberlain wrote: > 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? Can we please disabuse ourselves of the notion that entropy can be "drained too quickly" (or even drained at all) from the CSPRNG? Once properly seeded, it produces unpredictable bits. Period. It does not matter how many bits are output (well, for achievable quantities of output); the bits are still unpredictable. -Ben