Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 20 Jan 2022 10:34:33 -0500
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Sandy Harris <sandyinchina@gmail.com>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: random(4) question
Message-ID: <YemBCdWrGeKHWeFN@mit.edu>
References: <CACXcFm=67TU=wy-WdkpiGnSm2M-E5__z=ACTzCmOkiGijrWNOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CACXcFm=67TU=wy-WdkpiGnSm2M-E5__z=ACTzCmOkiGijrWNOg@mail.gmail.com>
Precedence: bulk

On Thu, Jan 20, 2022 at 06:39:31PM +0800, Sandy Harris wrote:
> 
> Like the previous version based on SHA1, this produces an output half
> the hash size which is likely a fine idea since we do not want to
> expose the full hash output to an enemy. Unlike the older code,
> though, this does expose some hash output.

Well, as the comment says, we do this because we want to prevent
backtracking attacks --- where the attacker knows the state of the
pool plus the current outputs, and is trying to go back in time to
figure out previous outputs.  Whether we XOR the halves together or
just reveal half the bits, either will achieve this goal.

Note that we're actually no longer directly exposing this output to
the enemy, since extract_buf is now only being use to extract entropy
from the input pool into the CRNG.  And if the attacker can intercept
the values being used to reseed the CRNG, we've got bigger problems.  :-)

Given how extrat_buf is being used today, assuming that we are
confident in the cryptosecurity of the CHACHA20 algorithm, it's
probably a bit of overkill as it is.  However, it's not like this is
on the hot path from a performance perspective, and a bit of
over-engineering is not a bad thing.

Cheers,

					- Ted