public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stephan Müller" <smueller@chronox.de>
To: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Nicolai Stange <nstange@suse.de>
Cc: Torsten Duwe <duwe@suse.de>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	Nicolai Stange <nstange@suse.de>
Subject: Re: [PATCH 0/6] crypto: DRBG - improve 'nopr' reseeding
Date: Tue, 26 Oct 2021 10:33:05 +0200	[thread overview]
Message-ID: <2120606.3HGXcN3vsr@positron.chronox.de> (raw)
In-Reply-To: <20211025092525.12805-1-nstange@suse.de>

Am Montag, 25. Oktober 2021, 11:25:19 CEST schrieb Nicolai Stange:

Hi Nicolai,

> Hi all,
> 
> this patchset aims at (hopefully) improving the DRBG code related to
> reseeding from get_random_bytes() a bit:

Thanks for sharing your patches.

> - Replace the asynchronous random_ready_callback based DRBG reseeding
>   logic with a synchronous solution leveraging rng_is_initialized().

Could you please help me why replacing an async method with a sync method is 
helpful? Which problems do you see with the async method that are alleviated 
with the swtich to the sync method? In general, an async method is more 
powerful, though it requires a bit more code.

>   This
>   move simplifies the code IMO and, as a side-effect, would enable DRBG
>   users to rely on wait_for_random_bytes() to sync properly with
>   drbg_generate(), if desired. Implemented by patches 1-5/6.
> - Make the 'nopr' DRBGs to reseed themselves every 5min from
>   get_random_bytes(). This achieves at least kind of a partial prediction
>   resistance over the time domain at almost no extra cost. Implemented
>   by patch 6/6, the preceding patches in this series are a prerequisite
>   for this.

Just as a side note not against your ideas and patches, but in general: IMHO 
it is a failure of all of us that the quite sensitive (re)seeding of RNGs and 
entropy management is handled in multiple places in the kernel - and each case 
only handles a subset of considerations around that topic. Note, (re)seeding 
may be needed in other occasions than the elapse of a timer or the reaching of 
maximum number of generate operations. Seeding belongs to a central place 
where it is done right once and usable for differnent RNGs as proposed with my 
LRNG patch set and the published todo list to get rid of the entire seeding 
logic in the DRBG code base.

That said, your patch of adding the timer-based reseeding seems appropriate 
and thus should be considered for the current code base.

Ciao
Stephan



  parent reply	other threads:[~2021-10-26  8:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-25  9:25 [PATCH 0/6] crypto: DRBG - improve 'nopr' reseeding Nicolai Stange
2021-10-25  9:25 ` [PATCH 1/6] crypto: DRBG - prepare for more fine-grained tracking of seeding state Nicolai Stange
2021-10-26  8:37   ` Stephan Müller
2021-10-25  9:25 ` [PATCH 2/6] crypto: DRBG - track whether DRBG was seeded with !rng_is_initialized() Nicolai Stange
2021-10-26  8:41   ` Stephan Müller
2021-10-25  9:25 ` [PATCH 3/6] crypto: DRBG - move dynamic ->reseed_threshold adjustments to __drbg_seed() Nicolai Stange
2021-10-26  9:05   ` Stephan Müller
2021-10-25  9:25 ` [PATCH 4/6] crypto: DRBG - make reseeding from get_random_bytes() synchronous Nicolai Stange
2021-10-26  9:19   ` Stephan Müller
2021-10-27  9:19     ` Nicolai Stange
2021-10-27 18:44       ` Stephan Müller
2021-10-25  9:25 ` [PATCH 5/6] crypto: DRBG - make drbg_prepare_hrng() handle jent instantiation errors Nicolai Stange
2021-10-26  9:19   ` Stephan Müller
2021-10-25  9:25 ` [PATCH 6/6] crypto: DRBG - reseed 'nopr' drbgs periodically from get_random_bytes() Nicolai Stange
2021-10-26  9:33   ` Stephan Müller
2021-10-26  8:33 ` Stephan Müller [this message]
2021-10-27  8:40   ` [PATCH 0/6] crypto: DRBG - improve 'nopr' reseeding Nicolai Stange
2021-10-27 18:43     ` Stephan Müller

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=2120606.3HGXcN3vsr@positron.chronox.de \
    --to=smueller@chronox.de \
    --cc=davem@davemloft.net \
    --cc=duwe@suse.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nstange@suse.de \
    /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