Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751466AbdCRKMx (ORCPT ); Sat, 18 Mar 2017 06:12:53 -0400 Received: from mail-ot0-f176.google.com ([74.125.82.176]:33033 "EHLO mail-ot0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751107AbdCRKM3 (ORCPT ); Sat, 18 Mar 2017 06:12:29 -0400 MIME-Version: 1.0 Reply-To: noloader@gmail.com In-Reply-To: <2785457.pDyvZpZC2q@positron.chronox.de> References: <2785457.pDyvZpZC2q@positron.chronox.de> From: Jeffrey Walton Date: Sat, 18 Mar 2017 06:11:57 -0400 Message-ID: Subject: Re: [ANNOUNCE] /dev/random - a new approach (code for 4.11-rc1) To: =?UTF-8?Q?Stephan_M=C3=BCller?= Cc: LKML , linux-crypto@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1046 Lines: 21 > The design and implementation is driven by a set of goals described in [2] > that the LRNG completely implements. Furthermore, [2] includes a > comparison with RNG design suggestions such as SP800-90B, SP800-90C, and > AIS20/31. A quick comment about SP800 and the hardware instructions... RDSEED is 2 to 5 times slower than RDRAND on Intel hardware, depending on the architecture and microarchitecture. AMD's implementation of RDRAND is orders of magnitude slower than Intel's. Testing on an Athlon 845 X4 (Bulldozer v4) @ 3.5 GHz shows it runs between 4100 and 4500 cycles per byte. It works out to be about 1 MiB/s. While the LRNG may reach a cryptographically acceptable seed level much earlier then the existing /dev/random, it may not be early enough. Some components, like systemd, will ask for random numbers and truck-on even if they are not available. Systemd does not block or wait if get_random_bytes fails to produce. In the bigger picture, don't expect that software layered above will do the expected thing in all cases. Jeff