Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753853AbcDYHz6 (ORCPT ); Mon, 25 Apr 2016 03:55:58 -0400 Received: from mail-lf0-f42.google.com ([209.85.215.42]:35238 "EHLO mail-lf0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753805AbcDYHzz convert rfc822-to-8bit (ORCPT ); Mon, 25 Apr 2016 03:55:55 -0400 MIME-Version: 1.0 In-Reply-To: <1499137.D4Mft7n8bh@tauon.atsec.com> References: <9192755.iDgo3Omyqe@positron.chronox.de> <1499137.D4Mft7n8bh@tauon.atsec.com> From: Nikos Mavrogiannopoulos Date: Mon, 25 Apr 2016 09:55:14 +0200 X-Google-Sender-Auth: VIzFj6iw4jO9Hkwx58IrYuTsMWU 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: 1215 Lines: 24 On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller wrote: >> > ... 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. > One more item to consider: If you do not want to change to use getrandom(2), > the LRNG provides you with another means. The main problem is not about willing to switch to getrandom() or not, but finding any system where getrandom() exists. Today due to libc not having the call, we can only use /dev/urandom and applications would most likely continue to do so long time after getrandom() is introduced to libc. regards, Nikos