From owner-freebsd-arch@FreeBSD.ORG Fri Nov 21 19:37:27 2014 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDE0AC21; Fri, 21 Nov 2014 19:37:27 +0000 (UTC) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 948F2F16; Fri, 21 Nov 2014 19:37:27 +0000 (UTC) Received: from [2001:470:9174:1:c160:6db5:dfbd:9b92] by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Xru1E-000Nbt-To; Fri, 21 Nov 2014 19:37:25 +0000 Subject: Re: svn commit: r274739 - head/sys/mips/conf Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <1416596266.1147.290.camel@revolution.hippie.lan> Date: Fri, 21 Nov 2014 19:37:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1993) X-SA-Score: -1.0 Cc: arch@freebsd.org, John-Mark Gurney , Adrian Chadd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 19:37:27 -0000 > On 21 Nov 2014, at 18:57, Ian Lepore wrote: >=20 > All I've ever asked for, since day one of discussing this topic, is a > knob to prevent /dev/random from blocking, ever. A way in which an > administrativive policy decision can be made about what consitutes = "good > enough" entropy (and by extension, security). The knob could be of = the > nature that it's hard to turn on accidentally -- it's a dangerous = thing > and like an industrial stamping press maybe you have to hold down two > buttons far apart from each other to make it go. I=E2=80=99m suspicious of motive here. You are planning on ignoring = lousy entropy coming out of /dev/random; you seem to need a way of breaking to do so. (I can=E2=80=99t think of a better word than =E2=80=9Cignoring=E2= =80=9D; what I mean is that you don=E2=80=99t seem to care how bad the output is.) If you don=E2=80=99t care about the contents of /dev/random, why not = simply ignore it? Choosing to use tools that require good-quality /dev/random output means you should choose other tools, not break /dev/random! > As far as I know we have that now, but it sounds like not forever. = I'm > just arguing in favor of providing the tools, making it reasonably = hard > to accidentally cut yourself on them, but ultimately leaving the = policy > decisions of how to use them to the people who own and run the = systems. > I kind of thought that was the unix way. The Snowden revelations have made folks considerably more paranoid. Providing tools that bad guys could potentially use where the good guys have alternatives is not a way that security-minded folks are keen to go. You have the right to ignore /dev/random. Asking for a back door to break it is a bigger deal. Bad guys like these back doors. M --=20 Mark R V Murray