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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 8 Jan 2021 16:42:11 +0800 From: Sandy Harris <sandyinchina@...il.com> To: Pavel Machek <pavel@....cz> Cc: Petr Tesarik <ptesarik@...e.cz>, "Jason A. Donenfeld" <Jason@...c4.com>, Torsten Duwe <duwe@....de>, Marcelo Henrique Cerri <marcelo.cerri@...onical.com>, "Theodore Y. Ts'o" <tytso@....edu>, Linus Torvalds <torvalds@...ux-foundation.org>, Stephan Müller <smueller@...onox.de>, Willy Tarreau <w@....eu>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, Nicolai Stange <nstange@...e.de>, LKML <linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>, "Eric W. Biederman" <ebiederm@...ssion.com>, "Alexander E. Patrakov" <patrakov@...il.com>, "Ahmed S. Darwish" <darwish.07@...il.com>, Matthew Garrett <mjg59@...f.ucam.org>, Vito Caputo <vcaputo@...garu.com>, Andreas Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.cz>, Ray Strode <rstrode@...hat.com>, William Jon McCann <mccann@....edu>, zhangjs <zachary@...shancloud.com>, Andy Lutomirski <luto@...nel.org>, Florian Weimer <fweimer@...hat.com>, Lennart Poettering <mzxreary@...inter.de>, Peter Matthias <matthias.peter@....bund.de>, Neil Horman <nhorman@...hat.com>, Randy Dunlap <rdunlap@...radead.org>, Julia Lawall <julia.lawall@...ia.fr>, Dan Carpenter <dan.carpenter@...cle.com>, And y Lavr <andy.lavr@...il.com>, Eric Biggers <ebiggers@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, simo@...hat.com Subject: Re: drivers/char/random.c needs a (new) maintainer Pavel Machek <pavel@....cz> wrote: > To play devil's advocate, does RNG subsystem need to evolve? Its task > is to get random numbers. Does it fail at the task? > > Problem is, random subsystem is hard to verify, and big rewrite is > likely to cause security problems... Parts of the problem, though, are dead easy in many of today's environments. Many CPUs, e,g. Intel, have an instruction that gives random numbers. Some systems have another hardware RNG. Some can add one using a USB device or Denker's Turbid (https://www.av8n.com/turbid/). Many Linux instances run on VMs so they have an emulated HWRNG using the host's /dev/random. None of those is necessarily 100% trustworthy, though the published analysis for Turbid & for (one version of) the Intel device seem adequate to me. However, if you use any of them to scribble over the entire 4k-bit input pool and/or a 512-bit Salsa context during initialisation, then it seems almost certain you'll get enough entropy to block attacks. They are all dirt cheap so doing that, and using them again later for incremental squirts of randomness, looks reasonable. In many cases you could go further. Consider a system with an intel CPU and another HWRNG, perhaps a VM. Get 128 bits from each source & combine them using the 128-bit finite field multiplication from the GSM authentication. Still cheap & it cannot be worse than the better of the two sources. If both sources are anywhere near reasonable, this should produce 128 bits of very high grade random material, cheaply. I am not suggesting any of these should be used for output, but using them for initialisation whenever possible looks obvious to me.
Powered by blists - more mailing lists