Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 13 May 2022 12:17:55 +0200
From:   "Jason A. Donenfeld" <Jason@zx2c4.com>
To:     Dominik Brodowski <linux@dominikbrodowski.net>
Cc:     linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH v3] random: use first 128 bits of input as fast init
Message-ID: <Yn4wUxYYYm8adCrN@zx2c4.com>
References: <20220503131204.571547-1-Jason@zx2c4.com>
 <20220504111644.284927-1-Jason@zx2c4.com>
 <Yn35LG3pz9BNsSS3@owl.dominikbrodowski.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <Yn35LG3pz9BNsSS3@owl.dominikbrodowski.net>
Precedence: bulk

Hi Dominik,

On Fri, May 13, 2022 at 08:22:36AM +0200, Dominik Brodowski wrote:
> Am Wed, May 04, 2022 at 01:16:44PM +0200 schrieb Jason A. Donenfeld:
> > Before, the first 64 bytes of input, regardless of how entropic it was,
> > would be used to mutate the crng base key directly, and none of those
> > bytes would be credited as having entropy. Then 256 bits of credited
> > input would be accumulated, and only then would the rng transition from
> > the earlier "fast init" phase into being actually initialized.
> > 
> > The thinking was that by mixing and matching fast init and real init, an
> > attacker who compromised the fast init state, considered easy to do
> > given how little entropy might be in those first 64 bytes, would then be
> > able to bruteforce bits from the actual initialization. By keeping these
> > separate, bruteforcing became impossible.
> > 
> > However, by not crediting potentially creditable bits from those first 64
> > bytes of input, we delay initialization, and actually make the problem
> > worse, because it means the user is drawing worse random numbers for a
> > longer period of time.
> > 
> > Instead, we can take the first 128 bits as fast init, and allow them to
> > be credited, and then hold off on the next 128 bits until they've
> > accumulated. This is still a wide enough margin to prevent bruteforcing
> > the rng state, while still initializing much faster.
> > 
> > Then, rather than trying to piecemeal inject into the base crng key at
> > various points, instead just extract from the pool when we need it, for
> > the crng_init==0 phase. Performance may even be better for the various
> > inputs here, since there are likely more calls to mix_pool_bytes() then
> > there are to get_random_bytes() during this phase of system execution.
> 
> Have you evaluated this closer, also for systems where it takes ages to
> reach crng_init = 1? And might it make sense to only call extract_entropy()
> if there has been new input between two calls to get_random_bytes()?

Yes. On those systems, the extra calls to extract_entropy() are actually
helping the otherwise abysmal state, because they're adding in some new
cycle counter values on every call. Performance-wise, it's not really
that bad. Actually, by *far* the most expensive thing that
extract_entropy() does is RDSEED/RDRAND, but systems that have those
instructions don't stay in crng_init==CRNG_EARLY for very long anyway.
So all and all, it works out quite nicely.

Jason