linux-kernel - Re: [RFC][PATCH 0/6] /dev/random

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJU7zaL26c33wApqb=S_NCP9gTZPMGnQ+DACjEi6vnXfTq6XkA@mail.gmail.com>
Date:	Thu, 21 Apr 2016 15:03:37 +0200
From:	Nikos Mavrogiannopoulos <nmav@...tls.org>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	Ted Tso <tytso@....edu>, Herbert Xu <herbert@...dor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sandy Harris <sandyinchina@...il.com>
Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach

On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller <smueller@...onox.de> 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