linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).