Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753843AbcDYICO (ORCPT ); Mon, 25 Apr 2016 04:02:14 -0400 Received: from mail.eperm.de ([89.247.134.16]:53542 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752231AbcDYICL convert rfc822-to-8bit (ORCPT ); Mon, 25 Apr 2016 04:02:11 -0400 From: Stephan Mueller To: Nikos Mavrogiannopoulos Cc: Ted Tso , Herbert Xu , Linux Crypto Mailing List , Linux Kernel Mailing List , Sandy Harris Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach Date: Mon, 25 Apr 2016 10:02:08 +0200 Message-ID: <2009968.Rf1hsrr5t0@tauon.atsec.com> User-Agent: KMail/4.14.10 (Linux/4.4.7-300.fc23.x86_64; KDE/4.14.18; x86_64; ; ) In-Reply-To: References: <9192755.iDgo3Omyqe@positron.chronox.de> <1499137.D4Mft7n8bh@tauon.atsec.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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: 1846 Lines: 46 Am Montag, 25. April 2016, 09:55:14 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > 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. Implement the syscall yourself with syscall(). If you get ENOSYS back, revert to your old logic of seeding from /dev/urandom. If you know you are on kernels >= 3.14, you could use the following steps in your library: - poll /proc/sys/kernel/random/entropy_avail in spaces of, say, one second and block your seeding process until that value becomes non-zero - if you unblock, seed from /dev/urandom and you have the guarantee of having a /dev/urandom seeded with 128 bits. > > regards, > Nikos Ciao Stephan