From: Kurt Roeckx <kurt@roeckx.be> To: "Theodore Y. Ts'o" <tytso@mit.edu> Cc: Stephan Mueller <smueller@chronox.de>, Andy Lutomirski <luto@amacapital.net>, Andy Lutomirski <luto@kernel.org>, LKML <linux-kernel@vger.kernel.org>, Linux API <linux-api@vger.kernel.org>, Kees Cook <keescook@chromium.org>, "Jason A. Donenfeld" <Jason@zx2c4.com>, "Ahmed S. Darwish" <darwish.07@gmail.com>, Lennart Poettering <mzxreary@0pointer.de>, "Eric W. Biederman" <ebiederm@xmission.com>, "Alexander E. Patrakov" <patrakov@gmail.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Willy Tarreau <w@1wt.eu>, Matthew Garrett <mjg59@srcf.ucam.org>, Ext4 Developers List <linux-ext4@vger.kernel.org>, linux-man <linux-man@vger.kernel.org> Subject: Re: [PATCH v3 0/8] Rework random blocking Date: Thu, 9 Jan 2020 23:02:30 +0100 Message-ID: <20200109220230.GA39185@roeckx.be> (raw) In-Reply-To: <20191227220857.GD70060@mit.edu> On Fri, Dec 27, 2019 at 05:08:57PM -0500, Theodore Y. Ts'o wrote: > On Fri, Dec 27, 2019 at 10:22:23PM +0100, Stephan Mueller wrote: > > > So let's take a step back and ask the question: "Exactly what _value_ > > > do you want to provide by creating some kind of true random > > > interface?" What does this enable? What applications does this > > > really help? > > > > There are simply cryptographers who have use cases for such random numbers. > > The core use case is to seed other DRNGs and avoiding the chaining of free- > > running DRNGs. > > For this very specialized use case, what I think the kernel should > provide is maximal transparency; that is, given the DRBG direct access > to the TPM's random number generator, or direct access to the > ChaosKey, and the userspace DRBG should be able to get a list of the > various hardware RNG's, and select one, with the characterization > being done userspace, not in the kernel. One thing the NIST DRBGs have is prediction resistance, which is done by reseeding. If you chain DRBGs, you tell your parent DRBG that you want prediction resistance, so your parent will also reseed. There currently is no way to tell the kernel to reseed. This reseed option might be something that some people would like to see. If such an option is added, I expect that the kernel might block until it has gotten enough new entropy from it's entropy sources. But I don't actually see a need to add such an option. If the kernel provides a good RNG, the only reason I can see why you would like to have direct access to a hwrng is to verify that it's working correctly. That might mean that you put it in some special mode where it returns raw unprocessed values. If the device is in such a mode, it's output will not provide the same entropy per bit, and so I would expect the kernel to stop using it directly. I guess there might be people who would like to use it directly, but I think we should instead encourage them kernel RNG. > You can talk about providing tools that try to make these estimations > --- but these sorts of things would have to be done on each user's > hardware, and for most distro users, it's just not practical. I would check my own hardware if such an option was available. I think it can be useful to see if the current estimates in the kernel are conservative enough or not. But it would require that you can know what the entropy source is, like the keyboard or harddisk. > So if it's just for cryptographers, then let it all be done in > userspace, and let's not make it easy for GPG, OpenSSL, etc., to all > say, "We want TrueRandom(tm); we won't settle for less". I don't think we want that. As far as I know, the only reason for using /dev/random is that /dev/urandom returns data before it has sufficient entropy. Kurt
next prev parent reply index Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-23 8:20 Andy Lutomirski 2019-12-23 8:20 ` [PATCH v3 1/8] random: Don't wake crng_init_wait when crng_init == 1 Andy Lutomirski 2020-01-07 20:42 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 2/8] random: Add a urandom_read_nowait() for random APIs that don't warn Andy Lutomirski 2020-01-07 20:43 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 3/8] random: Add GRND_INSECURE to return best-effort non-cryptographic bytes Andy Lutomirski 2020-01-07 20:44 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 4/8] random: Ignore GRND_RANDOM in getentropy(2) Andy Lutomirski 2020-01-07 20:44 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 5/8] random: Make /dev/random be almost like /dev/urandom Andy Lutomirski 2020-01-07 21:02 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 6/8] random: Remove the blocking pool Andy Lutomirski 2020-01-07 21:03 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 7/8] random: Delete code to pull data into pools Andy Lutomirski 2020-01-07 21:03 ` Theodore Y. Ts'o 2019-12-23 8:20 ` [PATCH v3 8/8] random: Remove kernel.random.read_wakeup_threshold Andy Lutomirski 2020-01-07 21:04 ` Theodore Y. Ts'o 2019-12-26 9:29 ` [PATCH v3 0/8] Rework random blocking Stephan Müller 2019-12-26 10:03 ` Matthew Garrett 2019-12-26 11:40 ` Stephan Mueller 2019-12-26 11:12 ` Andy Lutomirski 2019-12-26 12:03 ` Stephan Mueller 2019-12-26 12:46 ` Andy Lutomirski 2019-12-27 9:55 ` Stephan Mueller 2019-12-26 14:04 ` Theodore Y. Ts'o 2019-12-26 23:29 ` Andy Lutomirski 2019-12-27 10:29 ` Stephan Mueller 2019-12-27 13:04 ` Theodore Y. Ts'o 2019-12-27 21:22 ` Stephan Mueller 2019-12-27 22:08 ` Theodore Y. Ts'o 2019-12-28 2:06 ` Andy Lutomirski 2019-12-29 14:49 ` Theodore Y. Ts'o 2019-12-29 15:08 ` Andy Lutomirski 2019-12-28 7:01 ` Willy Tarreau 2020-01-09 22:02 ` Kurt Roeckx [this message] 2020-01-09 22:40 ` Theodore Y. Ts'o 2020-01-09 23:02 ` Kurt Roeckx 2020-01-10 7:53 ` Stephan Mueller 2020-01-10 0:30 ` Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200109220230.GA39185@roeckx.be \ --to=kurt@roeckx.be \ --cc=Jason@zx2c4.com \ --cc=darwish.07@gmail.com \ --cc=ebiederm@xmission.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-man@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=mjg59@srcf.ucam.org \ --cc=mtk.manpages@gmail.com \ --cc=mzxreary@0pointer.de \ --cc=patrakov@gmail.com \ --cc=smueller@chronox.de \ --cc=tytso@mit.edu \ --cc=w@1wt.eu \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-man Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \ linux-man@vger.kernel.org public-inbox-index linux-man Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man AGPL code for this site: git clone https://public-inbox.org/public-inbox.git