From: "Stephan Müller" <smueller@chronox.de>
To: Theodore Ts'o <tytso@mit.edu>
Cc: kernel-hardening@lists.openwall.com,
Michael Ellerman <mpe@ellerman.id.au>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
David Miller <davem@davemloft.net>,
Eric Biggers <ebiggers3@gmail.com>
Subject: Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness
Date: Sun, 18 Jun 2017 19:55:04 +0200 [thread overview]
Message-ID: <2812305.zGuAXT15AM@positron.chronox.de> (raw)
In-Reply-To: <20170618154625.5qu3eduqjtgk5bal@thunk.org>
Am Sonntag, 18. Juni 2017, 17:46:25 CEST schrieb Theodore Ts'o:
Hi Theodore,
> > IMHO, users using the get_random_u64 or get_random_u32 are use cases that
> > do not require a fully seeded DRNG thus do not need a cryptographically
> > strong random number. Hence, I would think that the logging should be
> > removed from get_random_u32/u64.
>
> You are effectively proposing that there ought to be a middle range of
> security between prandom_32, get_random_u32/get_random_u64 and
> get_random_bytes(). I think that's going to lead to all sorts of
> complexity and bugs from people not understanding when they should use
> get_random_u32 vs get_random_bytes versus prandom_u32. And then we'll
> end up needing to audit all of the callsites for get_random_u32() so
> they don't violate this new usage rule that you are proposing.
I only proposed to get rid of the log messages indicating a non-seeded DRNG.
But you bring up an interesting point: if it is true you say that it is hard
for people to use differnent types of APIs regarding entropy and random
numbers right (which I would concur with), and considering that you imply that
get_random_bytes, get_random_u32 and get_random_u64 have the same security
strength, why do we have these three APIs to begin with? The get_random_bytes
API would then be more than enough.
Ciao
Stephan
next prev parent reply other threads:[~2017-06-18 17:55 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-06 17:47 [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 01/13] random: invalidate batched entropy after crng init Jason A. Donenfeld
2017-06-07 23:58 ` Theodore Ts'o
2017-06-08 0:52 ` Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 02/13] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-08 0:00 ` Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-08 0:05 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 04/13] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-08 0:31 ` Theodore Ts'o
2017-06-08 0:50 ` Jason A. Donenfeld
2017-06-08 1:03 ` Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 05/13] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-08 0:41 ` [kernel-hardening] " Theodore Ts'o
2017-06-08 0:47 ` Jason A. Donenfeld
2017-06-06 17:47 ` [PATCH v4 06/13] iscsi: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-08 2:43 ` Theodore Ts'o
2017-06-08 12:09 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-16 21:58 ` Lee Duncan
2017-06-17 0:41 ` Jason A. Donenfeld
2017-06-17 3:45 ` Lee Duncan
2017-06-17 14:23 ` Jeffrey Walton
[not found] ` <CAH8yC8nHX2r9cfQ0gNeJAUrgSfAS8V16dVHv35BRnLn-YprZCg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-17 18:50 ` [kernel-hardening] " Paul Koning
2017-07-05 7:08 ` Antw: Re: [kernel-hardening] " Ulrich Windl
2017-07-05 13:16 ` Paul Koning
2017-07-05 17:34 ` Antw: " Theodore Ts'o
2017-06-18 8:04 ` [kernel-hardening] " Stephan Müller
[not found] ` <2639082.PtrrGWOPPL-jJGQKZiSfeo1haGO/jJMPxvVK+yQ3ZXh@public.gmane.org>
2017-06-26 1:23 ` Nicholas A. Bellinger
[not found] ` <1498440189.26123.85.camel-XoQW25Eq2zviZyQQd+hFbcojREIfoBdhmpATvIKMPHk@public.gmane.org>
2017-06-26 17:38 ` Stephan Müller
2017-06-30 6:02 ` Nicholas A. Bellinger
[not found] ` <1678474.GnYBdSlWgs-b2PLbiJbNv8ftSvlWXw0+g@public.gmane.org>
2017-07-05 7:03 ` Antw: " Ulrich Windl
2017-07-05 12:35 ` Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 07/13] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-08 2:45 ` [kernel-hardening] " Theodore Ts'o
2017-06-06 17:47 ` [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random Jason A. Donenfeld
2017-06-08 0:25 ` Theodore Ts'o
2017-06-08 0:31 ` [kernel-hardening] " Jason A. Donenfeld
2017-06-08 0:34 ` Jason A. Donenfeld
2017-06-06 17:48 ` [PATCH v4 09/13] rhashtable: use get_random_u32 for hash_rnd Jason A. Donenfeld
2017-06-08 2:47 ` Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 10/13] net/neighbor: use get_random_u32 for 32-bit hash random Jason A. Donenfeld
2017-06-08 3:00 ` Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 11/13] net/route: use get_random_int for random counter Jason A. Donenfeld
2017-06-08 3:01 ` Theodore Ts'o
2017-06-06 17:48 ` [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-08 3:06 ` Theodore Ts'o
2017-06-08 5:04 ` Marcel Holtmann
2017-06-08 12:03 ` Jason A. Donenfeld
2017-06-08 12:05 ` Jason A. Donenfeld
2017-06-08 17:05 ` Marcel Holtmann
2017-06-08 17:34 ` Jason A. Donenfeld
2017-06-06 17:48 ` [PATCH v4 13/13] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-08 8:19 ` Theodore Ts'o
2017-06-08 12:01 ` Jason A. Donenfeld
2017-06-15 11:03 ` [kernel-hardening] " Michael Ellerman
2017-06-15 11:59 ` Stephan Müller
2017-06-18 15:46 ` Theodore Ts'o
2017-06-18 17:55 ` Stephan Müller [this message]
2017-06-18 19:12 ` Jason A. Donenfeld
2017-06-18 19:11 ` Jason A. Donenfeld
2017-06-08 8:43 ` Jeffrey Walton
2017-06-07 12:33 ` [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
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=2812305.zGuAXT15AM@positron.chronox.de \
--to=smueller@chronox.de \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=ebiggers3@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=tytso@mit.edu \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).