Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752097AbcDUNEW (ORCPT ); Thu, 21 Apr 2016 09:04:22 -0400 Received: from mail-lf0-f45.google.com ([209.85.215.45]:36166 "EHLO mail-lf0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751622AbcDUNES convert rfc822-to-8bit (ORCPT ); Thu, 21 Apr 2016 09:04:18 -0400 MIME-Version: 1.0 In-Reply-To: <9192755.iDgo3Omyqe@positron.chronox.de> References: <9192755.iDgo3Omyqe@positron.chronox.de> From: Nikos Mavrogiannopoulos Date: Thu, 21 Apr 2016 15:03:37 +0200 X-Google-Sender-Auth: JRVj26Hn5UnmrQN3dY2Qfg8XGEw Message-ID: Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach To: Stephan Mueller Cc: Ted Tso , Herbert Xu , Linux Crypto Mailing List , Linux Kernel Mailing List , Sandy Harris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2669 Lines: 50 On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller wrote: > Hi Herbert, Ted, > > The venerable Linux /dev/random served users of cryptographic mechanisms well > for a long time. Its behavior is well understood to deliver entropic data. In > the last years, however, the Linux /dev/random showed signs of age where it has > challenges to cope with modern computing environments ranging from tiny embedded > systems, over new hardware resources such as SSDs, up to massive parallel > systems as well as virtualized environments. > > With the experience gained during numerous studies of /dev/random, entropy > assessments of different noise source designs and assessing entropy behavior in > virtual machines and other special environments, I felt to do something about > it. > I developed a different approach, which I call Linux Random Number Generator > (LRNG) to collect entropy within the Linux kernel. The main improvements > compared to the legacy /dev/random is to provide sufficient entropy during boot > time as well as in virtual environments and when using SSDs. A secondary design > goal is to limit the impact of the entropy collection on massive parallel > systems and also allow the use accelerated cryptographic primitives. Also, all > steps of the entropic data processing are testable. Finally massive performance > improvements are visible at /dev/urandom / get_random_bytes. [quote from pdf] > ... DRBG is “minimally” seeded with 112^6 bits of entropy. > This is commonly achieved even before user space is initiated. Unfortunately one of the issues of the /dev/urandom interface is the fact that it may start providing random numbers even before the seeding is complete. From the above quote, I understand that this issue is not addressed by the new interface. That's a serious limitation (of the current and inherited by the new implementation), since most/all newly deployed systems from "cloud" images generate keys using /dev/urandom (for sshd for example) on boot, and it is unknown to these applications whether they operate with uninitialized seed. While one could argue for using /dev/random, the unpredictability of the delay it incurs is prohibitive for any practical use. Thus I'd expect any new interface to provide a better /dev/urandom, by ensuring that the kernel seed buffer is fully seeded prior to switching to userspace. About the rest of the design, I think it is quite clean. I think the DRBG choice is quite natural given the NIST recommendations, but have you considered using a stream cipher instead like chacha20 which in most of cases it would outperform the DRBG based on AES? regards, Nikos