From owner-freebsd-current@FreeBSD.ORG Tue Sep 10 18:18:16 2013 Return-Path: Delivered-To: freebsd-current@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 6CB8A4EB for ; Tue, 10 Sep 2013 18:18:16 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from s1.omnilan.de (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAC282F8F for ; Tue, 10 Sep 2013 18:18:15 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by s1.omnilan.de (8.13.8/8.13.8) with ESMTP id r8AIDfAN048854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Sep 2013 20:13:41 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <522F6155.40101@omnilan.de> Date: Tue, 10 Sep 2013 20:13:41 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD CURRENT Subject: HW fed /dev/random X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig78FC4776DEF45BD76F0A3930" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 18:18:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig78FC4776DEF45BD76F0A3930 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, some time ago, before random(4) was rewritten for FreeBSD 5 by Mark Murray, we had rng, the i815 hardware random number generator. At this time, there were rumors about the quality of the randomness. Now we have rdrand (BullMountain hardware random generator in IvyBridge) and Dual_EC_DRBG (NSA's NIST contribution) makes me wonder if quality is again something to worry about - although kib's commit message states: =E2=80=9EFrom the Intel whitepapers and articles about Bull Mountain, it = seems that we do not need to perform post-processing of RDRAND results, like AES-encryption of the data with random IV and keys, which was done for Padlock. Intel claims that sanitization is performed in hardware.=E2=80=9C= When we use the software random device, one has great control over /dev/random with sysctk kern.random. Are there considerations to extend the HW-rng-implementation by optional post processing? -Harry --------------enig78FC4776DEF45BD76F0A3930 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlIvYVUACgkQLDqVQ9VXb8iEPQCgn1d/XUCFYTsVv2zwcxrlmreJ cYAAn3wvGDEMiqt4jG4Sphv4JjN3bchz =FpO0 -----END PGP SIGNATURE----- --------------enig78FC4776DEF45BD76F0A3930--