From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 17:21:10 2013 Return-Path: Delivered-To: freebsd-arch@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 ESMTP id CC45E605; Sun, 18 Aug 2013 17:21:10 +0000 (UTC) (envelope-from mark@grondar.org) 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)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D9BA21E3; Sun, 18 Aug 2013 17:21:10 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VB6f3-000Keq-KT; Sun, 18 Aug 2013 18:21:08 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> Date: Sun, 18 Aug 2013 18:20:57 +0100 Message-Id: <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , secteam@freebsd.org, FreeBSD-arch Arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2013 17:21:11 -0000 --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Aug 2013, at 17:53, Tim Kientzle wrote: > We could have kernel options to choose mixers > (e.g., Yarrow or Fortuna) for /dev/random and > loadable device modules for entropy sources. >=20 > Besides Yarrow and Fortuna mixers, we could then > offer a "null mixer" option that selected the single > "best" entropy source and passed it directly through. =85 assuming that it is "real" entropy and not unprocessed stuff like keystrokes, mouse moves etc. Code needed. > Users could compile the null mixer into the kernel > and load a single HW RNG driver to have precise > control over /dev/random. Interrupt harvesting would > be the lowest-quality source as a fall back. There are lots of harvest points in the kernel. Why not take the lot? > In particular, this has a reasonable failure mode if > someone built a kernel with only a single HW entropy > source and the null mixer: > * On hardware with that source, they would get > full-speed HW entropy. OK. Works for me. This is me accepting a point and changing my stance. This will need to be written. > * On hardware without that source, they would get > the old blocking /dev/random that we had before > Yarrow, the one that used only interrupt harvesting. Disagree. The fallback should be Yarrow/Fortuna. Both do a better job with the same input. See: Furguson, Niels & Schneier, Bruce. "Practical Cryptography" ISBN 0-471-22894-X 0-471-22357-3 There is a theoretical argument that real random data is better than = pseudorandom data from a PRNG. In certain cryptographic protocols you = can prove that certain attacks are impossible if you use real random = data. The protocol is unconditionally secure. If you use a PRNG, then = the protocol is only secure as long as the attacker cannot break the = PRNG; the protocol is computationally secure. this distinction, however, = is only relevant for people in ivory towers. All cryptographic protocols = use use computational assumptions for for almost everything. Removing = the computational assumption assumption for one particular type of = attack is an insignificant improvement, and generating real random data, = which you need for unconditional security, is so difficult that you are = far more likely to reduce the system security by trying to use real = random data. ...=20 M --=20 Mark R V Murray --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhECgN58vKOKE6LNAQopdAQAnqXrvAcJ8W/Iif7DPDaR7+xUVimN3soJ btCfGClEyYWktmtcbSkmktR0bgMEN5P5he4/uTjvGoWjrK/uSyI5sYps4o+MgRwS bSS5xhDKkeQFBb3lY+URl5g5r8fjHWiaAbktgDjICnuw4qBRYaTrzT0hy4EzD8+S 2NSaR/mwXNw= =z3Km -----END PGP SIGNATURE----- --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898--