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:   Tue, 1 Feb 2022 11:03:15 -0500
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        m@ib.tc, Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH] random.c Remove locking in extract_buf()
Message-ID: <YflZw7B1F41KpJ0K@mit.edu>
References: <CACXcFmnPumpkfLLzzjqkBmxwtpMa0izNj3LOtf2ycTugAKAUwQ@mail.gmail.com>
 <CAHmME9pUW1o_QPfs45Q0JWucA5Qu1jhgMV7x2PycxosYV2wV7A@mail.gmail.com>
 <CACXcFmk049OXc16ynjHBa+OSEOMYB=nYE1MDM_oM=Maf8bfcEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACXcFmk049OXc16ynjHBa+OSEOMYB=nYE1MDM_oM=Maf8bfcEA@mail.gmail.com>
Precedence: bulk

On Tue, Feb 01, 2022 at 05:40:11PM +0800, Sandy Harris wrote:
> Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> 
> > Either way, I don't think this is safe to do. We want the feed forward
> > there to totally separate generations of seeds.
> 
> Yes, but the right way to do that is to lock the chacha context
> in the reseed function and call extract_buf() while that lock
> is held. I'll send a patch for that soon.

Extract_buf() is supposed to be able to reliably generate high quality
randomness; that's why we use it for the chacha reseed.  If
extract_buf() can return return the same value for two parallel calls
to extract_buf(), that's a Bad Thing.  For example, suppose there were
two chacha contexts reseeding using extract_buf(), and they were
racing against each other on two different CPU's.  Having two of them
reseed with the same value would be a cryptographic weakness.

NACK to both patches.

       	    	     	   	    - Ted