All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dominik Brodowski <linux@dominikbrodowski.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
	tytso@mit.edu, ebiggers@kernel.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [PATCH v2 7/9] random: use simpler fast key erasure flow on per-cpu keys
Date: Wed, 9 Feb 2022 09:30:16 +0100	[thread overview]
Message-ID: <YgN7mOTtQ03etVJX@owl.dominikbrodowski.net> (raw)
In-Reply-To: <20220209011919.493762-8-Jason@zx2c4.com>

Nice work, just a few minor queries:

> -static void extract_crng(u8 out[CHACHA_BLOCK_SIZE])
> +/*
> + * The general form here is based on a "fast key erasure RNG" from
> + * <https://blog.cr.yp.to/20170723-random.html>. It generates a ChaCha
> + * block using the provided key, and then immediately overwites that
> + * key with half the block. It returns the resultant ChaCha state to the
> + * user, along with the second half of the block containing 32 bytes of
> + * random data that may be used; random_data_len may not be greater than
> + * 32.
> + */
> +static void crng_fast_key_erasure(u8 key[CHACHA_KEY_SIZE],
> +				  u32 chacha_state[CHACHA_STATE_WORDS],
> +				  u8 *random_data, size_t random_data_len)
>  {
> -	unsigned long flags, init_time;
> +	u8 first_block[CHACHA_BLOCK_SIZE];

Do we need a BUG_ON(random_data_len > 32) here?

>  
> -	if (crng_ready()) {
> -		init_time = READ_ONCE(primary_crng.init_time);
> -		if (time_after(jiffies, init_time + CRNG_RESEED_INTERVAL))
> -			crng_reseed();
> -	}
> -	spin_lock_irqsave(&primary_crng.lock, flags);
> -	chacha20_block(&primary_crng.state[0], out);
> -	if (primary_crng.state[12] == 0)
> -		primary_crng.state[13]++;
> -	spin_unlock_irqrestore(&primary_crng.lock, flags);
> +	chacha_init_consts(chacha_state);
> +	memcpy(&chacha_state[4], key, CHACHA_KEY_SIZE);
> +	memset(&chacha_state[12], 0, sizeof(u32) * 4);

No IV, no generation counter here? As you already have a generation counter
in use for other purposes, why not use it here as well as some non-zero
starting point?

Otherwise, it looks really nice.

Thanks,
	Dominik

  reply	other threads:[~2022-02-09  8:37 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-09  1:19 [PATCH v2 0/9] random: cleanups around per-cpu crng & rdrand Jason A. Donenfeld
2022-02-09  1:19 ` [PATCH v2 1/9] random: use RDSEED instead of RDRAND in entropy extraction Jason A. Donenfeld
2022-02-09  6:18   ` Dominik Brodowski
2022-02-09  1:19 ` [PATCH v2 2/9] random: get rid of secondary crngs Jason A. Donenfeld
2022-02-09  8:22   ` Dominik Brodowski
2022-02-09 10:26     ` Jason A. Donenfeld
2022-02-21  2:38   ` Eric Biggers
2022-02-09  1:19 ` [PATCH v2 3/9] random: inline leaves of rand_initialize() Jason A. Donenfeld
2022-02-09  8:22   ` Dominik Brodowski
2022-02-09 10:27     ` Jason A. Donenfeld
2022-02-09  1:19 ` [PATCH v2 4/9] random: ensure early RDSEED goes through mixer on init Jason A. Donenfeld
2022-02-09  8:23   ` Dominik Brodowski
2022-02-09 10:37     ` Jason A. Donenfeld
2022-02-09  1:19 ` [PATCH v2 5/9] random: do not xor RDRAND when writing into /dev/random Jason A. Donenfeld
2022-02-09  8:28   ` Dominik Brodowski
2022-02-09 10:40     ` Jason A. Donenfeld
2022-02-09  1:19 ` [PATCH v2 6/9] random: absorb fast pool into input pool after fast load Jason A. Donenfeld
2022-02-09  8:29   ` Dominik Brodowski
2022-02-09 10:45     ` Jason A. Donenfeld
2022-02-15 21:13       ` [PATCH v3] " Jason A. Donenfeld
2022-02-21  2:47         ` Eric Biggers
2022-02-21 14:57           ` Jason A. Donenfeld
2022-02-21 14:58             ` [PATCH v4] " Jason A. Donenfeld
2022-02-21 19:08               ` Eric Biggers
2022-02-09  1:19 ` [PATCH v2 7/9] random: use simpler fast key erasure flow on per-cpu keys Jason A. Donenfeld
2022-02-09  8:30   ` Dominik Brodowski [this message]
2022-02-09 10:54     ` Jason A. Donenfeld
2022-02-14 18:46   ` [PATCH v3] " Jason A. Donenfeld
2022-02-16 23:21     ` [PATCH v4] " Jason A. Donenfeld
2022-02-21  3:37       ` Eric Biggers
2022-02-21 14:42         ` Jason A. Donenfeld
2022-02-09  1:19 ` [PATCH v2 8/9] random: use hash function for crng_slow_load() Jason A. Donenfeld
2022-02-09  8:30   ` Dominik Brodowski
2022-02-21  3:40   ` Eric Biggers
2022-02-09  1:19 ` [PATCH v2 9/9] random: remove outdated INT_MAX >> 6 check in urandom_read() Jason A. Donenfeld
2022-02-21  3:56   ` Eric Biggers

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=YgN7mOTtQ03etVJX@owl.dominikbrodowski.net \
    --to=linux@dominikbrodowski.net \
    --cc=Jason@zx2c4.com \
    --cc=bigeasy@linutronix.de \
    --cc=ebiggers@kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.